1. Requirements

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

2. Rationale

To show how the software requirements and software-related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software integration to implement the system requirements and system operation. The software and hardware work together to perform a safety-critical function, their roles, precedence, and failure modes need to be documented and understood.

3. Guidance

All software related safety constraints and constraints between the hardware, operator, and software are documented in the software requirements documentation.  When the software, hardware, or operator performs a safety-critical function, document the hardware, software, and operator (1) roles in that function, (2) the precedence, and (3) the failure modes as well as any known constraints, controls,  mitigations, conditions, timing constraints, limits, and wear-out factors that impact how software needs to respond.

Also, it is strongly recommended that software requirements developers seek out inputs from the operators and hardware engineers, asking about constraints and operating conditions the software may need to account for.  

Software-related safety requirements which include constraints and assumptions between the hardware, operator, and software will be documented in the software requirements documentation.  While the Software Requirement Specification (SRS) is not required to have a specific section that addresses the safety requirements, safety requirements are to be included in the SRS and designated (marked) as safety requirements.

• Any safety-related constraints between the hardware and software are included in the software requirements documentation. That is, when the software and hardware work together to perform a safety-critical function, their roles, precedence, and failure modes are documented and understood.

  Swerefn
  refnum 271

• Software safety requirements are derived from the system safety requirements, environmental requirements, standards, program specification, vehicle or facility requirements, interface requirements, system hazard reports, and system hazard analyses.

  Swerefn
  refnum 271

• System safety analyses, including the PHA [Preliminary Hazard Analysis], subsequent system hazard analyses, and software safety analyses are used to create new or identify existing, software requirements necessary to mitigate or resolve any hazards where software is a potential cause or contributor or enable the software to be used as a hazard control. Such requirements are designated as software safety requirements.

  Swerefn
  refnum 271

• Software safety requirements include the modes or states of operation under which they are valid and any modes or states in which they are not applicable.

  Swerefn
  refnum 271

• Software safety personnel, system safety personnel, and the Center Safety and Mission Assurance (SMA) organization work together to develop and identify or provide assistance in identifying software safety requirements. 

  Swerefn
  refnum 271

Additional guidance related to software safety may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Analyze that the software requirements documentation contains the software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and the software.

7.2 Software Assurance Products

• Copy of the system hazard analyses that address or include software.

• Software assurance/safety analysis of safety-related requirements.

• List of safety-related non-conformances identified in a problem tracking system.

  
  

  Note
  title Objective Evidence
  Software requirements. Software requirements analysis results or report.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

7.3 Metrics

• # of software work product Non-Conformances identified by life-cycle phase over time.
• # of safety-related non-conformances identified by life-cycle phase over time.
• Number of safety-related requirements issues (Open, Closed) over time.

7.4 Guidance

Step 1 - Assess that the software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software are in the software requirements documentation. Perform analysis to ensure the software does not violate the independence of hazard inhibits and hardware redundancy. While the Software Requirement Specification (SRS) is not required to have a specific section that addresses the safety requirements, safety requirements are to be included in the SRS.

• Any safety-related constraints between the hardware and software are included in the software requirements documentation. That is, when the software and hardware work together to perform a safety-critical function, their roles, precedence, and failure modes are documented and understood. 
• Software safety requirements are derived from the system safety requirements, environmental requirements, standards, program specification, vehicle or facility requirements, interface requirements, system hazard reports, and system hazard analyses.
• System safety analyses, including the PHA [Preliminary Hazard Analysis], subsequent system hazard analyses, and software safety analyses are used to create new or identify existing, software requirements necessary to mitigate or resolve any hazards where software is a potential cause or contributor or enable the software to be used as a hazard control. Such requirements are designated as software safety requirements.
• Software safety requirements include the modes or states of operation under which they are valid and any modes or states in which they are not applicable.
• Software safety personnel, system safety personnel, and the Center Safety and Mission Assurance (SMA) organization work together to develop and identify or provide assistance in identifying software safety requirements.

From SWE-134 - Safety Critical Software Design Requirements - If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software:

1. 1. The software is initialized, at first start and restarts, to a known safe state.
   2. The software safely transitions between all predefined known states.
   3. Termination performed by the software of functions is performed to a known safe state.
   4. Operator overrides of software functions require at least two independent actions by an operator.
   5. The software rejects commands received out of sequence when the execution of those commands out of sequence can cause a hazard.
   6. The software detects inadvertent memory modification and recovers to a known safe state.
   7. The software performs integrity checks on inputs and outputs to/from the software system.
   8. The software performs prerequisite checks before the execution of safety-critical software commands.
   9. No single software event or action is allowed to initiate an identified hazard.
   10. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
   11. The software provides error handling.
   12. The software can place the system into a safe state

