|
Ideally, all FSW tasks would be performed on a single CPU.
Unfortunately,
the limited speed of available radiation-hardened processors
requires the tasks to be performed on multiple CPUs.
(See FSW Task Index
for an annotated list of FSW tasks.)
- The Spacecraft Interface Unit (SIU)
The SIU is responsible for managing the instrument configuration,
the activities of the other CPUs,
and the command and control interface to the spacecraft.
A spare SIU is available, in case the primary SIU fails.
- The Event Processing Units (EPUs)
A trio of EPUs is responsible for bulk science data processing
(specifically, handling information on detected "events").
It is expected that only two EPUs will be running at any time.
The SIU performs a small number of tasks,
each dedicated to one aspect of the instrument's operation.
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.
Although there are also several tasks running on the EPUs,
the software architecture is much simpler than that of the SIU.
Nearly all EPU compute cycles are dedicated
to filtering the data stream coming from the instrument
(to identify the small fraction of events of physics interest).
Common Characteristics
Although the SIU and the EPUs have very different duties,
they share certain common characteristics:
- Hardware
Each CPU resides in a "crate",
consisting of a Compact PCI (cPCI) backplane and three boards:
- Booting
Primary boot, performed from the SUROM,
performs low-level board and crate intialization,
with the hardware watchdog disabled.
Once primitive communications have been established,
the boot software 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 these commands from the SIU;
The SIU receives them from the spacecraft.
Once commanded to do so,
the primary boot initiates secondary boot.
Specifically, it loads the
VxWorks
operating system from SIB EEPROM
and branches to the VxWorks entry point.
VxWorks repeats much of the board and crate initialization
performed during the primary boot, but with greater sophistication.
Once VxWorks is satisfied that the crate is configured,
it loads applications (from the SIB EEPROM file system)
and initializes the CPU's tasks.
At this point,
the CPU is running in the "steady state",
with the hardware watchdog enabled.
If the watchdog is not re-initialized on a regular basis
("given a heartbeat"), it will initiate a hard reset of the crate.
- Languages
Most of the operational flight software is written in C.
A small portion is written in assembly language,
for reasons of performance and predictability
(i.e., control of the exact instruction sequence to be used).
- Modularity
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.
- Operating System
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.
- Support Code
Several FSW packages (e.g.,
CMX,
FILE,
LCB,
MSG,
PBI,
PBS)
provide services used on all CPUs.
Other, more specialized packages
are used on either the SIU or the EPUs, as appropriate.
For more information on package relationships,
see the Package "use" Tree.
EPU Characteristics and Duties
The foremost responsibility of the EPU software
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:
-
monitors event data for integrity,
tracking changes in event and detector statistics.
The software notifies the SIU software
in the event of any errors or anomalies.
-
filters the input stream of events
(i.e., those accepted by the electronic trigger)
into an output stream whose volume
meets the spacecraft storage rate and capacity,
while keeping events that meet the science objectives.
See Event Filtering
for details.
Upon request by the SIU software, the filtering software may:
-
allow reconfiguration to increase or decrease the filtering rate
-
pass a pre-scaled sample of unfiltered events,
for monitoring and analysis
Other functions provided by the EPU include:
-
dumping specified regions of memory
-
providing read/write/dump access to the EEPROM-based file system
-
maintaining (GPS-synchronized, wall clock) time information
SIU Characteristics and Duties
Flight software running on the SIU provides the command, control,
and configuration functions for the instrument.
In addition, it handles instrument health monitoring.
Specifically, it:
-
exchanges commands, low rate telemetry, time messages,
and ancillary data with the spacecraft,
using a 1553
communications bus and physical-layer protocol.
-
receives commands across the Command and Telemetry Data Bus (CTDB)
at a rate of up to 20 commands per second.
-
accepts up to 4 primary and 4 redundant discrete input signals
from the spacecraft, for configuration and power control of the LAT.
These include both pulse and level signals.
-
sends up to 3 primary and 3 redundant monitor signals
to the spacecraft, for communicating status.
-
formats science data into
CCSDS packets,
then transfers these to the spacecraft
via the custom science-data interface.
-
formats housekeeping data into CCSDS telemetry packets,
then transfers these to the spacecraft via the CTDB.
-
communicates with the LAT instrument subsystems,
for the purposes of configuration and retrieval
of housekeeping and low-rate science data.
-
configures, reprograms, and receives data from the EPUs.
|
