# Jpl Design Principles > 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: `nasa/jpl-design-principles` (Agent Skill) - Install (CLI): `npx skillmds@latest add nasa/jpl-design-principles` - Raw SKILL.md: https://api.skillmd.com/api/skills/nasa/jpl-design-principles/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: nasa (https://skillmd.com/u/nasa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/nasa/jpl-design-principles --- # 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.