R.C. Moore 1

1
An Overview of Space Flight Software Engineering
Presented by Robert C. Moore Principal Staff
Engineer The Johns Hopkins University Applied
Physics Laboratory Space Department robert.moore_at_j
huapl.edu
2
Essential attributes of well-engineered software
? Maintainable capable of evolving to meet
changing requirements
? Dependable reliable, secure, safe, not able to
cause damage
? Efficient not wasteful of system resources
(memory, time, etc.)
? Usable appropriate user interface, adequate
documentation
3
Fundamental software process activities
Specification define functionality and
constraints on operation
Development generate software that meets the
requirements
Validation confirm that the software does what
the customer wants. Confirm that the quality
assurance (QA) plan was implemented.
Evolution modify the software to meet changing
requirements. Maintain configuration management
(CM) for all versions.
4
Empirical estimation model for embedded space
flight software (COCOMO model)
Assumes that the total number of thousands of
lines of deliverable source instructions (kLOC)
is already estimated
Development effort E 3.6 (kLOC) 1.2
(staff-months)
Development duration D 2.5 E 0.32 (months)
Source Ian Sommerville, Software Engineering,
5th ed. (Essex, England Addison-Wesley
Publishers, Ltd., 1995), pp. 598-602. COCOMO is
an abbreviation of Constructive Cost Model.
5
The space system engineering process
Requirements definition
Mission termination
System design
Mission operations
Subsystem development
Launch, AE
Integration and test
6
Flight software development
7
Flight software criticality
8
Embedded real-time software development
Real-time system correct functioning depends on
the system responding to events within a
specified time interval
Soft real-time system operation is degraded if
system misses deadline(s) in responding to events
Hard real-time system operation is incorrect
(system fails) if system misses deadline(s) in
responding to events
9
Stimulus-response paradigm
Sensor
Actuator
Sensor
Actuator
Data processor
Sensor control
Actuator control
Sensor
Actuator
When stimulus is received from a sensor, control
is transferred to the appropriate handler with
minimal latency
Data processor is a set of concurrent,
cooperating processes that are managed by a
real-time executive
10
Real-time executive
11
Software fault avoidance
Use floating-point representations only where
necessary
Pay special attention to the ways pointers are
used
Pay special attention to the implementation of
dynamic (run-time) memory allocation /
de-allocation
Avoid non-deterministic real-time schedules
Use recursion only where absolutely necessary
Keep the number of interrupts to a minimum
Take full advantage of data typing to enforce
need to know access to variables (information
hiding)
12
Software testing
Verification Are we building the product right?
(Does the software correctly implement the
requirements specification?)
Validation Are we building the right product?
(Does the software meet the expectations of its
customer?)
Statistical testing evaluates system performance
Defect testing seeks to induce failures. Can
demonstrate only the presence of errors cannot
prove that there are no errors.
De-bugging seeks to locate and correct defects
Regression testing confirms that recent changes
have not introduced new defects
13
Flight software testing
Unit testing
Subsystem testing
System testing
Acceptance testing
Component testing
Integration testing
User testing
14
Software testing strategies
Top-down begin with the most abstract
components. Lower-level components are stubbed
as necessary.
Bottom-up begin with the least abstract
components e.g., test low-level objects using
their own test drivers.
Thread exercise all unique transactions that
thread their way through the processes.
Stress determine the systems response to
deliberate overload, and the system margins.
Especially important for multiple-processor
systems.
Back-to-back compare results from multiple
versions of the system e.g., N-version
programming.
15
Additional cost of software errors
16
14
12
10
Additional cost to fix during test
8
6
4
2
Requirements Specification
Top-level Design
Coding
Documentation
Other
Product containing the error
Source Rosenberg and Hyatt, Software Metrics
Program for Risk Assessment, 47th International
Astronautical Congress and Exhibition, Risk
Management and Assessment Session, Beijing,
China, October, 1996, pp. 3-4 of 9.
16
Phases of testing in the software development
process
Requirements specification
System specification
System design
Detailed design
System integration test plan
Subsystem integration test plan
Acceptance test plan
Module code and test
Launch, AE
Acceptance test
System integration
Subsystem integration
17
Probability of successful change
Probability that change is correct (on first
attempt)
Number of lines of code changed
18
COTS in embedded space systems
Requirements specification
Use knowledge of commercial technology, trends
System Requirements Review (SRR)
Establish realistic, low-risk cost goals Treat
cost as an independent variable (CAIV) Track
costs associated with each requirement Select
standards Select commercial off-the-shelf (COTS)
products Maintain configuration management (CM)
Preliminary Design Review (PDR)
Critical Design Review (CDR)
Adhere to open standards where possible Do not
use any undocumented features
Hardware and software development
Module test
Monitor current goals Maintain configuration
management (CM) Anticipate the need for
technology refresh Track trends technology
advances, software upgrades
Unit test
System test
System integration
19
Trojan horse COTS
Initially the software appears to be a COTS
product in a box, but then, suddenly, numerous
software engineers hop out of the box in the dead
of night to modify or upgrade the software and
then show you how to use it.
? Paul Graziani, President and CEO of Analytical
Graphics, Inc. (8/00)
20
Pernicious bug(insectus deleterius)
The safety-critical software bug was
difficult to diagnose, even during extensive
simulations following the catastrophic failure of
the mission. The problem appeared to have a mind
of its own, a kind of weird intelligence. It was
almost as if the bug had made a detailed study
of our source code to determine the one software
error that would produce the most enigmatic
results, and then inserted that error with
malicious precision so that under normal
operations the obscure consequences would occur
only once every six months. ? Embedded flight
systems software engineer
21
Faster, better, cheaper
One result of downsizing.
22
Impediments to quality software engineering

• Programmatic pressures
• Schedule constraints
• Inadequate manpower
• Cost ceiling
• Unnecessary documentation
• Personnel puzzles
• Finding / keeping skilled staff
• Staff attrition / turnover
• Staff motivation / morale
• Planning problems
• Inadequate requirements
• Requirements creep
• Inadequate test time / people / equipment
• Process poorly defined / followed

23
Staffing and motivating the flight software
development team
24
Rules of thumb for quality flight software

• Best designers 32 hours/week
• Three equal phases
• Requirements specification
• Implementation
• Testing and validation
• Independent of HLL
• Recognize good modules
• Small (fewer than 100 lines)
• Well-commented
• Small calling complexity

25
Three essential skills
Requirements specification
Testing and validation
Coding and implementation