The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to https://swehb.nasa.gov/display/SWEHBVC/9.01+Software+Design+Principles. If you do not get there in 2 seconds, click the link to go there.
See edit history of this section
Post feedback on this section
1. Software Principles at NASA
- The software design principles presented here represent a consensus view of best practices in the design of mission-critical Class A and B software at NASA. They were selected with participation from several Centers, representing the major disciplines in embedded real-time software: launch systems, manned systems, and robotic missions.
- The design principles focus on features and characteristics that are typically found in high-quality embedded software applications. They should be familiar to the experienced embedded software professional. However, they include only those principles that were deemed common across all Centers and disciplines. In the course of development, many good ideas were not selected for inclusion because they were specific to a particular mission or application type. However, application-specific approaches and interpretations are included in the discussion section accompanying each principle to convey the kinds of variations that might be introduced.
- It is important to understand what the design principles are, and what they are not. They are a distillation of decades of experience in the kind of embedded software that has enabled NASA’s most spectacular achievements. They can be used as a source of design criteria both in development and at review time. Training materials for new developers can draw upon them. Individual projects and organizations can use them as a reference in the development and implementation of local standards and processes.
- The design principles are not requirements. They do not supersede design principles already in place at NASA Centers. There is no requirement to justify using a different set of design standards, nor are waivers for deviation from the principles required. The design principles here are not a complete statement about what makes for good embedded software design. Organizations and projects that choose to adopt them are encouraged to tailor and elaborate these principles to their specific situation.
1.1 Structure of the Software Principle Topics
Principle statements are deliberately brief to avoid including the detail that might not be universally applicable. Each principle has a short rationale that expresses why it was considered important enough to include in the Agency-wide set of design principles.
Following this is a section entitled “Examples and Discussion” that elaborates on the principle. Depending on the topic, this section may provide life cycle guidance, discussion of techniques commonly used to implement the principle, and implementation considerations.
When applicable entries from the NASA Lessons Learned 439 database are available, links to these entries are also included in the Examples and Discussion section. Lessons Learned often highlight a subtle aspect of a design principle or identify an opportunity to consider how the application of a principle might have helped avoid an incident. In a handful of cases, there are positive lessons learned that support adoption of the related principle.
Each principle was derived from one or more source materials. Where this material is not included in the Examples and Discussion section, it is included in a concluding section entitled “Inputs”. Inputs may be from works in progress furnished to the team, or from official standards. The Center responsible for the input material is identified by a subheading preceding that Center’s material.
Each principle has the same basic structure:
- Principle and Rationale - a simple statement of the principle together with a short explanation of why the principle is important.
- Examples - detailed description and discussion of the principle from an engineering perspective. Includes an analysis of the supporting data.
- Inputs - Additional material usually from one or more Centers. Includes Center specific application of the principle.
- Resources - List of resources referenced in one or more tabs on the page, with links to the actual reference.
- Lessons Learned - descriptions and links to the appropriate Lessons Learned referenced on the page.
Links to Software Design Principles
Title | Software Design Principle |
---|---|
9.03 Coding Standards | Implement a "secure" coding standard on all mission-critical software. |
9.04 Command Receipt Acknowledgement | Design software to send a positive acknowledgement of command receipt. |
9.05 Data Interface Integrity | Design software to verify the integrity of all inputs and outputs in the control system |
9.06 Dead Code Exclusion | Establish a policy for eliminating unreachable code or mitigating the risk of any unreachable code. |
9.07 Fault Detection and Response | In the software design, provide mechanisms to detect credible system faults and to react to these faults according to a pre-described plan. |
9.08 Flight Software Modification | Include in the software design the capability for commanding modification of the software, and for preventing unwanted modifications. |
9.09 Incorrect Memory Use or Access | Design software to protect against incorrect use of memory. |
9.10 Initialization - Safe Mode | Design flight software to initialize software and hardware to a known, safe, and deliberate state |
9.11 Invalid Data Handling | Design software to handle invalid data appropriately. |
9.12 Resource Margins | Establish and maintain quantitative margins for all critical resources, allowing for maturation of usage estimates through the life cycle. |
9.13 Resource Oversubscription | Include a robust and well thought out response to resource oversubscription situations in the software design. |
9.14 Resource Usage Measurement | Incorporate timely visibility into the use of computing resources into the software design. |
9.15 Safe Transitions | Assert required preconditions and post-conditions at software transitions. |
9.16 Thread Safety | Design interaction between threads to prevent inappropriate interference. |
9.17 Toggle Commands | Design both internal and external commanding to place the system into an explicitly specified state. |
1.2 Support for NASA Software Safety Standard
- The NASA software design principles provide considerable support for the implementation of the NASA software safety requirements found in the NASA Procedural Requirement for software engineering (NPR 7150.2, SWE-134 ). It may be possible to demonstrate compliance for the design-related parts of the requirement through verified adherence to the design principles. See 9.02 Software Safety and Design Principles for a compliance matrix and discussion.
2.1 References
- (SWEREF-439) The NASA Lessons Learned system. The system provides access to official, reviewed lessons learned from NASA programs and projects.
- (SWEREF-670) ARC - APR 8070.1 This document defines engineering design and environmental test requirements and guidelines for Class C and D space flight systems.
- (SWEREF-671) JPL: DocID 43913, Rev. 1
- (SWEREF-672) GSFC-STD-1000F, Approved: 02-08-2013 - With Administrative Changes , Expiration Date: 02-08-2018, Superseding GSFC-STD-1000E
Caveat on using JPL rules:
Some of you may be interested in viewing standards recently made available to NASA civil servants. They are JPL Flight Project Practices; JPL Design, Verification/Validation & Ops Principles for Flight Systems (Design Principles); and JPL Systems Engineering Practices. Please keep in mind that these documents are labeled as confidential/proprietary and should be handled according to SBU procedures. JPL has lessons learned infusion process that cross-references lessons learned directly to JPL’s two mandatory core engineering standards – and you might be interested in reviewing the JPL process as guidance for your Centers lessons learned infusion.