1. Requirements

4.1.4 The project manager shall include software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software in the software requirements documentation.

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

Key:    - Applicable | - Not Applicable

2. Rationale

To show how the software requirements and software-related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software integration 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

3.1 Safety Constraints And Constraints

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.  

3.2 Safety Requirements

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 (5.09 - SRS - Software Requirements Specification) 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. See also SWE-023 - Software Safety-Critical 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. ²⁷¹
• Software safety requirements are derived from the system safety requirements, environmental requirements, standards, program specifications, vehicle or facility requirements, interface requirements, system hazard reports, and system hazard analyses. ²⁷¹ See also Topic 8.10 - Facility Software Safety Considerations. 
• 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.  ²⁷¹

See also PAT-007 - Checklist for General Software Safety Requirements, Topic 6.2 - Checklist for General Software Safety Requirements, 

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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

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.

  
  

  Objective Evidence

  • Software requirements.
  • Software requirements analysis results or report.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

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

See also Topic 8.18 - SA Suggested Metrics.

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 (5.09 - SRS - Software Requirements Specification) 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 specifications, 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, 8.10 - Facility Software Safety Considerations

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 include 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 for 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 continue with normal operations. The intent is to design 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 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 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 .

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: