Flight software architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 7

Flight Software Architecture PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Flight Software Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Flight software architecture

Flight Software Architecture

Jim Beatty

Ohio State


Computing environment

Computing Environment

  • SBS CR-7 Pentium-III at 700 MHz

  • ‘Stripped’ Linux installation based on RH 9.0

  • 512 MB RAM

    • 256MB configured as RAMdisk.

  • 1 GB Flash disk for system

  • 40 GB solid-state disk for data archive

  • No swap!


Dataflow diagram

Dataflow Diagram


Issues

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

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

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

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


  • Login