summaryrefslogtreecommitdiff
path: root/FCSoftwareRequirements.mdwn
authorPeter Welte <shark@centibyte.org>2007-02-28 08:43:03 (GMT)
committer Peter Welte <shark@centibyte.org>2007-02-28 08:43:03 (GMT)
commit5b73f3579a33fd2061789340d8e6b5ae43e9f339 (patch) (side-by-side diff)
treecf5863d3e7c9c31efc9a35ac48aa1f15852bd099 /FCSoftwareRequirements.mdwn
parentf4a78d88cb7a39965392142deab88628e613f241 (diff)
downloadwiki-5b73f3579a33fd2061789340d8e6b5ae43e9f339.zip
wiki-5b73f3579a33fd2061789340d8e6b5ae43e9f339.tar.gz
FCSoftwareRequirements: refactored requirements into one list (still needs work), added state flow link
Diffstat (limited to 'FCSoftwareRequirements.mdwn') (more/less context) (ignore whitespace changes)
-rw-r--r--FCSoftwareRequirements.mdwn109
1 files changed, 34 insertions, 75 deletions
diff --git a/FCSoftwareRequirements.mdwn b/FCSoftwareRequirements.mdwn
index 17743d0..c7b1a6f 100644
--- a/FCSoftwareRequirements.mdwn
+++ b/FCSoftwareRequirements.mdwn
@@ -8,7 +8,7 @@ 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.
-The primary audience of this document is the PSAS software team, for use in creating a design and ultimately the flight computer software and software test systems.
+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
@@ -27,15 +27,17 @@ The following terms are used in this document:
<dl>
<dt>rocket</dt>
- <dd>The LV2c rocket that the software will run on.</dd>
+ <dd>The LV2c rocket that the avionics package is installed in.</dd>
<dt>FC or Flight Computer</dt>
- <dd>The rocket&#39;s flight computer. avionics package: the rocket&#39;s electronics, including flight computer, sensors, power supply, etc.</dd>
+ <dd>The rocket&#39;s flight computer.</dd>
+ <dt>avionics package</dt>
+ <dd>The rocket&#39;s electronics, including flight computer, sensors, power supply, etc.</dd>
<dt>software</dt>
<dd>The software running on the rocket&#39;s flight computer. In this document, this term refers only to the flight computer software, and not to the firmware on the rocket&#39;s sensors.</dd>
<dt>system</dt>
<dd>This term may be used interchangeably with the term &#39;software&#39;.</dd>
<dt>firmware</dt>
- <dd>the software embedded into the electronic devices (except the flight computer) on the rocket</dd>
+ <dd>The software embedded into the electronic devices (except the flight computer) on the rocket</dd>
<dt>Launch Control</dt>
<dd>
<p><em><strong>TBD (people, computers, software, or ....)</strong></em></p>
@@ -51,6 +53,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. State flow information: [[FlightComputerStateFlowSep2003]]
## Overall Description
@@ -60,7 +63,7 @@ This section gives an overall view of the software and the system it is a part o
#### 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 electronic nodes), the Launch Tower, and Launch Control.
+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.
The following block diagrams show these systems:
@@ -97,18 +100,18 @@ The Flight Computer is the PowerPC based TQM5200. More information is available
### Product Functions
-The primary objectives of the software are the following:
+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 fraction of tha data via the telemetry link.
-3. Measure flight data in order to determine the current state of the flight **I think this is implicit . -peter**
+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 useful information via telemetry to the recovery teams to enable them to track the rocket.
**(That was mainly stolen from [[SystemRequirements]].)**
-### **User Characteristics**
+### _User Characteristics_
The users of the software are:
@@ -124,7 +127,9 @@ Users are expected to have a significant base of expertise in relevant fields, i
### Assumptions and Dependencies
-- **TBD**' what to put here?
+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
+3. lots of spare cycles in the Flight Computer
## Specific Requirements
@@ -143,19 +148,14 @@ Generally organized by one of (or maybe combination of two of):
- stimulus
- response
- functional heirarchy
-- user class
----
-Feel free to review and add input. --Peter
-
-## Requirements
-
-### Inputs:
+## Specific Requirements
-The flight computer software's inputs are data from the hardware devices on the rocket as well as messages from ground control.
+1. **Flight Sequencing**
-Ground control can send the following messages:
+Commands from ground:
- ARM
- LAUNCH
@@ -163,71 +163,30 @@ Ground control can send the following messages:
- DEPLOY DROGUE
- DEPLOY MAIN
-### Outputs:
-
-The software communicates state information over the wireless link with ground control, and communicates with each sensor or control component running on the rocket.
-
-### The rest (needs organizing):
-
-Sensors (need list) Comm Bus Wireless comm info More hw info OS: Linux 2.6 (Probably &gt; 2.6.20 w/ Sarah's USBFS patches) memory - how much?
-
Recovery Node: FC sets timer to N seconds (TBD) before it is launched. FC s/ make state of rec. node timer available to GC. If FC detects timer has &lt;= 1 second but FC doesn't think we're at apogee, set timer to 4 seconds.
-The FC must detect apogee based on sensor data.
-
-The FC must send signal to hardware to deploy drogue at apogee.
-
-The FC must record sensor data. -&gt; using flash drive -&gt; using wireless link
-
-Simulation: code must be designed with unit and integration testing (simulation) in mind
-
-The firmware software runs on the control devices. As much of the firmware code as possible must be written in ANSI C so it can be tested with the FC software using the simulator.
-
-----
-
-## Requirements from other docs
-
-**[[SystemRequirements]]**:
-
-**avionics whitepaper:**
-
-- ground control can interface to flight computer for manual status checks, arming the systems, and emergency control of the payload separation (p. 28)
-- fc sends telemetry data to ground
-- video is sent to ground
-- telemetry data and fc status sent to ground for monitoring and storage
- FC: the fc controls flight sequencing based on internal state machine, input from other subsystems and uplink data
-
-**[[SoftwareRequirements]]:**
-
-In order:
-
-- launchcontrol sequences launch
- - Pressure initialization message to FC (UI to enter info, or read file)
- - GPS origin message to FC
- - Listen to FC state message
- - Be able to force rocket state using [[TestNetSend]] and possibly scripts
- FC detects launch
-- Data is logged to flash
-- wifi link quality measured in flight
-- rocketview displays rocket status
- - GPS messages
- - FC state
-
-**[[SoftwareRequirementsJune2003]]**:
-
-1. **Flight Computer**
- 1. will initialize with a "power on self test" that determines which CAN nodes are currently active in the system, then enter a valid state in the state machine
+ 1. 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
2. will have a manual override to exit the launch-ready state
- 3. will accept all CAN packets with &lt; 5% dropped
- 4. each CAN packet will take &lt;1 millisecond from receipt at the CAN chip, dispatch by muxer, to signal of action thread
-2. **Logger**
+ 3. If a force state command is recieved from Launch Control, that state will be entered. T
+ 4. GPS and Pressure initialization messages to FC **what was this for? what is the output**
+ 5. will accept all CAN packets with &lt; 5% dropped
+ 6. each CAN packet will take &lt;1 millisecond from receipt at the CAN chip, dispatch by muxer, to signal of action thread
+ 7. The FC must send signal to hardware to deploy drogue at apogee.
+- The FC must detect apogee based on sensor data.
+- **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
3. will deal gracefully with log buffer overflow; if necessary, will discard oldest data first
-3. **2\.4 Ghz downlink**
+- **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. **Assumptions**
- 1. maximum of 128K bytes/sec received on CAN bus
- 2. lots of spare cycles in the Flight Computer
+ 4. Telemetry data will be sent over the wireless link with Launch Control.
+ 5. Important software state information will be sent
+ and fc status sent to ground for monitoring and storage
+ - The software communicates state information over the wireless link with Launch Control.
+- wifi link quality measured in flight _**TBD**_
+- Testability
+ 1. The software must be designed with unit and integration testing (including simulation) in mind.