summaryrefslogtreecommitdiff
path: root/FCSoftwareRequirements.mdwn
blob: 3094318abea4f685de2f52cd1f61c0b62582328a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
[[!toc levels="6"]]

## Introduction

This document describes the requirements for the PSAS flight computer software. This will be a fairly detailed and technical requirements document because the "customers" are also the developers. The software described in this document is targeting the AV2b avioncs package which will be running in the LV2c rocket in late 2007.

Any phrases in _**bold italic**_ need review.

### Purpose

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

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 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.

### Glossary

Some names used here are defined on the [[RocketNames]] page.

The following terms are used in this document:

<dl>
  <dt>rocket</dt>
  <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.</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>
  <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>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>
  <dt>rocketready (also sometimes called RocketReady)</dt>
  <dd>
    <p>a signal on the umbilical cord that allows the rocket to tell the launch tower if it is ready to launch or not. See [[Lv2UmbilicalCord]] and [[Lv2RocketReadyRelay]].</p>
  </dd>
  <dt>MAX_MAIN_DEPLOY_ALTITUDE</dt>
  <dd>Altitude above base altitude to fire the line cutters which allow main parachute to be released: 500 meters.</dd>
  <dt>APOGEE_WINDOW</dt>
  <dd>Time before or after apogee during which it is expected that the rocket&#39;s velocity is slow enough to deploy the drogue parachute. (3 seconds).</dd>
  <dt>TIME_TO_APOGEE</dt>
  <dd>
    <p>The expected time (in seconds) between when the rocket leaves ground and when it reaches apogee. This depends on currently unknown physical characterists of the rocket (weight, motor impulse, etc) so is <em><strong>TBD</strong></em>.</p>
  </dd>
</dl>

### References

1. PSAS Website. <http://psas.pdx.edu> Lots of history and background material available here, as well as current status, project planning and scheduling, and meeting notes.
2. LV2 Avionics whitepaper (old, but pages 25-28 of the PDF file include problem statement, constraints and requirements that are still valid). [[http://psas.pdx.edu/ProjectLV2/lv2_avionics_design.pdf|/ProjectLV2/lv2_avionics_design.pdf]]
3. Description of previous software at [[FlightComputerSoftware]] page.
4. State descriptions for previous software at [[FlightComputerStateFlowSep2003]] page.
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. [[Lv2RocketReadyRelay]] allows FC to abort the launch without relying on any wireless link.
8. [[Lv2UmbilicalCord]] carries shore power and rocketready signal.
9. [[AvionicsPowerSystemLv2]] describes the APS node.
10. [[RecoveryNodeLV2]] describes how the recovery node, pyros, and chute deployment work.
11. Block diagrams: [[onboard avionics system|/avionics/Lv2_avionics_diagram_2006-09-30.pdf]], [[network and ground systems diagram|/avionics/System_diagram_2006-10-16.pdf]], [[CapstoneLV2bProjectReport/SystemBlockDiagram]].
12. A description of the launch countdown, describing what happens when: [[LaunchSequenceLv2]]
13. Some description of software behavior is in the [[CurrentCheckList]].
14. [[Free Software and High Power Rocketry|Usenix2003Paper]] (a PSAS USENIX paper).
15. Discussion about requirements happened on the software and avionics mailing list in february and march, respectively. See <http://lists.psas.pdx.edu/pipermail/psas-avionics/2007-February/thread.html> and <http://lists.psas.pdx.edu/pipermail/psas-software/2007-March/thread.html>.

## Overall Description

This section gives an overall view of the software and the system it is a part of. The Product Perspective section describes the other systems the software interacts with, including a brief overview of the Flight Computer hardware, and describes the modes of operation for the software. The Product Functions section gives a high level view of the functions of the software.

### 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.

The following block diagrams show these systems:

- [[onboard avionics system|/avionics/Lv2_avionics_diagram_2006-09-30.pdf]]
- [[network and ground systems diagram|/avionics/System_diagram_2006-10-16.pdf]]

**The Flight Computer**:

- has two USB host controllers (in other words there are two connectors, or buses, on the FC board): one connects to the sensor/controller nodes, and the other has a USB wireless card and a USB flash disk attached.
- 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 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. 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 [[avionics/FlightComputerAv3]] page.

For historical perspective, see [[SoftwareFunctionalSpecJune2003]].

#### Interfaces

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

- The software may have two "modes": in-flight and debug. Within those, there are a number of states (as described in [[FlightComputerStateFlowSep2003]]) in which the software has unique requirements.

Debug mode has a superset of requirements, mainly that debugging information may be made available and that it should be possible to force the software into any of its states.

### Product Functions

The primary functions of the software are the following:

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 if less than MAX\_MAIN\_DEPLOY\_ALTITUDE.
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 useful information via telemetry to the recovery teams to enable them to track the rocket.

For historical perspective, see [[SystemRequirements]].

### User Characteristics

The users of the software are:

- Students and members of the PSAS team
- Any outside group using the AV2b avionics package inside an LV2c rocket.

Users are expected to have a significant base of expertise in relevant fields, including C/Unix programming.

### Constraints

- The software must not be designed in a way that would make adding active guidance too hard. For example, writing the software in assembly language would make it very difficult to add active guidance later.
- More sensors will be added to the avionics package in the future. A future requirement will be to interact with them, and the design must not compromise that..

### Assumptions and Dependencies

1. maximum of 12 Mbit/sec available per USB host controller.
2. approximate maximum of 10 Mbit/sec available to the flash drive.
3. approximate maximum of 2 Mbit/sec available to the wifi link.
4. lots of spare cycles in the Flight Computer

## Specific Requirements

The following are specific requirements, organized primarily by functionality. There is a section for non-functionality requirements ("Other Requirements") at the end.

1. Configuration.
  1. The software should have a method to configure whether or not antennas should be powered up.
  2. The software must have a way for users to specify GPS position of the launch site, and starting barometric pressure at the launch site. [See setbase.sh and sequencer.c from old software; the software uses it to help detect liftoff].
  3. The software should have a way for users to specify the Ameature radio callsign for the ATV node to use.
2. Flight Sequencing: the software controls flight sequencing based on internal state machine, input from other subsystems and uplink data. The software will implement the behavior described in each state in the [[FlightComputerStateFlowSep2003]] page. The highlights are described here:
  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.
  2. The software must set the recovery node timer to TIME\_TO\_APOGEE seconds before launch.
  3. If an FC\_ABORT\_LAUNCH command is receieved from Launch Control the software enter the appropriate abort state if one is defined. If no abort state is defined (for example, once the motors ignite and launch is detect it is impossible to abort) the event will be logged and no state change will occur.
  4. If an FC\_FORCE\_STATE command is received from Launch Control while in debug mode, that state will be entered.
  5. If an FC\_REQUEST\_STATE command is received from Launch Control requesting the software to enter the next expected state, that state will be entered. Requests to enter an unexpected state should be logged.
  6. The software should detect launch and enter appropriate state.
  7. If the software detects recovery node timer has &lt;= 1 second but doesn't think the rocket is at apogee, set timer to 4 seconds.
  8. The software must detect apogee based on sensor data.
  9. The software must send signal to hardware to deploy drogue at apogee.
3. Collect Rocket State Information
  1. The software should 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 should get, log, and report over wifi voltage, current, and charge from the APS node at _**TBD**_ intervals.
  3. The software should get, log, and report over wifi state of pyros and timers from REC node at _**TBD**_ intervals.
  4. The software should get, log, and report over wifi disk/log usage information at _**TBD**_ intervals.
4. Interact with ATV node. The software should send the following information to the ATV node for overlay, as often as it changes:
  - Mission (e.g. "LV2")
  - Ham callsign
  - FC Status (e.g. Safe, Armed, Boost, etc)
  - GPS latitude, longitude, and gps-locked status (true or false)
  - GPS time (hours, minutes, seconds) altitude
  - GPS date (month, date, year)
  - time left on recovery node timers if they are set
  - altitude from pressure sensor
  - APS node voltage &amp; amps
5. Logging to flash
  1. will have no discernable impact on other processing
  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
6. 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. should 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. (_**How often?**_)
  6. wifi link quality should be measured in flight
7. Other Requirements
  1. Safety
    1. The software must be able to abort the launch if it is commanded to do so before the motor has ignited.
    2. The software must be able to abort the launch if it has detected any error before the motor has ignited.
    3. The software must ensure that the pyros to eject the nose cone only fire when commanded to do so at apogee or during a system test.
    4. The software must ensure that the pyrotechnic line cutters (which allow the main chute to be pulled out) are commanded to fire as soon as the rocket decends to the MAX\_MAIN\_DEPLOY\_ALTITUDE.
  2. Reliability
    1. sensor readings must be processed fast enough so that the software can detect apogee and deploy the drogue parachute within the safe window of time (APOGEE\_WINDOW) from apogee.
    2. 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. Any unit of software that is long, complex, or mission critical should be capable of being unit tested.
    3. The interface to the USB bus must be narrow so that the bus type can change without a major software overhaul.