NASA Procedural Requirement (NPR) 7150.2D “NASA Software Engineering Requirements” outlines the software engineering and software management requirements for software development and acquisition within NASA (National Aeronautics and Space Administration). This NPR is a key reference for ensuring the quality, safety, and reliability of software used in NASA missions and projects, including embedded software.
NASA guidance documents relating to the development of embedded software fall into two groups – standards and procedural requirements. NPRs ensure that the processes and management aspects align with NASA’s goals.
NPR 7150.2D is therefore designed to ensure that software engineering and software management processes are so aligned.
According to the document itself, NPR 7150.2D applies to “NASA Headquarters (HQ) and NASA Centers, including Component Facilities and Technical and Service Support Centers.”
The document goes on to clarify that it may also be applicable to other parties “to the extent referenced in appropriate contracts, grants, or agreements”. Tailoring allows NPR 7150.2D to be applied by contractors as well as the NASA Center, and the document has specific guidelines for tailoring to make sure the best safety practices are applied to any programme that involves NASA.
NPR 7150.2D covers the complete development lifecycle. Its primary recommendations are subdivided into Software Management Requirements, and Software Engineering (Life Cycle) Requirements.
Chapter 3 of the document covers software management requirements. Its 12 subsections cover the following topics:
Chapters 4 and 5 of the document cover software engineering (life cycle) requirements, with the latter detailing supporting requirements. They are subdivided into 6 and 5 sections respectively:
In NPR 7150.2D, there are six classes. Software assigned to Class A is the most critical software. The rigor of the applicable testing and verification processes is proportionate to that criticality.
It is quite common for projects to include multiple systems and subsystems that have been assigned different classes.
Class A software is used for critical mission functions and systems where a software failure could result in the loss of human life or the failure of a mission.
Class B software is used for important mission functions but does not have the same level of criticality as Class A software. Failure of software in this category may have a significant impact on mission success but would not be expected to result in the loss of human life.
Class C software is used for support or R&D functions. It does not directly impact mission-critical systems or functions. Failures in Class C software are not expected to lead to mission failure or loss of life.
Class D software includes basic science & engineering design software, such as applications designed to perform secondary science data analysis, or tools used to support engineering development. Some airborne software falls into this category, including flight software for physically constrained UAVs.
Class E applies to Software developed to explore a design concept or hypothesis, or to perform minor desktop analysis of science or experimental data.
General purpose computing software used in support of the Agency and/or its Centers.
In general, the requirements dictated by the classification of a software system or subsystem dictate the level or rigor. However, it is possible to customize the specific software development and assurance requirements to meet the specific needs and risks associated with a particular software project within NASA.
To gain approval for tailoring requests, it is imperative to provide a rational and well-justified explanation, conduct a thorough risk assessment, and appropriately reference relevant source materials. In the illustration below, X indicates that the requirement is applicable.
Tailoring is an important aspect of this standard, particularly with regards to its adoption for commercial projects.
Although NPR 7150.2D is tailored to NASA Centers, its relevance extends beyond the agency’s boundaries. NASA frequently collaborates with contractors and vendors for the development of “Class A” Human-Rated Space Software Systems. It is anticipated that future Requests for Proposals (RFPs) will include requirements in alignment with this standard.
Tailoring is a key aspect of this standard and enables its adaptation for commercial purposes by balancing three key considerations:
A software component will be classified as safety critical software if it is identified by hazard analysis as fulfilling a role with the potential to cause, control, mitigate, or detect hazardous events or conditions. This classification signifies that the software has the potential to result in severe injury, significant damage, or mission failure.
Software assigned safety critical status will be subject to supplementary requirements later in the software development process.
NPR 7150.2D does not specify a preferred development lifecycle model like the V-model, Agile, or any other particular approach. Instead, it outlines high-level principles and requirements for software development processes, including activities such as software requirements, design, coding, testing, and maintenance. Each of those activities can be slotted into the lifecycle model of choice.
The practices and processes defined within the standard align with the eight primary software verification tasks supported by the LDRA tool suite: traceability verification and process standard objective management, static analysis (design, code, and quality reviews), unit testing, target testing, test verification (code coverage) and test management. Focus on all these key areas is required to achieve an organization’s software development and maintenance goals.
Like NPR 7150.2, LDRA makes a specific point of not specifying a preferred development lifecycle model. For example, it can support a V-model and the CI/CD approach typified by DevSecOps equally well.
The V-model diagram below shows how the different LDRA capabilities dovetail into the requirements laid down by the standard.
In general, NPR 7150.2D does not dictate specific code coverage metrics, and NASA software projects may establish their own code coverage requirements based on project-specific needs, safety, and criticality considerations.
An exception is the requirement for “100 percent code test coverage using the Modified Condition/Decision Coverage (MC/DC)” for code that is designated safety critical. Otherwise, project-specific requirements documents, guidelines, or standards may provide more detailed guidance on code coverage expectations.
NPR 7150.2D §3.7.5 requires “all identified safety-critical components to have a cyclomatic complexity of 15 or lower.” As illustrated below, the LDRA tool suite calculates cyclomatic complexity as part of its static analysis capabilities.
NPR 7150.2D §3.8.1 requires the “verification and validation of auto-generated source code using the same software standards and processes as hand generated code.”
The LDRA tool suite integrates with several different model-based development tools, including offerings from Ansys, IBM, and The MathWorks. “Back-to-back” testing involves first developing and verifying design models. Code is then generated by the development tool, instrumented by the LDRA tool suite, and executed in either Software in the Loop (SIL or host) mode, or Processor In the Loop (PIL or target) mode. Structural coverage reports are generated from the resulting data.
NPR 7150.2D §3.11 opines that “software defects are a central and critical aspect of computer security vulnerabilities. Software defects with cybersecurity ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.”
With that premise established, security issues are also mentioned as a prime motivator for many of the code quality-related precautions required throughout the standard.
Traceability of requirements is fundamental to most critical software development, and the space applications referenced by NPR 7150.2D are no exception. The maintenance of the resulting traceability matrix represents a real headache for many project managers.
The TBmanager component of the LDRA tool suite is designed to address that pain-point by automating bidirectional traceability.
The LDRA tool suite also supports the traceability of implemented code to software architecture and design by means of its design review capabilities.
NPR 7150.2D §4.2.3 requires “A documented software architecture that describes: the software’s structure; identifies the software qualities…identifies the known interfaces between the software components and the components external to the software…identifies the interfaces between the software components and identifies the software components.”
NPR 7150.2D §4.2.4 requires “The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.”
The LDRA tool suite’s design review performs an analysis of the structure, control flow and data flow of source code, presenting the results graphically or textually and greatly enhancing design conformance (or non-conformance) review.
NPR 7150.2D §4.4.4 requires that “The project manager shall use static analysis tools to analyze the code during the development and testing phases to, at a minimum, detect defects, software security, code coverage, and software complexity.”
The static and dynamic capabilities of the LDRA tool suite provide a means of analysis to fulfil each of those objectives. The TBvision component provides the means to achieve static analysis and contribute to the detection of defects, software security, and software complexity. TBvision in tandem with TBrun, the unit test component of the LDRA tool suite, perform the required code coverage analysis.
NPR 7150.2D §4.5 requires unit test results that are repeatable, that run on the targeted platform or simulator, and that can be regressed.
The TBrun component of the LDRA tool suite is designed to perform unit test activities, and supports on-target and on-simulator testing.
NPR 7150.2D §4.4.8 & §4.5.6 require that software test tools are validated. TÜV approval of LDRA’s software test tools underpins the capabilities of the products, and their capacity to meet the exacting demands of the world’s predominant functional safety standards.
Should accreditation be required for the LDRA tool suite in the context of the project-specific tool chain, LDRA’s TQSPs provide the appropriate resources to make that process as seamless as possible. Although designed by experts from the civil aviation sector, the approach detailed in the DO-330 document is sector-agnostic.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707