summaryrefslogtreecommitdiff
path: root/FCSoftwareRequirements.mdwn
authorPeter Welte <shark@centibyte.org>2007-03-01 10:34:04 (GMT)
committer Peter Welte <shark@centibyte.org>2007-03-01 10:34:04 (GMT)
commit080efa1157907b683be70e2e85368c210c8bca65 (patch) (side-by-side diff)
treeccbf8022e970b212302a008f9d295de66e05e30a /FCSoftwareRequirements.mdwn
parent09b40202ac0deae361038df4b1857e0241267f43 (diff)
downloadwiki-080efa1157907b683be70e2e85368c210c8bca65.zip
wiki-080efa1157907b683be70e2e85368c210c8bca65.tar.gz
FCSoftwareRequirements: added some safety reqs and other info from meeting
Diffstat (limited to 'FCSoftwareRequirements.mdwn') (more/less context) (ignore whitespace changes)
-rw-r--r--FCSoftwareRequirements.mdwn88
1 files changed, 48 insertions, 40 deletions
diff --git a/FCSoftwareRequirements.mdwn b/FCSoftwareRequirements.mdwn
index b65ef00..43742ff 100644
--- a/FCSoftwareRequirements.mdwn
+++ b/FCSoftwareRequirements.mdwn
@@ -8,6 +8,8 @@ Any phrases in _**bold italic**_ need review.
The purpose of this document is to describe in detail the requirements of the flight computer software. By carefully detailing the requirements of the software, all PSAS members and specifically avionics and software team members can review them for accuracy, and ultimately we can produce software that is both complete and correct. Because a detailed list of requirements helps us get the software correct the first time, without redesign, recoding, and retesting, we will be able to launch smarter rockets, faster. This document should also help new PSAS members and other interested people understand our software's capabilities and operation.
+This document is intended to say exactly _what_ the software is supposed to do (we're just describing behavior), it **does not** say _how_ the software should do it (we call that _design_ or _architecture_).
+
The primary audience of this document is the PSAS software team, for use in creating a design for the flight computer software and the software test plan.
### Scope
@@ -15,7 +17,7 @@ The primary audience of this document is the PSAS software team, for use in crea
The software produced will run on the Avionics hardware (AV2b), with the primary objectives of:
1. Ensuring the safety of both the rocket itself and others by launching only when safe and returning safely by deploying parachutes at the appropriate time.
-2. Collecting data during flight from onboard sensors. The data gathered helps in developing active guidance for the next rocket design.
+2. Collecting data during flight from on-board sensors. The data gathered helps in developing active guidance for the next rocket design.
The software on the flight computer is the primary concern of this document; the rocket airframe, its avionics, the firmware for the avionics, and the launch tower may be mentioned here but we're concerned with those things only as much as it matters to the software.
@@ -39,8 +41,10 @@ The following terms are used in this document:
<dt>firmware</dt>
<dd>The software embedded into the electronic devices (except the flight computer) on the rocket</dd>
<dt>Launch Control</dt>
+ <dd>Usually refers to the computer systems running on the ground which are responsible for communicating with the rocket. Can also mean the people in charge of rocket operations, or both, depending on context.</dd>
+ <dt>IMU</dt>
<dd>
- <p><em><strong>TBD (people, computers, software, or ....)</strong></em></p>
+ <p>An &quot;Inertial Measurement Unit (IMU) is a closed system that is used to detect altitude, location, and motion&quot;. --<a href="http://en.wikipedia.org/wiki/Inertial_Measurement_Unit">Wikipedia IMU page</a>. We use the term to refer to the rocket&#39;s IMU node, which is described in the Other Subsystems section below.</p>
</dd>
</dl>
@@ -53,7 +57,7 @@ The following terms are used in this document:
5. Requirements related documents for AV2a flight computer software: [[SoftwareRequirements]], [[SoftwareRequirementsJune2003]], [[SystemRequirements]], [[SystemRequirementsFor04May2003]], [[SoftwareFunctionalSpecJune2003]]
6. Hardware for AV2b flight computer (TQ MPC 5200): <http://www.tq-components.de/446+M551fb6a049c.html>
7. Other block diagrams: [[CapstoneLV2bProjectReport/SystemBlockDiagram]], [[Lv2GroundStationBlockDiagram]] (OLD), and [[BlockDiagram]] (OLD).
-8. [[LaunchSequenceLv2]]
+8. A description of the launch countdown, describing what happens when: [[LaunchSequenceLv2]]
## Overall Description
@@ -61,6 +65,8 @@ This section gives an overall view of the software and the system it is a part o
### Product Perspective
+The software is running on the flight computer and interacts with other electronic devices on the rocket in order to do its job. The software will frequently collect data from the on-board sensors, storing that data to disk and sending it to Launch Control. Launch Control interacts with the software via the wireless link to tell the software to enter certain states, to do certain things (like fire the pyros), or to send initialization values the software may need (like altitude). Once the rocket lifts off, Launch control use an emergency backup radio signal to tell the recovery node to eject the nosecone and fire the pyrotechnic line cutters to deploy the main parachute. During flight, the ATV node sends in-flight analog video to Launch Control via dedicated radio channel (separate from the wifi link).
+
#### Other Subsystems
The other subsystems the software interact with include the flight computer (which the software is running on), the rest of the AV2b avionics package (sensors and other nodes), the Launch Tower, and Launch Control.
@@ -76,14 +82,16 @@ _**modified from [[SoftwareFunctionalSpecJune2003]]**_:
- has a USB connection to the Pyro/2m, GPS, IMU, ATV and APS (Avionics Power System), and MAG (Magnetometer) nodes.
- has a connection to an IEEE 802.11 [[WiFi]] transceiver, over which it exchanges messages with the Launch Control systems.
-- has _**128MB (32MB x 32) of non-volatile flash memory**_ used as a "flash" hard disk (for program and data storage).
-- has _**TBD**_ MB of volotile memory.
+- has up to 4GB of non-volatile flash memory used as a "flash" hard disk (for program and data storage).
+- has up to 256 MB of SDRAM.
- is running Debian GNU/Linux with kernel version 2.6.20 or higher, with Sarah Bailey's USBFS patches.
-- is the PowerPC based TQM5200. More information is available on the [[FlightComputerAv2b]] page.
+- is the PowerPC based TQM5200. We're required to use the PowerPC architecture as part of an IBM grant, and the avionics team picked the specific computer. More information is available on the [[FlightComputerAv2b]] page.
#### Interfaces
-- interfaces (software, hardware, communications)
+This section describes any software, hardware, and communication interfaces the flight computer software needs to use.
+
+- _**TBD: currently we know that we'll communicate over USB to the rockets nodes, and over wifi to Launch Control. When more info about what that communication entails is available, it will go here.**_
#### Modes
@@ -97,12 +105,11 @@ _**modified from [[SoftwareFunctionalSpecJune2003]]**_:
The primary functions of the software are the following:
-1. Interact with Launch Control Systems to abort or successfully launch.
-2. Record real-time data locally in the system, and send a fraction of tha data _**(what fraction?)**_ via the telemetry link.
-3. Measure flight data in order to determine the current state of the flight. _**I think this is implicit . -peter**_
-4. Fire the pyrotechnic charges in order to deploy the drogue parachute at apogee.
-5. Fire the pyrotechnic charges in order to deploy the main parachute some distance above the ground.
-6. Convey enough _**(how much?)**_ useful information via telemetry to the recovery teams to enable them to track the rocket.
+1. Interact with Launch Control to abort or successfully launch.
+2. Fire the pyrotechnic charges in order to deploy the drogue parachute at apogee.
+3. Fire the pyrotechnic charges in order to deploy the main parachute _**some distance**_ above the ground.
+4. Any data communicated between the flight computer and the rocket's nodes should also be transmitted to Launch Control for monitoring and recording, as well as stored locally on the rocket to the extent allowed by the disk size.
+5. Convey enough _**(how much/how frequently?)**_ useful information _**(which is? Just GPS and video?)**_ via telemetry to the recovery teams to enable them to track the rocket.
_**(That was mainly stolen from [[SystemRequirements]].)**_
@@ -122,12 +129,14 @@ Users are expected to have a significant base of expertise in relevant fields, i
### Assumptions and Dependencies
-1. video is sent to ground, without software help. **there should be a better place for this.**
-2. maximum **TBD** bytes/sec available over USB.
+1. maximum _**TBD**_ bytes/sec available over USB to each device. _**or do we have different speeds per device?**_
+2. maximum _**TBD**_ bytes/sec available to the flash drive
3. lots of spare cycles in the Flight Computer
## Specific Requirements
+As a reminder, specific requirements include the following types:
+
- external interfaces
- functions
- design constraints imposed by others (like hardware)
@@ -135,43 +144,42 @@ Users are expected to have a significant base of expertise in relevant fields, i
- standards compliance
- software attributes (reliability, availability, security, maintainability, portability)
-Generally organized by one of (or maybe combination of two of):
-
-- system mode
-- objects
-- high level features
-- stimulus
-- response
-- functional heirarchy
-
-----
-
-## Specific Requirements
+The following are specific requirements, organized primarily by functionality. The "flight sequencing" functionality _**might be**_ organized by state with some things to do in each state. There is a section for non-functionality requirements ("Other Requirements") at the end.
1. Flight Sequencing: the software controls flight sequencing based on internal state machine, input from other subsystems and uplink data.
1. The software will initialize with a "power on self test" that determines which nodes are currently active in the system, then enter a valid state in the state machine (see [[FlightComputerSoftware]]).
- 2. Recovery Node: Software sets recovery node timer to **TBD seconds before launch. The software makes state of recovery node timer available to Launch Control. If software detects timer has &lt;= 1 second but doesn't think the rocket is at apogee, set timer to 4 seconds.**
+ 2. Recovery Node: Software sets recovery node timer to _**TBD**_ seconds before launch. The software makes state of recovery node timer available to Launch Control. If software detects timer has &lt;= 1 second but doesn't think the rocket is at apogee, set timer to 4 seconds.
3. The software should detect launch and enter appropriate state.
4. The software will have a manual override to exit the launch-ready state.
5. If a force state command is recieved from Launch Control, that state will be entered. The possible force state commands are ARM, LAUNCH, ABORT, DEPLOY\_DROGUE, DEPLOY\_MAIN.
- 6. GPS and Pressure initialization messages to FC **what was this for? What is the output (nodes get initialized somehow?)**
+ 6. GPS and Pressure initialization messages to FC _**what was this for? What is the output (nodes get initialized somehow?)**_
7. The software must send signal to hardware to deploy drogue at apogee.
8. The software must detect apogee based on sensor data.
-2. Logging to flash
+2. Collect Rocket State Information
+ 1. The software must read all sensor data _**as frequently as possible while still meeting all other requirements (like apogee detect)**_ from the IMU and GPS
+ 2. The software must _**get info from the APS node**_
+ 3. The software must _**get info from the REC node**_
+ 4. _**what about disk/log usage info?**_
+3. Interact with ATV node _**Does the software need to tell ATV things like GPS location, IMU data, etc?**_
+4. Logging to flash
1. will have no discernable impact on other processing
- 2. will guarantee 100% logging of all packets, including those with failed header checksum, up to the limit of the log buffer
+ 2. will guarantee 100% logging of all packets up to the limit of the log buffer
3. will deal gracefully with log buffer overflow; if necessary, will discard oldest data first
-3. 2\.4 Ghz downlink
+5. 2\.4 Ghz downlink
1. software will tolerate 100% failure of link
2. when resuming from a failure, will process most recent data first
3. will process 10 ping packets per second from the ground to Flight Computer
4. Telemetry data will be sent over the wireless link with Launch Control.
5. Important software state information will be sent to Launch Control.
- 6. wifi link quality measured in flight **(TBD: what does this mean exactly)**
-4. Reliability
- 1. will accept all CAN packets with &lt; 5% dropped **do we have an equivolent measurement of USB? **
- 2. each CAN packet will take &lt;1 millisecond from receipt at the CAN chip, dispatch by muxer, to signal of action thread **TBD**
- 3. If the software crashes, it should be restarted and put in the correct state.
-5. Software attributes
- 1. The software must be designed with unit and integration testing (including simulation) in mind.
- 2. The interface to the USB bus must be narrow so that the bus type could change without a major software overhaul.
+ 6. wifi link quality should be measured in flight
+6. Other Requirements
+ 1. Safety
+ 1. _**TODO. see use cases and state flow pages for ideas**_
+ 2. _**TODO: think about: nose cone separation at wrong time (when?), launch at wrong time, parachutes firing when needed (already listed in flight sequencing, but probably important enough to list twice**_
+ 2. Reliability
+ 1. _**network reliability?**_
+ 2. _**each sensor reading will take &lt;1 millisecond from time available to time processed**_
+ 3. If the software crashes, it should be restarted and put in the correct state.
+ 3. Software attributes
+ 1. The software must be designed with unit and integration testing (including simulation) in mind.
+ 2. The interface to the USB bus must be narrow so that the bus type could change without a major software overhaul.