Process/FIFO Software Architecture
Description: The process/FIFO software is a suite of a flight computer software application tasks. It is responsible for all the flight computer requirements, basically handling input/output to CAN and Wireless LAN in accordance with the flight computer state model.
The FIFO architecture consists of a handful of processes each focusing on a specific asynchronous task:
- can_rdr - reads messages from the CAN device driver and turns them into FIFO messages, dispatches to other processes
- can_wtr - reads FIFO messages and writes them to the CAN device driver
- can_rw - performs both can_rdr and can_wtr tasks (alternative to seperate can_rdr and can_wtr processes)
- sequencer - handles the flight computer state machine, turn on and turn off of all CAN device nodes.
- smart - handles the main data path from the CAN during flight, interpreting physical data into position and velocity, and produces messages to inform sequencer to detect launch, chuff, burnout, apogee, and parachute deployment.
- logger - commits FIFO messages to a log file
- fc2net - sends telemetry FIFO messages to wireless via UDP messages
- net2fc - recieves command messages via wireless UDP, dispatches to other processes as FIFO messages.
- manager - responsible for process management of the above tasks (it is to the application like "init" is to a Linux system)
The tasks communicate with each other with named pipes (aka FIFOs), sending fixed-size FIFO message structures. Each task is basically a big loop waiting for things to read on its data source (usually its own FIFO, but can be the can device for can_rdr or the net device for net2fc). Processes open another process' FIFO and write a message into it in order to communicate to the other process. FIFO messages include raw can messages, system state information, interesting conditions, miscellaneous strings, and the like.
Source code: is at http://cvs.psas.pdx.edu in the c/fcfifo directory, with library functions in the c/ltc-fc-common directory and Linux CAN driver in the c/can-linux directory.
History: The FIFO architecture replaced the earlier Can Muxer and Renegade architectures, which didn't get as far in implementation of the rocket application.
Pros: The main advantage to the process/fifo architecture seems to be ease of initial implementation and debugging.
Cons: The weakness to this model includes:
- FIFOs have problems with determinism of ordering and timing and may cause deadlocks or livelocks if not used carefully.
- sharing state data between tasks requires explicit code for marshalling the data into FIFO message packets and unmarshalling on the other side, leading to high overhead and potential for subtle errors.
- It is hard to create watcher tasks browsing the state data for interesting conditions, at least with the current architecture.
Compare with BlackboardArchitecture.
-- ?JamesPerkins - 08 Oct 2003