PSAS/ FCSoftwareRequirements
  1. Introduction
    1. Purpose
    2. Scope
    3. Glossary
    4. References
  2. Overall Description
    1. Product Perspective
      1. Other Subsystems
      2. Interfaces
      3. Modes
    2. Product Functions
    3. User Characteristics
    4. Constraints
    5. Assumptions and Dependencies
  3. Specific Requirements

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:

rocket
The LV2c rocket that the avionics package is installed in.
FC or Flight Computer
The rocket's flight computer.
avionics package
The rocket's electronics, including flight computer, sensors, power supply, etc.
software
The software running on the rocket's flight computer. In this document, this term refers only to the flight computer software, and not to the firmware on the rocket's sensors.
system
This term may be used interchangeably with the term 'software'.
firmware
The software embedded into the electronic devices (except the flight computer) on the rocket
Launch Control
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.
IMU

An "Inertial Measurement Unit (IMU) is a closed system that is used to detect altitude, location, and motion". --Wikipedia IMU page. We use the term to refer to the rocket's IMU node, which is described in the Other Subsystems section below.

rocketready (also sometimes called RocketReady)

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.

MAX_MAIN_DEPLOY_ALTITUDE
Altitude above base altitude to fire the line cutters which allow main parachute to be released: 500 meters.
APOGEE_WINDOW
Time before or after apogee during which it is expected that the rocket's velocity is slow enough to deploy the drogue parachute. (3 seconds).
TIME_TO_APOGEE

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

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
  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, network and ground systems diagram, 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 (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:

The Flight Computer:

For historical perspective, see SoftwareFunctionalSpecJune2003.

Interfaces

This section describes any software, hardware, and communication interfaces the flight computer software needs to use.

Modes

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:

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

Constraints

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 <= 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 & 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
    2. The software must be able to abort the launch if it is commanded to do so before the motor has ignited.
    3. The software must be able to abort the launch if it has detected any error before the motor has ignited.
    4. 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.
    5. 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.
    6. Reliability
    7. 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.
    8. If the software crashes, it should be restarted and put in the correct state.
    9. Software attributes
    10. The software must be designed with unit and integration testing (including simulation) in mind.
    11. Any unit of software that is long, complex, or mission critical should be capable of being unit tested.
    12. The interface to the USB bus must be narrow so that the bus type can change without a major software overhaul.