Early planning and implementation dramatically ease the developmental burden of these requirements. Depending on the failure philosophy used (fault tolerance, control-path separation, etc.), design and implementation trade-offs will be made. Trying to incorporate these requirements late in the life cycle will impact the project cost, schedule, and quality. It can also impact safety as an integrated design that incorporates software safety features such as those above. This allows the system perspective to be taken into account and the design to have a better chance of being implemented as needed to meet the requirements in an elegant, simple, and more reliable way.

The sub-requirements and notes included in the requirement are a collection of best practices for the implementation of safety-critical software. These sub-requirements apply to components that reside in a safety-critical system, and the components that control, mitigate, or contribute to a hazard, as well as the software, used to command hazardous operations/activities. Software engineering and software assurance disciplines each have specific responsibilities for providing project management with work products that meet the engineering, safety, quality, and reliability requirements of a project.

Additional specific clarifications for a few of the requirement notes include:

Item a: Aspects to consider when establishing a known safe state includes the state of the hardware and software, operational phase, device capability, configuration, file allocation tables, and boot code in memory.

Item d: Multiple independent actions by the operator help to reduce potential operator mistakes.

Item f: Memory modifications may occur due to radiation-induced errors, uplink errors, configuration errors, or other causes so the computing system must be able to detect the problem and recover to a safe state. As an example, computing systems may implement error detection and correction, software executable and data load authentication, periodic memory scrub, and space partitioning to protect against inadvertent memory modification. Features of the processor and/or operating system can be utilized to protect against incorrect memory use.

Item g: Software needs to accommodate both nominal inputs (within specifications) and off-nominal inputs, from which recovery may be required.

Item h: The requirement is intended to preclude the inappropriate sequencing of commands. Appropriateness is determined by the project and conditions designed into the safety-critical system. Safety-critical software commands are commands that can cause or contribute to a hazardous event or operation. One must consider not only the inappropriate sequencing of commands (as described in the original note) but also the execution of a command in the wrong mode or state. Safety-critical software commands must perform when needed (must work) or be prevented from performing when the system is not in a proper mode or state (must-not work). 

Item j: The intent is to establish a safe state following the detection of an off-nominal indication. The safety mitigation must complete between the time that the off-nominal condition is detected and the time the hazard would occur without the mitigation. The safe state can either be an alternate state from normal operations or can be accomplished by detecting and correcting the fault or failure within the timeframe necessary to prevent a hazard and continuing with normal operations. The intent is to design in the ability of software to detect and respond to a fault or failure before it causes the system or subsystem to fail. If failure cannot be prevented, then design in the ability for the software to place the system into a safe state from which it can later recover. In this safe state, the system may not have full functionality but will operate with this reduced functionality. 

Item k: Error handling is an implementation mechanism or design technique by which software faults and/or failures are detected, isolated, and recovered to allow for correct run-time program execution. The software error handling features that support safety-critical functions must detect and respond to hardware and operational faults and/or failures as well as faults in software data and commands from within a program or from other software programs. 

Item l: The design of the system must provide sufficient sensors and effectors, as well as self-checks within the software, to enable the software to detect and respond to system potential hazards.

The analysis must ensure independent processors do not violate the independence of hazard inhibit-controls, controls that start at the sustainer separation event.  Also, Hardware redundancy for the start of inhibiting controls, and follow-through to actuator end-items, shall meet risk posture classification for the mission success. Partition of processors to meet single processor control of single inhibits, shall be verified by software engineering. When inhibit-control processors are not deterministic machines and go outside of the package to determine their action, software engineering shall verify no common mode failures exist influencing more than one inhibit-control processor (i.e. fault-containment-zones).

The analysis must ensure independent processors do not violate the independence of hazard inhibit-controls, controls that start at the sustainer separation event.  Also, Hardware redundancy for the start of inhibiting controls, and follow-through to actuator end-items, shall meet risk posture classification for the mission success. Partition of processors to meet single processor control of single inhibits should be verified by software engineering. When inhibit-control processors are not deterministic machines and go outside of the package to determine their action, software engineering should verify no common mode failures exist influencing more than one inhibit-control processor (i.e. fault-containment-zones).

See Software Contributions to Hazards, Software in system hazard analysis in SWE-205 - Determination of Safety-Critical Software