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