Flight Software Architecture Jim Beatty Ohio State

Computing Environment SBS CR-7 Pentium-III at 700 MHz ‘Stripped’ Linux installation based on RH MB RAM –256MB configured as RAMdisk. 1 GB Flash disk for system 40 GB solid-state disk for data archive No swap!

Dataflow Diagram

Issues The system must never page or swap. –Fixed suite of processes –Avoid memory leaks Repetitive writing to solid state disk must be limited to well below the device specs. –This is subtle, because filesystem data structures are involved and we do not directly control physical writes. –Minimize file accesses by appropriate blocking. RAMdisk is our scratch and temporary space and is limited. System must gracefully resume operation on restart.

What goes on solid-state disk? Events are archived to solid-state disk only after passing the prioritizer. –/run/priority/subrun directory tree Command and housekeeping logs are blocked and placed on the solid state disk. Configuration snapshots are periodically archived to the solid-state disk. –These include event queue pointer snapshots. –We can choose to define a master configuration to be assumed on the next restart.

What goes on RAMdisk? Packets and file pointers. Current configuration (since modifications via commands may cause multiple writes per change). Log data not yet archived to solid state disk. Logs used for debugging –Periodically truncated. –Logged to external storage during testing.

How event queueing works Pointers into the event queues are used to track the next event: –for each priority queue –for header and for transient packet generation. Checkpoint pointers to archive periodically. On restart, transmission begins from the last checkpoint, but can be commanded to skip to the most recent data. Data ‘in transit’ at the time of reset is permanently lost. –Need to understand the impact of this on deadtime determination Playback can be used to fill in gaps