GLAST/LAT > DAQ and FSW > FSW > Intro to FSW
The FSW (Flight Software) group is tasked with creating software to operate the LAT instrument, process the data it collects, and relay the resulting information to the GLAST satellite.
Much of the software developed by the Flight Software group is used as infrastructure (e.g., for the development, testing, and documentation of the operational flight software). This page does not cover any of this ancillary software; see Documentation Data Flow and Traveler Document Index for more information.
Ideally, all FSW tasks would be performed on a single CPU. Unfortunately the speed of available processors is insufficient, so FSW tasks are divided between multiple CPUs. A single CPU, the spacecraft interface unit (SIU), is responsible for managing the instrument configuration, the activities of the other CPUs and the command and control interface to the spacecraft. A farm of CPUs, the events processing units (EPUs), have the responsibility for bulk science data processing (specifically, information on detected "events").
The SIU will run a small number of tasks, each dedicated to one operational aspect. There are for instance separate tasks for monitoring the instrument's state of health, managing an EEPROM based file system and managing a continuous stream of time and location information from the spacecraft.
While there are also several tasks running on the EPUs, the software architecture is much simpler than the SIU, and nearly all EPU compute cycles will be dedicated to filtering the data stream coming from the instrument to identify the small fraction of events of physics interest.
Although the software running on the EPUs and the SIU have very different duties, they share certain common characteristics:
A CPU crate consists of a cPCI backplane and three "boards": the CPU board, a Storage & Interface Board (SIB) and a LAT communications Board (LCB).
The CPU is a RAD750 (equivalent to a PowerPC 750 but radiation-hardened for use in space). It runs at 133 MHz and has a small (256 kByte) non-volatile memory built in for primary booting (the Start Up ROM or "SUROM").
The SIB provides 6 MByte of non-volatile storage in EEPROM and connectivity back to the spacecraft (a 1553 communications bus and a small number of discrete digital signals). Connectivity to the spacecraft is only supported in the case of the SIU.
The LCB supports communications throughout the LAT instrument, including: bi-directional communications between the SIU and the instrument to configure the instrument, uni-directional transport of events from the instrument to the EPUs, bi-directional communication between EPUs and the SIU, and the uni-directional connection from all CPUs to a bulk data storage device (the Solid State Recorder or "SSR") provided by the spacecraft.
Primary boot is performed from the SUROM. Primary boot performs very low level board and crate intialization with the hardware watchdog disabled. Once primitive communications have been established, the primary boot enters an interactive state where it can service a small number of commands (e.g. load file, dump memory, proceed to secondary boot). EPUs receive such commands from the SIU. The SIU receives such commands from the spacecraft. If commanded to do so, or if no commands are received during a timeout period, the primary boot initiates secondary boot by loading a full VxWorks operating system from SIB EEPROM and branching to the VxWorks entry point.
The VxWorks image loaded at the end of primary boot repeats much of the board and crate initialization done by primary boot, but with greater sophistication. Once VxWorks is satisfied that the crate is configured, it performs its final step which is to load in applications from the SIB EEPROM file system and initialize the various tasks that satisfy that CPU's function. At this point the CPU is running in the "steady state" with the watchdog enabled. If the watchdog is not re-initialized on a regular basis ("given a heartbeat"), the hardware watchdog initiates a hard reset of the crate.
Most of the operational flight software is written in C. A small portion is written in assembly language, for reasons of performance and predictability.
The operational flight software, like most software produced by the FSW group, is divided up into a hierarchy of projects, packages, constituents, and files. See The FSW Build Matrix and The FSW File Tree for details.
Although VxWorks processes share a common address space, FSW practice is to avoid the explicit use of shared memory. Most interprocess communication is performed via queues.
The operational flight software runs under VxWorks, a real-time operating system from Wind River. The C-level programming interfaces in VxWorks are modeled after those found in Unix.
Several FSW packages (e.g., FILE, LCB, MSG, PBI, PBS) provide services used on all CPUs. Other packages can be more specialized and are only used on one of the species of processor. For more information on package relationships, see the Package "use" Tree.
The foremost responsibility of software running on EPUs is to filter the data produced by the Trigger and Dataflow (T&DF) electronics system. The filter characterizes and retains events caused by high-energy photons (i.e., Gamma-rays), rejecting the high flux of cosmic background radiation (e.g., protons, electrons and positrons). Each retained event contains information on the incident direction, energy, and arrival time of the photon.
During normal operation, the filtering software:
Upon request by the Spacecraft Interface Unit software, the filtering software may:
Other functions provided by the EPU include:
Flight software running on the spacecraft interface unit (SIU) provides the command, control, and configuration functions for the instrument. In addition, it handles instrument health monitoring. Specifically, it: