| name | jpl-design-principles |
| description | Software-relevant distillation of the JPL Design Principles (DP10, External Release V4). Use as a developer checklist when writing or modifying F Prime flight software, and as a reviewer reference for flagging JPL Design Principle violations in PRs. Keywords: JPL, design principles, flight software, margins, fault protection, testability, keep-it-simple, KISS, robustness.
|
Skill: JPL Design Principles — Software Distillation
Source: JPL Design Principles — "Design, Verification/Validation and
Operations Principles for Flight Systems" (DP10, External Release V4).
Numbering below mirrors the original document sections so every rule is
traceable.
Section 2 — Principles (software-relevant subset)
P-2.1.1 Enable Anomaly Investigations
Design and operate the mission so that future anomaly investigations
have the data needed to prevent recurrence — even if the mission is lost.
P-2.2.1 Mission Robustness
Protect threshold mission in the presence of flight system faults,
mission system faults, and operator errors. Stored critical data shall
be protected from loss due to credible fault scenarios.
P-2.2.3 Fault Protection Expectations
Fault protection preserves flight system health, safety, and
consumables throughout all mission phases, except when completion of
time-critical events takes priority.
P-2.2.5 Escapes
Take actions during I&T and operations to detect errors and reduce the
chance of escapes.
P-2.2.6 Test As You Fly
Test systems in conditions that match or exceed flight conditions; fly
systems within the bounds already tested.
P-2.3.1 Design for Ops
Develop the project and flight system keeping operational impacts of
design choices in mind. Encourage approaches that reduce operational
complexity and interdependencies (fewer calibrations, more on-board
autonomy, robust margins). Critical flight software parameter updates
shall have the same rigor as a full FSW update.
P-2.3.2 Unambiguous
Design flight and ground systems to set and know the state of the
flight system unambiguously.
P-2.3.3 Fault Avoidance
Take design action to avoid building-in known vulnerabilities.
P-2.3.6 Graceful Degradation
Build design robustness through graceful degradation following a
failure — incremental loss of capability such that a reduced set of
mission requirements is still met.
P-2.3.7 Fault Recovery
Full mission capability is retained or recovered following faults or
operator errors.
P-2.4.1 Technical Resource Margins for Operations
Preserve a portion of technical resource margins (power, memory,
throughput, bus bandwidth, delta-V) at launch to solve problems after
launch.
P-2.4.2 Reliability through Design Margins
Margins are established consistent with design maturity and mission
environments, accommodate "unknown unknowns," and enable changes with
minimal ripple effects.
P-2.5.1 Margins for Development
Manage development risk through margin establishment. Margins may
follow a glide slope (e.g., mass/power decrease over lifecycle) or be
set once (e.g., pointing/stability).
P-2.5.2 Avoid Local Optimization
Constrain the number and type of interfaces to avoid duplication of
design and testing effort at the system level.
P-2.6.1 Follow Identified Standards
Follow identified standards or practices (possibly with JPL
exceptions).
P-2.6.2 Follow Software Best Practices
Follow software best practices as mapped to Design Rules in Section
4.11.
Section 4 — Flight System Design Rules (software-relevant subset)
DR-4.1.3.1 Single Failure Tolerance
No single failure of any element shall result in failure to meet
threshold mission requirements. All single-point failures must be
identified.
DR-4.1.3.2 Protection Against Operator Errors
The design shall protect against ground operator errors that could
result in loss of mission or significant impact.
DR-4.4.4.4 Assured Commanding
Commanding functions shall be robust to power outages and degraded
communications (e.g., hardware command decoding, non-volatile memory).
DR-4.4.4.6 Commanding Reliability
Provide protection against all incorrect commands and against correct
but untimely commands that risk health/safety, initiate irreversible
state changes, threaten consumables, or jeopardize commandability.
DR-4.4.4.8 Onboard Command Processing Approach
Avoid direct memory location manipulation for command processing. Use
software functions to translate commands into actions.
DR-4.4.4.9 Two Independent Commands for Hazardous Events
Initiation of hazardous or mission-critical in-flight events shall
require at least two independent commands or actions.
DR-4.4.6.1 Visibility of S/C Status
Provide telemetry data to assess spacecraft status under normal,
stressed, and faulted operations — including health, anomaly
determination, and state visibility.
DR-4.4.6.4 Visibility of Spacecraft State
Permit ground operators to rapidly and unambiguously determine
spacecraft state, particularly fault protection responses, during the
first part of a tracking pass.
DR-4.4.6.8 Visibility to Reconstruct Faults
Provide visibility to support post-mortem analysis of activities with
potential for mission-catastrophic outcome.
DR-4.4.7.1 Clock and Counter Rollover
Spacecraft shall continue to operate in the event of rollover of
spacecraft clocks and/or incremental counters (hardware or software).
DR-4.9.1.2 Protection for Credible Single Faults
Fault protection shall handle all credible single faults within all
expected environmental conditions.
DR-4.9.1.5 Tolerance to False Alarms
The spacecraft shall tolerate execution of fault protection in response
to false alarms at all times throughout the mission.
DR-4.9.1.6 Variation in FP Behavior
Variations in fault protection behavior shall be based directly on
system mode or activity, not on individual enable/threshold
manipulation.
DR-4.9.1.7 Speed of Fault Detection and Response
Fault protection shall respond in a timely manner to identified threats
to health, safety, and/or mission success.
DR-4.9.2.2 Flight System Safing
Following fault conditions, fault protection shall autonomously
configure the spacecraft to a safe, sustainable, ground-commandable
mode preserving vital resources and providing at least an RF carrier
downlink.
DR-4.9.2.3 Autonomous Completion
For events that must execute without ground intervention, fault
protection shall endeavor to ensure autonomous, timely completion.
DR-4.9.3.1 In-Flight Commandability
Fault protection design shall permit ground operators to easily modify
control settings (enables, thresholds, persistence) in flight.
Section 4.11 — Flight Software System Design (complete)
DR-4.11.1.1.1 Documentation of Architecture Design
Document architectural elements, external interfaces, interfaces
between elements, element responsibilities, and interaction
constraints.
DR-4.11.1.1.2 Architectural Analysis of Quality Attributes
Architecture documentation shall include multiple views and support
evaluation of key quality attributes (performance, availability,
maintainability, modifiability, security, testability, usability).
DR-4.11.1.3 Semantics of Data Interfaces
Semantics of data across public interfaces shall be clearly specified
and, if possible, verified automatically at build time (range,
precision, units, coordinate frames).
DR-4.11.1.4 Compatibility with COTS Tools
Flight software shall operate on commercial platforms with little
change, so tests on those platforms are substantially relevant to V&V.
DR-4.11.1.5 Demonstrable Correctness Properties
Software should have demonstrable correctness properties supported by
appropriate static analysis techniques.
DR-4.11.2.1 Nominal Initialization
Flight software shall initialize software and hardware to a known,
safe, and deliberate state.
DR-4.11.2.2 Multiple Restart Initialization
Software shall detect off-nominal restarts and successively
reinitialize with less dependency on preserved state until a fully
known configuration and stable operation are restored.
DR-4.11.2.3 Minimalist Boot
Boot implementation shall include a minimalist configuration requiring
minimum on-board resources for vehicle safety and ground intervention.
DR-4.11.2.4 System Initialization Trace Telemetry
Flight software shall record and transmit its progress through each
initialization attempt.
DR-4.11.3.1 Use of Standards
Flight software shall employ applicable JPL standard products,
formats, interfaces, and processes.
DR-4.11.3.3 Parameter and Argument Specification
Parameters and arguments shall be specified in terms of their
attributes. Physical units and reference frames shall be specified and
checked for consistency (automatically where possible).
DR-4.11.4.2 Response to Incorrect Commands/Data/Memory
Flight software shall detect and respond safely to: (a) corrupted
commands, data, loads, and memory faults; (b) incorrectly formatted
data including invalid or out-of-range parameters; (c) commands/data
invalid in the current context.
DR-4.11.4.3 Protection from Unintended Software Modification
Flight software modifiable during flight shall be protected from
unintended modifications (operations errors, SEEs, hardware problems).
DR-4.11.4.5 Response to Resource Over-Subscription
Software shall contain a robust response when computer resources are
oversubscribed (buffer overflow, rate-group overrun, excessive
interrupts).
DR-4.11.4.6 Response to I/O Anomalies
Software shall tolerate and continue functioning when periodic inputs
are missing or I/O fails/completes unsuccessfully/is invalid.
DR-4.11.4.7 Use of Time-Outs
Software shall detect and respond appropriately to failures to
complete required activities on time (e.g., watchdog timers).
DR-4.11.4.11 Protection Against Incorrect Memory Use
Protect against execution in data areas, using code as data, and
unintended overwriting of code areas.
DR-4.11.4.12 Data Set Consistency
Ensure data sets and parameter lists are consistent when passed among
threads — no danger of using a mixture of old and new data.
DR-4.11.4.13 Thread-Safe Operations
Software shall be demonstrated free of deadlocks, failures to make
progress, race conditions, and other threats to multi-threaded
operations.
DR-4.11.4.14 Software Managed State Transitions
Avoid uncertain, unsafe, or hazardous consequential states during
software-managed state transitions. Account for all transition steps
and their timing; detect incomplete/interrupted transitions and
reinforce a known configuration.
DR-4.11.5.2 Design for Incremental Verification
Enable easy software testing at unit, module, subsystem-testbed, and
system-testbed levels including regression testing.
DR-4.11.5.4 Stress Testing
Software shall degrade with understandable behavior when stressed
beyond performance limitations (singularities, capability exceedance,
identified uncertainties).
DR-4.11.6.1 Self-Test Capability
Include capabilities to test operation and permit timely fault
diagnostics. If not removed for flight, test capabilities shall not
damage hardware or interfere with proper operation.
DR-4.11.6.2 Fault Diagnostics
Incorporate test/diagnostic code early (by PDR design, by CDR code),
accessible through flight interfaces for rapid problem resolution.
DR-4.11.6.3 Measurement of Constrained Resources
Provide easy and timely visibility into computing resource usage
(throughput, memory, bus utilization, stack headroom, cycle slip
statistics, fragmentation, memory leaks, allocation latency).
Section 6.3.5 — Flight Software Margins
DR-6.3.5.1 Margin Definitions
Margin = Capability − CBE. % Margin = 100% × (Margin / Capability).
DR-6.3.5.3 Margins at Key Milestones
| Milestone | Computer Selection | PDR | CDR | Launch |
|---|
| % Margin | 75% | 60% | (no spec) | 20% |
Applies to constrained resources: computing capacity, memory,
throughput, bus bandwidth, etc.
Section 8 — V&V (software-relevant subset)
DR-8.2.1 Subsystem Pre-Delivery Verification
All flight hardware and software shall be functionally verified to
conform to all allocated requirements prior to delivery to ATLO.
DR-8.3.2.2 Software Regression Testing
New flight software versions delivered to ATLO shall undergo
regression testing on the flight vehicle prior to use in system-level
verification.
DR-8.3.3.5 Phasing Test
Phasing tests in final flight configuration shall verify proper
operation of polarity-sensitive functions, including software.
Section 9 — Flight Operations (software-relevant subset)
DR-9.2.2 Post-Launch FSW Update Rigor
Post-launch FSW updates shall have the same rigor (review, testing,
safeguards, procedures) as pre-launch development, including
functional testing on a testbed.
DR-9.2.3 In-Flight Parameter Update
Critical on-board parameter updates shall have the same rigor as
pre-launch parameter selection, including testbed functional testing.
DR-9.5.1 Operating Margins for Real-Time Operations
Plan, maintain, and monitor operating margins for system resources
(power, thermal, comms links, computer memory, timing, throughput,
bus bandwidth, FP thresholds/persistences) in all flight activities.
