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

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.