RBSP
Rad
iati
on B
elt S
torm
Pro
bes
RBSP
Rad
iati
on B
elt S
torm
Pro
bes
04/21/23 1
Flight Software
Template forInstrument Critical Design Review
Gary M. Heiligman2009 May 27
04/21/23 2
General Guidelines
• This is a template for the Flight Software portion of I-CDR.• Provide Presentation and Backup Materials in the I-CDR review
package.• Present all required topics in the Presentation.
– Target audience for the Presentation is all reviewers.
– Flight Software Presentations usually require more than the 30 minutes currently allocated in the I-CDR Guidelines. Instrument teams should allocate enough time to adequately cover the material that follows.
• JUNO FSW presentations required about 60 minutes and 30 slides
• Provide detailed information in Backup Materials.– Target audience for Backup Materials is the software experts.
– No limit on the number of Backup Material slides, but “keep it reasonable”.
– DON’T use Backup Materials as a proxy for detailed peer reviews.
04/21/23 3
Outline
• Flight Software Overview• Flight Software Context• Changes Since Preliminary Design Review• Detailed Software Design
– Functional description– Structural decomposition– Timing
• Commands and Telemetry (may be included in Functional Description instead of a separate section)
• Resource Margins• Software Verification and Testing• Status of Engineering Model Software (optional)• Development Environment and Support of Flight Operations• Backup Materials
04/21/23 4
Flight Software Overview
• Key Requirements– What does the software do?
– List requirements that drive the software design.
– DON’T list all the requirements in your Presentation; if you want to include them in the review package, put them in the Backup Materials.
• List of CSCIs– What are the major pieces of software?
– For every CSCI, give a 1 – 2 sentence summary of what it does.
(suggested size: 2 slides)
04/21/23 5
Flight Software Context
• Place the flight software in its context– Where does FSW fit within the instrument system as a whole?– Include processors, data storage, buses, networks, communication
lines, peripherals, etc.– Recommendation: use your context diagram (or block diagram) from
PDR, updated as needed.
(suggested size: one slide)
04/21/23 6
Changes Since Preliminary Design Review
• Status of each action item from instrument and mission PDRs (1 slide, if any)– Put responses to each RFA in Backup Materials
• Results of trade studies (1 slide, if any)• Major changes in software requirements (1 slide, if any)• Major changes in ICDs (1 slide, if any)• Major changes in top-level design (1 slide, if any)• Peer reviews since PDR (1 slide, if any)
– Summarize results and action items
• Major open technical issues, programmatic issues, or risks (1 slide, if any)
04/21/23 7
Detailed Software DesignFunctional Description
• Describe the functional operation of the software– Include Boot / initialization
• Describe major modes of operation– (may use UML statechart or state-transition diagram)
• Describe data flows (in data driven designs)– (may use data flow diagram)
• Describe communication / synchronization between multiple tasks (in multitasking designs)– (may use task communication graph)
• Describe critical task functional flow– (may use a task flow diagram)
• Describe management of data stored within the instrument (for instruments that have an internal SSR)
(suggested size: 3-6 slides, remainder in backup)
04/21/23 8
Structural Decomposition
• Decompose the design into components– E.g., packages, modules, function groups, or classes
• Describe the structural relationship between components– E.g., which packages call which – (may use a package dependency diagram)
(suggested size: 2-4 slides, remainder in backup)
04/21/23 9
Timing
• Describe activities during a major cycle (usually 1 second)– (may use a timing diagram)
(suggested size: 1-3 slides)
04/21/23 10
Commands
• List commands implemented by the software– Group by functional area
-- OR --
• List commands with the description of each functional area in the Detailed Design portion of the package
(suggested size: 1-2 slides)
04/21/23 11
Telemetry
• List telemetry packets produced by the software
-- OR --
• List telemetry packets with the description of each functional area in the Detailed Design portion of the package
• Show how telemetry fits within allocated SSR volume– Recommendation: Provide a table showing how
Σ {packet size} × {production rate} ≤ {telemetry allocation}
(suggested size: 2-5 slides)
04/21/23 12
Resource Margins
• Present the resource metrics that you specified in SW-001– Typically includes RAM, EEPROM, and CPU utilization– Compare against estimates from PDR– Margin = 100% - {estimated} / {available}– For Example:
Resource AvailableCurrentEstimate
Current% Margin
Estimateat PDR
% Marginat PDR
CPU utilization 100% 71% 29% 60% 40%RAM (KB) 512 455 11% 255 50%EEPROM (KB) 64 31 52% 30 53%Peak telemetryrate (bits/sec) 80000 61440 23% 51200 36%Processing timeper event (µs) 10 5.6 44% 5 50%
(suggested size: 1 slide) This example is a particle instrument thatmust process 100,000 events per second
04/21/23 13
Software Verification and Testing
• Summarize how flight software will be tested– Resources required: Test environment, GSE, other instrument
subsystems
– Is the tester independent of the developer?
• Summarize what tests will be conducted– For example:
• Functional areas• Day-in-the-life scenarios• Reset & recovery• New program load• Internal SSR management• Stress tests
(suggested size: 1 slide)
04/21/23 14
Status of Engineering Model Software
• Describe state of software currently in use on engineering models, breadboards, and prototypes
(suggested size: 1 slide, detailed results in backup slides)
04/21/23 15
Development Environment and Support of I&T and Flight Operations
• Development Environment– List tools, development platforms, etc. and provide status– Include support for geographically distributed teams
• Support for I&T and Flight Operations– List software builds with (approximate) dates– Describe facilities for software updates after instrument delivery to APL
(suggested size: 1 slide)
RBSP
Rad
iati
on B
elt S
torm
Pro
bes
RBSP
Rad
iati
on B
elt S
torm
Pro
bes
04/21/23 16
Flight SoftwareBackup Materials
Candidate materials for
Instrument Critical Design Review
04/21/23 17
Guidelines
• Place information in the Backup Materials if it interrupts the flow of the Presentation
• The following are examples of diagram types that might appear in the Backup Materials– NONE OF THEM IS REQUIRED
04/21/23 18
Sample State-Transition Diagram
Step cmdreceived
Start
Auto-track (1)(command as necessary to
track the Earth)
Fixed Position (2)(command as necessary to
specified position)
Disabled (0)(send null command)
Auto-track cmd received and mode
not Maneuver
Rotate to Fixed Positioncmd received
mode = Maneuveror Disable Steering
cmd received
Auto-track cmd receivedand HGA uncaged
and mode not Maneuver
Auto-track will probably be used only in the heliocentric orbit.
Drive gimbal to commanded position and maintain it there.Used during I&T and on-orbit calibration.
Rotate to Fixed Positioncmd received
HGA should not be moved during Ascent mode or delta-v maneuvers.
Note: If a problem is detected trying to move the antenna, it is reported to C&DH where autonomy will respond by sending the Disable Steering cmd to G&C.
Step cmd receivedand HGA uncaged
Note: Numeric values of states are indicated in parentheses.
Stepping (3)(move commanded number
of steps)
Step cmd received
no more steps to door Disable Steering cmd received
Disable Steeringcmd received
Rotate to Fixed Positioncmd received
and HGA uncaged
version: 2006.03.08
04/21/23 19
Sample Data Flow Diagram
DSMSAssessment
CSCI
FrontEndCSCI
sfdu_to_stfIDR Files
TelemetryFrame Data
stf_to_stp
STPs
STF Files
derivedDerived
TelemetryPacket Data
IDRs
STFs
IDRs
STFs
STFs
STFs
STPs
STPs
STPs
STPsSTPs
IDR = Intermediate Data RecordSTF = Supplemented Telemetry FrameSTP = Supplemented Telemetry Packet
STPscontaining
SFDUheader data
04/21/23 20
Sample Task Communication Graph
Task 1
CommandQueue
Task 2 Task 3
Task 4ISR 1
SensorData
PERIODIC TASKexecutes at regular intervals
OPERATING SYSTEM QUEUEallows tasks to post and pend on messages
SEMAPHOREused to synchronize execution of a task
PROTECTED DATA STORElocking mechanism prevents simultaneous task access
INTERRUPT SERVICE ROUTINEusually triggered by an external source
CONTROL FLOWrepresented by dotted lines
DATA FLOWrepresented by solid lines
04/21/23 21
Sample Task Flow Diagram
Suspend until 25Hz interrupt
Initialize
Generate thrustercommand
Queue thrustercommand on TACCommand queue
5m
Queuedsuccessfully ?
No
Yes
Repeat 2 timesbefore exiting loop
Error::LogMinor(TAC)
Integrate attitude
Error::LogMajor(TAC)
Store ACintegrated attitude
5m
Storedsuccessfully ?
No
Repeat 2 timesbefore exiting loop
Error::LogMinor(Att)
Error::LogMajor(Att)
Yes
SYNCHRONIZATIONindicates that task may suspend on this call
SYNCHRONIZATIONindicates that task may suspend on this call for maximum of 5 milliseconds
METHOD CALLto a method in a package named Error
04/21/23 22
Sample Package Dependency Diagram
Package 1
Package 2
Package 3 Package 5
Package 4
DEPENDENCYPackage 1 depends on Package 2 (i.e., Package 1 calls a method contained in Package 2)
DEPENDENCYPackage 1 depends on Package 4 (i.e., Package 1 calls a method contained in Package 4)
DEPENDENCYPackage 4 depends on Package 5 (i.e., Package 4 calls a method contained in Package 5)
DEPENDENCYPackage 3 depends on Package 4 (i.e., Package 3 calls a method contained in Package 4)
04/21/23 23
Sample Timing Diagram