nasa 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.