Page History
| Tabsetup | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
...
4.1 Software Assurance Description
4.1.1 Software assurance is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life-cycle, and that the software functions in an intended manner and that the software does not function in an unintended manner. The objectives of the Software Assurance and Software Safety Standard include:
a. Ensuring that the processes, procedures, and products used to produce and sustain the software conform to all requirements and standards specified to govern those processes, procedures, and products.
b. Ensuring that the software systems are safe and that the software safety-critical requirements and processes are followed.
c. Ensuring that the software systems are secure.
4.1.2 Project and SMA Management support of the software assurance function is essential for software assurance processes to be effective. The software assurance support minimally includes:
a. Management is familiar with and understands the software assurance function’s purposes, concepts, practices, and needs.
b. Management provides the software assurance activities with a level of skilled resources (people, equipment, knowledge, methods, facilities, and tools) to accomplish their project responsibilities.
c. Management receives and acts upon information provided by the software assurance function throughout a project.
4.1.3 The Software Assurance and Software Safety Standard’s requirements apply to organizations in their roles as both acquirers and providers. A single organization can use the standard in a self-imposed mode or in a multi-party situation. The same organization or different organizations can implement the Software Assurance and Software Safety Standard’s requirements, and the job can originate from a Memorandum of Agreement, Memorandum of Understanding, or a contract.
4.2 Safety-Critical Software Determination
4.2.1 Software is classified as safety-critical, if it meets at least one of the following criteria:
a. Causes or contributes to a system hazardous condition/event,
b. Provides control or mitigation for a system hazardous condition/event,
c. Controls safety-critical functions,
d. Mitigates damage if a hazardous condition/event occurs,
e. Detects, reports, and takes corrective action, if the system reaches a potentially hazardous state.
| Note |
|---|
Software is classified as safety-critical if the software is determined by and traceable to hazard analysis. See appendix A for guidelines associated with addressing software in hazard definitions. See SWE-205. Consideration for other independent means of protection (software, hardware, barriers, or administrative) should be a part of the system hazard definition process. |
4.3 Software Assurance and Software Safety Requirements
4.3.1 The responsible project manager shall perform the software assurance and software safety activities defined in Table 1 per the requirements marked applicable in the software engineering requirements mapping matrix for the software component. (SASS-01) In this document, the phrase “Software Assurance and Software Safety Tasks” means that the roles and responsibilities for completing these requirements may be delegated within the project consistent with the scope and scale of the project. The Center SMA Director designates SMA TA(ies) for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency software assurance and software safety activities.
Table 1. Software Assurance and Software Safety Requirements Mapping Matrix
...
1. Confirm that the options for software acquisition versus development have been evaluated.
2. Confirm the flow down of applicable software engineering, software assurance, and software safety requirements on all acquisition activities. (NPR 7150.2 and NASA-STD-8739.8).
3. Assess any risks with acquisition versus development decision(s).
...
1. Confirm that all plans are in place, and have expected content for the life-cycle events, with proper tailoring for the classification of the software.
2. Develop a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety.
...
1. Confirm the following are approved, implemented, and updated per requirements:
a. Software processes, including software assurance, software safety, and IV&V processes.
b. Software documentation plans,
c. List of developed electronic products, deliverables, and
d. List of tasks required or needed for the project’s software development.
2. Confirm that any required government actions upon receipt of deliverables (e.g., approvals, reviews) are established and maintained.
...
The project manager shall satisfy the following conditions when a Commercial-Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), Modified Off-The-Shelf (MOTS), Open Source Software (OSS), or reused software component is acquired or used:
a. The requirements to be met by the software component are identified.
b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).
c. Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights have been addressed.
d. Future support for the software product is planned and adequate for project needs.
e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.
f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.
...
If software IV&V is performed on a project, the project manager shall ensure an IPEP is developed, negotiated, approved, maintained, and executed.
...
The project manager shall perform, record, and maintain bi-directional traceability between the following software elements:
...
4.4 Independent Verification &Validation (IV&V)
The requirements in the IV&V section are applicable to all IV&V efforts performed on a software development project, as tailored by the IV&V Project Execution Plan. It also serves as the definition of what NASA considers to be IV&V. IV&V is a risk mitigation activity, and as such, the application of IV&V analysis and the rigor of that analysis is driven by the IV&V Provider’s assessment of software risk.
4.4.2 IV&V Overview
4.4.2.1 IV&V is a technical discipline of software assurance, which employs rigorous analysis and testing methodologies identifying objective evidence and conclusions to provide a second independent assessment of critical products and processes throughout the life-cycle. The secondary evaluation of products and processes throughout the life-cycle contributes to the demonstration of whether the software is fit for nominal operations (required functionality, safety, dependability, etc.), and off-nominal conditions (response to faults, responses to hazardous conditions, etc.). The goal of the IV&V effort is to contribute to the assurance conclusions to the project and stakeholders based on evidence found in software development artifacts and risks associated with the intended behaviors of the software.
4.4.2.2 Three parameters define the independence of IV&V: technical independence, managerial independence, and financial independence.
a. Technical independence requires that the personnel performing the IV&V analysis are not involved in the development of the system or its elements. The IV&V team establishes an understanding of the problem and how the system addresses the problem. It is through technical independence that the IV&V team’s different perspective allows it to detect subtle errors overlooked by those personnel focused on developing the system.
b. Managerial independence requires that the personnel performing the IV&V analysis are not in the same organization as the development and program management team. Managerial independence also means that the IV&V team makes its own decisions as to which segments of the system and its software to analyze and test, chooses the IV&V analysis methods to apply, and defines the IV&V schedule of activities. While being independent from the development and program management organization, the IV&V team does provide its findings, in a timely manner, to both of those organizations. The submission of findings to the program management organization should not include any restrictions (e.g., requiring the approval of the development organization) or any other adverse pressures from the development group.
c. Financial independence requires that the control of the IV&V budget be vested in a group independent of the software development organization. Financial independence does not necessarily mean that the IV&V team controls the budget, but that the finances should be structured so that funding is available for the IV&V team to complete its analysis or test work. No adverse financial pressure or influence is applied.
4.4.2.3 The IV&V process starts early in the software development life-cycle, providing feedback to the Provider organization, allowing them to modify products at optimal timeframes and in a timely fashion, thereby reducing overall project risk. The feedback also answers project stakeholders’ questions about system properties (correctness, robustness, safety, security, etc.) so they can make informed decisions with respect to the development and acceptance of the system and its software.
4.4.2.4 The IV&V Provider performs two primary activities, often concurrently: verification and validation. Each of the activities provides a different perspective on the system/software. Verification is the process of evaluating a system and its software to provide objective evidence as to whether or not a product conforms to the build-to requirements and design specifications. Verification holds from the requirements through the design and code and into testing. Verification seeks to demonstrate that the products of a given development phase satisfy the conditions imposed at the start of or during that phase. Validation tasks, on the other hand, seek to develop objective evidence that shows that the content of the engineering artifact is the right content for the developed system/software. The content is accurate and correct if the objective evidence demonstrates that it satisfies the system requirements (e.g., user needs, stakeholder needs, etc.), that it fully describes the required capability/functionality needed and that it solves the right problem.
4.4.2.5 The center of the IV&V effort is on the discovery of objective evidence that supports the correct operation of the system or refutes the correct operation of the system. To understand this objective evidence, the IV&V provider typically works with the development team, which provides artifacts such as concept studies, operations concepts, and requirements that define the overall project. The IV&V provider uses these materials to develop an independent understanding of the project’s commitment to NASA, which then forms the basis for validation of lower-level technical artifacts.
4.4.2.6 Two principles help guide the development and use of objective evidence.
a. Performing IV&V throughout the entire development lifetime is the first principle; potential problems should be detected as early as possible in the development life-cycle. Performing IV&V throughout the entire development lifetime provides the IV&V team with sufficient information with which to establish a basis for the results of the analysis and provides early objective evidence to the development and program management groups to help keep the development effort on track early in the life-cycle.
b. The second principle is “appropriate assurance.” Given that it is not possible to provide IV&V on all aspects of a project’s software, the IV&V provider and project should balance risks against available resources to define an IV&V program for each project that will provide IV&V so that the software will operate correctly, safely, reliably, and securely throughout its operational lifetime. The IV&V Project Execution Plan will document this tailored approach and summarize the cost/benefit trade-offs made in the scoping process.
4.4.2.7 The requirements in the IV&V section are analyzed and partitioned according to the type of artifact. The requirements do not imply or require the use of any specific life-cycle model. It is also important to understand that IV&V applies to any life-cycle development process. The requirements in the IV&V section document the potential scope of analysis performed by the IV&V Provider and the key responsibility of the software project to provide the information needed to perform that analysis. Additionally, scoping the IV&V analysis is according to the application of the risk assessment to determine the prioritization of tasks and the level of rigor associated with performing those tasks. The scoping exercise results are captured in the IV&V Project Execution Plan, as documented below.
4.4.3 IV&V Planning/Management/Program Execution.
4.4.3.1 The IV&V Provider shall: (SASS-02)
a. Conduct an initial planning and risk assessment effort to determine the specific system/software behaviors (including the software components responsible for implementing the behaviors) to be analyzed, the IV&V tasks to be performed, the rigor to be applied to the tasks, and any tailoring of the requirements in this standard to be applied to the IV&V effort.
| Note |
|---|
Note: IV&V is a focused activity that prioritizes IV&V analysis to address the highest developmental and operational software risks. IV&V priority is based on the combination of the potential for software impacts to safety and mission success and the probability factors for latent defects. IV&V analysis tasks provide coverage with a degree of rigor that reflects the priority level. The initial planning and scoping effort based on the risk assessment define the starting point for the IV&V analysis. The planning and scoping effort also aid in establishing the initial relationships between the IV&V Provider, the Acquirer, and the Provider. |
b. Develop and negotiate with the project an IV&V Execution Plan documenting the activities, methods, level of rigor, environments, tailoring (if any) of these requirements, and criteria to be used in performing verification and validation of in-scope system/software behaviors (including responsible software components) determined by the planning and scoping effort.
| Note |
|---|
Note: A provider should use a documented analysis approach to track and manage the IV&V effort in alignment with on-going development project efforts. The IV&V Project Execution Plan documents which software products will be subject to which analyses, and which analysis requirements will be fully, partially, or not applied following the risk assessment and resource constraints. The IV&V plan also serves as a communication tool between the project and IV&V to set expectations for the IV&V products produced throughout the life-cycle. |
c. Provide analysis results, risks, and assurance statements/data to all the responsible organizations’ project management, engineering, and assurance personnel.
| Note |
|---|
Note: While independent, the IV&V Provider is still a part of the overall safety and risk mitigation software assurance strategy for a project. The results of IV&V analysis need to be incorporated into the overall software assurance assessment of the project as well as provided to the project management. |
d. Participate in project reviews of software activities by providing status and results of software IV&V activities including, but not limited to, upcoming analysis tasks, artifacts needed from the project, the results of the current or completed analysis, defects, and risks to stakeholders, customers, and development project personnel.
| Note |
|---|
Note: The most significant positive impact of IV&V analysis is when the analysis results are in phase with the development effort. Communicating defects after development artifacts are baselined increases the cost to make the changes. Additionally, the inclusion of the IV&V Provider in ongoing technical meetings keeps the IV&V Provider informed of possible changes that may affect future IV&V tasking. Supporting the ongoing technical meetings allows the IV&V Provider an opportunity to provide real-time feedback on these changes. |
e. Participate in planned software peer reviews or software inspections and record peer review measurements guided by the planning and scoping risk analysis documented in the IV&V Project Execution Plan as well as by the content of the items being reviewed or inspected.
| Note |
|---|
Note: The IV&V Provider should be involved in the review/inspection process for all system/software items within the scope of their analysis. |
f. Establish, record, maintain, report, and utilize software management and technical measurements.
g. Assess and track the actual results and performance of software activities against the software plans and identify and report any risks or findings.
h. Track and evaluate changes to software products to evaluate for possible changes in the IV&V Provider’s risk analysis as well as for potential adverse impacts to the software system and the development effort.
i. Assess the software development lifecycle for suitability for the problem to be solved, and identify and communicate any risks associated with the chosen life cycle.
j. Identify, analyze, track, communicate, and record risks to the software and development project in accordance with NPR 8000.4, Agency Risk Management Procedural Requirements.
k. Track, record, and communicate defects/issues and other results found during the execution of IV&V analysis during the software development effort to include issues and results found during the conducting of independent IV&V testing.
4.4.3.2 IV&V Work during Concept Development. The IV&V Provider shall verify and validate that the concept documentation represents the delineation of a specific implementation solution to solve the Acquirer’s problem. (SASS-03)
| Note |
|---|
Note: The objective of Concept IV&V is to understand the selected solution and to validate the role of software as it relates to providing the capability(ies) that support high priority or high-risk system capability(ies). |
a. Ensure that software planned for reuse meets the fit, form, and function as a component within the new application.
b. Ensure that the system architecture contains the computing-related items (subsystems, components, etc.) to carry out the mission of the system and satisfy user needs and operational scenarios or use cases.
c. Ensure that a basis for the engineering and planning of computing-related functions is the operations, mission objectives (including mission retirement), and the system.
d. Ensure that feasibility and trade studies provide the results to confidently support the critical decisions that drove the need for the study.
e. Identify and document the known software-based hazard causes, hazard contributors, and hazard controls.
f. Identify and document software-based security threats and risks, and the project implements the relevant regulatory requirements.
4.4.3.3 IV&V Work during Requirements Development. The IV&V Provider shall verify and validate: (SASS-04)
a. That the project implements the requirements for software listed in NPR 7150.2 (SWE-134), and risk-driven assessments determine the types of IV&V analyses.
b. That the in-scope software requirements and system requirements are, at a minimum, correct, consistent, complete, accurate, readable, traceable, and testable.
| Note |
|---|
Note: Software usually provides the interface between the user and the system hardware as well as the interface between system hardware components and other systems. These interfaces are critical to the successful operation and use of the system. |
c. That the project-identified mitigations for identified security risks are in the software requirements.
| Note |
|---|
Note: Security is an essential aspect of any system development effort. In most systems, software provides the primary user interface. The user interface is an element of the system that can provide undesired access. A system concept design should address known security risks through various features in the system. |
d. That the project-identified mitigations for identified security risks are correct and testable.
4.4.3.4 IV&V Work during Design. The IV&V Provider shall verify and validate: (SASS-05)
a. That the relationship between the in-scope system/software requirements and the associated architectural elements is traceable correct, consistent, and complete.
| Note |
|---|
Note: Architectural elements are responsible for implementing specific behaviors within the software and the overall system. It is the interactions between these architectural elements that result in the realization of the desired behaviors as well as possible undesired behaviors. |
b. That the software architecture meets the user’s safety and mission-critical needs as defined in the requirements.
| Note |
|---|
Note: The architecture provides the foundation for the development of the software. It also significantly impacts how the software deals with faults and failures, as well as how the software interfaces with the user and system components. Analysis of the architecture provides early insight into how the software is structured and how that structure can implement the requirements. |
c. That the detailed design products are traceable, consistent, complete, accurate, and testable.
| Note |
|---|
Note: Detailed design is the implementation of the algorithms that will control and monitor the different parts of the system as well as allow for interaction between the system and the user and other systems. The detailed design defines how the architectural components will behave to support the interactions defined in the architecture. Analysis of the detailed design includes looking at the low-level software components in the software system. |
d. That the interfaces between the detailed design components and the hardware, users, operators, other software, and external systems are correct, consistent, complete, accurate, and testable.
| Note |
|---|
Note: While the architecture defines the interactions between the architectural elements, each element is generally composed of lower-level components defined by the detailed design. The interfaces between these components are important in ensuring that the architectural element meets its assigned responsibilities. |
e. That the relationship between the software requirements and the associated detailed design components is correct, consistent, and complete.
| Note |
|---|
Note: The detailed design components capture the approach to implementing the software requirements, including the requirements associated with fault management, security, and safety. Analysis of the relationship between the detailed design and the software requirements provides evidence that all of the requirements are in the detailed design. |
4.4.3.5 IV&V Work during Implementation. The IV&V Provider shall verify and validate: (SASS-06)
a. That the software code products are consistent with architecture, complete with respect to requirements, and testable.
b. That the software code meets the project software coding standard.
c. That the security risks in the software code are identified and mitigated.
d. Analysis to assess the source code for the presence of open-source software including ensuring that the project has identified all open-source software used, the use of the open-source software is consistent with any licensing requirements and that the security risks are identified and mitigated by the use of the open-source software.
e. That software problem reports generated by the IV&V provider have been addressed entirely by the project.
f. That the project assesses the software systems for possible security vulnerabilities and weaknesses.
g. That the project implements the required software security risk mitigations to ensure that security objectives for software are satisfied.
h. The source code through the use of analysis tools (including but not limited to static, dynamic, and formal analysis tools).
| Note |
|---|
Note: The use of analysis tools may include the verification and validation of the results of the analysis tools used by the development project in the process of developing the software. |
i. That the relationship between the software design elements and the associated software units is correct, consistent, and complete.
j. That the relationship between software code components and corresponding requirements is correct, complete, and consistent.
| Note |
|---|
Note: For all of the implementation requirements, it is with code that the development of software reaches its lowest level of abstraction and that the software capabilities are implemented. Evaluating the relationship between the source code and the design components and requirements provides evidence that only the specified requirements and components are in the system. Evaluating the relationship between the source code and the design components and requirements helps to minimize one aspect of the emergence of unexpected behaviors: inclusion of behaviors not specified in the requirements. The overall analysis of the code is essential in assuring that the code does implement the required software behaviors. From a safety perspective, it is important to evaluate the code and assure that known software safety and security issues such as buffer overflows and type mismatches, among many others, are not used in safety-critical aspects of the software. |
4.4.3.6 IV&V Work during Testing. The IV&V Provider shall: (SASS-07)
a. Verify and validate that test plans, test procedures, test cases, test environment (including simulations), and test design at all levels of testing (unit, integration, system, acceptance, etc.) are correct, complete, and consistent for verification and validation of the source code and system functions allocated to the software.
b. Verify and validate that the relationships between the test plans, test procedures, test cases, and test design and source code and system functions allocated to the software are correct, complete, and consistent.
c. Verify that the test plans, test cases, test design, and test procedures contain objective acceptance criteria that support the verification of the associated requirements for both nominal and off-nominal conditions.
d. Verify that the software test results meet the associated acceptance criteria to ensure that software correctly implements the associated requirements.
| Note |
|---|
Note: The IV&V Provider assesses the testing artifacts within the context of the system’s meaning concerning the desired capabilities and expected operational system environment. The assessment includes an examination of testing at system boundary conditions to include unexpected conditions. The testing analysis assures that the project tests all of the requirements and that the system does what the requirements state it should do. The testing analysis also includes analysis of the traceability information between the tests and the requirements. |
e. Verify that the project tests the required software security risk mitigations to ensure that the security objectives for the software are satisfied.
4.4.3.7 IV&V Work during Operations/Maintenance. The IV&V Provider shall assess the software maintenance plan concerning software elements to support the planning of IV&V activities during the maintenance phase. (SASS-08)
| Note |
|---|
Note 1: The approach to software development on some projects results in different parts of the software going into operation at different times in the overall project life-cycle. For example, a lander mission to Mars may complete the software needed for the cruise phase to Mars while continuing to work on the entry, descent, landing, and surface operations software. Some software may also have an extended lifetime such that operational updates are anytime during the operational use of the software. |
| Note |
|---|
Note 2: In some cases, software anomalies will cause changes to the software. The use of IV&V is important in that changes to software can often have ripple effects throughout the system as well as cause emergent behaviors. The IV&V analysis provides insight into these possible effects as well as providing an overall assessment of the impact of the change. |
4.5 Principles Related to Tailoring the Standard Requirements
4.5.1 Software requirements tailoring is the process used to seek relief from standard requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, application of these requirements to specific software assurance, software safety, and IV&V efforts may be tailored where justified and approved. NASA established the TA governance model to approve and mitigate any changes to the application of the requirements in the Software Assurance and Software Safety Standard. Tailoring from requirements in the Software Assurance and Software Safety Standard is governed by the following requirements. Tailoring at the Center level is to be decided by the SMA TA and the NPR 7150.2 requirements mapping matrix applicability. Tailor the software assurance, software safety, and IV&V requirements using the following levels:
a. The first level of tailoring is the Software Classification Decision, see NPR 7150.2.
b. The second level of tailoring is the tailoring in the project’s Software Requirements Mapping Matrix, see NPR 7150.2.
c. The third level of tailoring is the tailoring by the Software Assurance TA of the Software Assurance and Software Safety Standard requirements that correspond to the project’s Software Requirements Mapping Matrix requirements.
4.5.2 The Software Assurance and Software Safety Standard establishes a baseline set of requirements for software assurance, software safety, and IV&V to reduce risks on NASA projects and programs. Each project has unique circumstances, and tailoring can be employed to modify the requirements set for software assurance, software safety, and IV&V effort. Determining the tailoring of requirements is a joint software engineering effort and SMA effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts.
4.5.3 Per SWE-121, the software assurance organization maintains a requirements mapping matrix or multiple requirements mapping matrices against requirements in the Software Assurance and Software Safety Standard, including those delegated to other parties or accomplished by contract vehicles. Per SWE-013 and SWE-039, the software assurance organization conducts risk assessment efforts to determine the software assurance, software safety, and IV&V tasks to be performed, and the rigor of each task. The software assurance organization will develop, maintain, and execute plans and procedures that cover the entire software life-cycle and, as a minimum, address the requirements of the Software Assurance and Software Safety Standard with approved tailoring.
4.5.4 The approval of the Software Assurance and Software Safety Standard tailoring is determined by the SMA management at the Center Level in conjunction with the project. The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that justifies supporting acceptance. The organization submitting the tailoring request informs the next higher level of involved management of the tailoring request in a timely manner. The dispositioning organization reviews the request with the other organizations that could be impacted or have a potential risk (i.e., to safety, quality, cybersecurity, health) with the proposed changes; and obtains the concurrence of those organizations.
4.5.5 The Center SMA TA shall review and agree with any tailored Software Assurance and Software Safety Standard requirements. (SASS-09)
4.5.6 If a system or subsystem development evolves to meet a higher or lower software classification as defined in NPR 7150.2 then the software assurance, software safety, and IV&V organizations shall update their plan(s) to fulfill the applicable requirements per the Requirements Mapping Matrix and any approved changes, and initiate adjustments to applicable contracts to meet the modified requirements. (SASS-10)
4.5.7 The responsibilities for approving changes to the software engineering requirements are in the NPR 7150.2. When the requirement and software class are applicable, the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix.
Appendix A GUIDELINES FOR THE HAZARD DEVELOPMENT INVOLVING SOFTWARE
...
A.1.1 Hazard Analysis should consider software’s ability, by design, to cause or control a given hazard. It is a best practice to include the software within the system hazard analysis. The general hazard analysis should consider software common-mode failures that can occur in instances of redundant flight computers running the same software.
A.1.2 Software Safety Analysis supplements the system hazard analysis by assessing the software performing critical functions serving as a hazard cause or control. The review assures compliance with the levied functional software requirements, including SWE-134. The software should not violate the independence of hazard inhibits, and the software should not violate the independence of hardware redundancy. The Software Safety Analysis should follow the phased hazard analysis process. A typical Software Safety Analysis process begins by identifying the must work and must not work functions in Phase 1 hazard reports. The system hazard analysis and software safety analysis process should assess each function, between Phase 1 and 2 hazard analysis, for compliance with the levied functional software requirements, including SWE-134. For example, Solar Array deployment (must work function) software should place deployment effectors in the powered off state when it boots up and requires arm and fire commands in the correct order within 4 CPU cycles before removing a deployment inhibit. The analysis also assesses the channelization of the communication paths between the inputs/sensors and the effectors to assure there is no violation of fault tolerance by routing a redundant communication path through a single component. The system hazard analysis and software safety analysis also assures the redundancy management performed by the software supports fault tolerance requirements. For example, software can’t trigger a critical sequence in a single fault-tolerant manner using a single sensor input. Considering how software can trigger a critical sequence is required for the design of triggering events such as payload separation, tripping FDIR responses that turn off critical subsystems, failover to redundant components, and providing closed-loop control of critical functions such as propellant tank pressurization.
A.1.3 The design analysis portion of software safety analysis should be completed by Phase 2 safety reviews. At this point, the software safety analysis supports a requirements gap analysis to identify any gaps (SWE-184) and ensuring the risk and control strategy documented in hazard reports are correct, as stated. Between Phase 2 and 3 safety reviews, the system hazard analysis and software safety analysis supports the analysis of test plans to assure adequate off-nominal scenarios (SWE-62, SWE-65a). Finally, in Phase 3, the system hazards analysis should verify the final implementation and verification upholds the analysis by ensuring test results permit closure of hazard verifications (SWE-68) and that the final hazardous commands support the single command and multi-step command needs and finalized pre-requisite checks are in place.
A.1.4 The following section includes useful considerations and examples of software causes and controls:
a. Does software control any of the safety-critical hardware?
b. Does software perform critical reconfiguration of the system during the mission?
c. Does the software perform redundancy management for safety-critical hardware?
d. Does the software determine when to perform a critical action?
e. Does the software trigger logic to meet failure tolerance requirements?
f. Does the software monitor hazard inhibits, safety-critical hardware/software, or issue a caution and warning alarm used to perform an operational control?
g. Does the software process or display data used to make safety-critical decisions?
h. Does the flight or ground software manipulate hazardous system effectors during prelaunch checkouts or terminal count?
i. Does the software perform analysis that impacts automatic or manual hazardous operations?
j. Does the software serve as an interlock preventing unsafe actions?
k. Does the software contain stored command sequences that remove multiple inhibits from a hazard?
l. Does the software initiate any stored command sequences, associated with a safety-critical activity?
m. Does software violate any hazard inhibits or hardware redundancy independence (channelized communication/power paths, stored command sequences/scripts, FDIR false positive, etc.)?
n. Can the software controls introduce new hazard causes?
o. Are the software safety-critical controls truly independent?
p. Can common cause faults affect the software controls?
q. Can any of the software controls used in operational scenarios cause a system hazard?
r. Does the software control switch-over to a backup system if a failure occurs in a primary system?
s. Is the software that makes safety-critical decisions fault-tolerant?
t. Does the software provide an approach for recovery if the system monitoring functions fail?
u. Does the software allow the operators to disable safety-critical controls unintentionally?
v. Does the software provide safety-critical cautions and warnings?
w. Is the software capable of diagnosing and fixing safety-critical faults that might occur in operations?
x. Does the software provide health and status of safety-critical functions?
y. Does the software process safety-critical commands (including autonomous commanding)?
z. Can software that provides full or partial verification or validation of safety-critical systems generate a hazard if it has a defect, fault, or error?
aa. Can a defect, fault, or error in the software used to process data or analyze trends lead to safety decisions that cause a system hazard?
bb. Do software capabilities exist against the potential use cases and planned operations throughout all phases of use, and through transitions between those phases/states?
A.1.5 Additional considerations when identifying software causes in a general software-centric hazard analysis are found in Table 2 below.
Table 2. Additional considerations when identifying software causes in hazard analysis
...
1. Use of industry-accepted coding standard
2. Use of safe math libraries
3. Robust software development, quality, and safety processes
...
