Attachment_0084 Joint Software System Safety Engineering Handbook (JSSSEH) Implementation Guide.pdf

Enclosure (2)

JOINT SERVICES – SOFTWARE SAFETY AUTHORITIES (JS‐SSA)

Supporting MIL‐STD‐882E

With Joint Software System Safety Engineering Handbook References

JS‐SSA‐IG Rev. B

3/14/2018

Distribution Statement A

Approved for public release; distribution is unlimited

This report is provided in fulfillment of the JS‐SSA and provides implementation guidance for Software System Safety program requirements that comply with the requirements specified in MIL‐STD‐882E and guidance detailed in the Joint Software Systems Safety Engineering Handbook (JSSSEH).

March 2018 i

Table of Contents

1.0 Software System Safety Abstract

2.0 Specialty Task Outline and Process

3.0 Process and Process Tasks for Software System Safety (SSS)

3.1. Process Task 1.0: Prepare the SSMP

3.1.1. Reference Documents

3.1.2. Process Subtask 1.1: Obtain Inputs from Acquirer Regulations and Policies

3.1.3. Process Subtask 1.2: Obtain Inputs from MIL‐STD‐882E and Compliance Documents

3.1.4. Process Subtask 1.3: Obtain Commitment from Program Management

3.1.5. Process Subtask 1.4: Prepare SSMP for Review and Approval

3.1.6. Process Subtask 1.5: Provide Inputs to the RFP and SOW

3.2. Process Task 2.0: Prepare SSPP

3.2.1. Process Subtask 2.1: Obtain Inputs from the SSMP

3.2.2. Process Subtask 2.2: Obtain Inputs from Compliance Documents

3.2.3. Process Subtask 2.3: Integrate Software Safety Engineering Criteria

3.2.4. Process Subtask 2.4: Prepare LOR Appendix

3.2.5. Process Subtask 2.5: Obtain Acquirer Approval of the Developer’s SSPP

3.3. Process Task 3.0: Preliminary Hazard Analysis

3.3.1. Process Subtask 3.1: Identify Hazards Pertaining to the Baseline System

3.3.2. Process Subtask 3.2: Identify Hazard Failure Modes

3.3.3. Process Subtask 3.3: Identify Hazard Causes (Hardware/Software & Human Error)

3.3.4. Process Subtask 3.4: Identify Mitigation Requirements

3.3.5. Process Subtask 3.5: Categorize Hazards with Risk Assessment Code (RAC)

3.4. Process Task 4.0: FHA

3.4.1. Process Subtask 4.1: Functionally Decompose the System

3.4.2. Process Subtask 4.2: Identification of All Functionality

3.4.3. Process Subtask 4.3: Document Functional Failure Consequences

3.4.4. Process Subtask 4.4: Determine Severity of Functional Failure Consequences

3.4.5. Process Subtask 4.5: Identify SSFs

3.4.6. Process Subtask 4.6: Allocate SSFs to Subsystems and Software

3.4.7. Process Subtask 4.7: Map SSFs to the Software Design Architecture

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight ii

3.4.8. Process Subtask 4.8: Assign SwCI to each Software Function within SSFs

3.4.9. Process Subtask 4.9: Identify Failure Mitigation Requirements

3.5. Process Task 5.0: Initiate System Requirements Hazard Analysis (SRHA)

3.5.1. Process Subtask 5.1: Review System and Functional Specifications

3.5.2. Process Subtask 5.2: Identify and Tag Contributing Safety‐Significant Requirements (CSSR)

3.5.3. Process Subtask 5.3: Identify and Tag GSSR

3.5.4. Process Subtask 5.4: Identify and Tag Mitigating Safety‐Significant Requirements (MSSR)

3.5.5. Process Subtask 5.5: Document Output of SRA Steps

3.5.6. Process Subtask 5.6: Define Verification and Validation for Each SSR

3.5.7. Process Subtask 5.7: Incorporate Each SSR into the Applicable Documents

3.5.8. Process Subtask 5.8: Assess Compliance of the System Hardware and Software with SSRs

3.6. Process Task 6.0: Perform System and Subsystem Hazard Analyses

3.6.1. Process Subtask 6.1: Integrate Hazards from the PHA

3.6.2. Process Subtask 6.2: Identify and Document New System/Subsystem Hazards

3.6.3. Process Subtask 6.3: Perform Causal Analysis on System/Subsystem Hazards

3.6.4. Process Subtask 6.4: Derive Specific Mitigation Requirements

3.6.5. Process Subtask 6.5: Categorize Hazards with a RAC

3.7. Process Task 7.0: Finalize SRHA

3.7.1. Process Subtask 7.1: Reassess SSRs

3.7.2. Process Subtask 7.2: Specify New System/Subsystem SSRs

3.7.3. Process Subtask 7.3: Assess Compliance of System/Subsystem Hardware and Software with SSRs

3.7.4. Process Subtask 7.4: Author Appropriate Change Requests against Requirements

3.8. Process Task 8.0: Perform Final Safety Requirements Traceability

3.8.1. Process Subtask 8.1: Trace Safety Requirements to Design Architecture

3.8.2. Process Subtask 8.2: Trace Safety Requirements to Hazards

3.8.3. Process Subtask 8.3: Trace Safety Requirements to Implementation

3.9. Process Task 9.0: Perform Code‐Level Safety Analysis

3.9.1. Process Subtask 9.1: Determine the Software Functionality to Analyze

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight iii

3.9.2. Process Subtask 9.2: Determine the Software Modules to Analyze

3.9.3. Process Subtask 9.3: Determine the Objectives of the Analysis

3.9.4. Process Subtask 9.4: Analyze LOR‐1 Software

3.10. Process Task 10.0: Perform Software Test Planning

3.10.1. Process Subtask 10.1: Ensure Correctness and Application of the LOR Test Criteria

3.10.2. Process Subtask 10.2: Ensure Safety Functionality is Tested

3.10.3. Process Subtask 10.3: Comply with the LOR Test Criteria

3.10.4. Process Subtask 10.4: Assist in Writing Test Cases and Test Procedures

3.11. Process Task 11.0: Monitor Safety‐Significant Software Testing

3.11.1. Process Subtask 11.1: Ensure Software Testing Conforms to LOR Test Criteria

3.11.2. Process Subtask 11.2: Ensure Safety Functionality is Tested

3.11.3. Process Subtask 11.3: Monitor Test Defects and Corrective Actions

3.11.4. Process Subtask 11.4: Review Final Software Test Results

3.12. Process Task 12.0: Perform Safety Risk Assessment

3.12.1. Process Subtask 12.1: Reassess all Documented Hazards

3.12.2. Process Subtask 12.2: Verify Hazard Mitigation

3.12.3. Process Subtask 12.3: Assess Partial Mitigation or Failure to Mitigate

3.12.4. Process Subtask 12.4: Assess Safety Risk

3.12.5. Process Subtask 12.5: Document and Communicate Safety Risk

3.13. Process Task 13.0: Participate in Life‐Cycle Management and Support

3.13.1. Process Subtask 13.1: Assess all Proposed Changes to and Operational Impacts on the

System

3.13.2. Process Subtask 13.2: Identify Changes and Operational Impacts Associated with Current

Hazards

3.13.3. Process Subtask 13.3: Identify New Hazards, Failure Modes, or Causes Associated with

Changes and Operational Usage

3.13.4. Process Subtask 13.4: Mitigate Hazards, Failure Modes, or Causes

3.13.5. Process Subtask 13.5: Document and Communicate Safety Risk

3.13.6. Process Subtask 13.6: Update all Safety‐Related Artifacts

4.0 Acronym List

5.0 Glossary

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight iv

List of Figures

Figure 1.0: Initial SSS Process Chart for Pre‐Contract and Requirements Phases

Figure 1.1: Process Task 1.0 Prepare the SSMP Subtasks

Figure 1.2: Process Task 2.0 SSPP Task and Subtasks

Figure 1.3: Sub‐Process Task 2.4 Prepare LOR Appendix to SSPP

Figure 2.0: SSS Process Chart for Requirements and Preliminary Design Phases

Figure 2.1: Process Task 3.0 PHA Task and Subtasks

Figure 2.2: Example of Hazard Failure Modes Represented in Simple Logic Diagram

Figure 2.3: Process Task 4.0 Task and Subtasks

Figure 2.4: Example FHA Format

Figure 2.5: SSF Mapping to Software Design Architecture Example

Figure 2.6: Process Subtasks for 4.8 Assign SwCI/LOR

Figure 2.7: Process Task 5.0 Initiate Safety Requirements Analysis Task and Subtasks

Figure 2.7.1: Initiate System Requirements Hazard Analysis Task and Subtasks

Figure 3.0: SSS Process Chart for Detail Design and Implementation Phases

Figure 3.1: Process Task 6.0 Perform In‐depth Hazard Analysis and Subtasks

Figure 3.2: Process Task 7.0 Finalize System Requirements Hazard Analysis

Figure 3.3: Process Task 8.0 Perform Final Requirements Traceability and Subtasks

Figure 3.4: Hazard Closed‐Loop Requirements Traceability

Figure 4.0: SSS Process Chart for Test and Deployment Phases

Figure 4.1: Process Task 9.0 Perform Code Level Analysis and Subtasks

Figure 4.2: Process Task 10.0 Perform Software Test Planning and Subtasks

Figure 4.3: Process Task 11.0 Monitor Safety‐Related Testing and Subtasks

Figure 4.4: Process Task 12.0 Perform Safety Risk Assessment and Subtasks

Figure 4.5: Process Task 13.0 Participate in Life Cycle Management and Subtasks

Figure A.1: Preferred LOR Tailoring Method Example

Appendices

Appendix – A Preferred Level of Rigor Activities Table

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight v

Revision History

Revision Date Description ‐ 29 June 2016 Initial Release

A 17 October 2017 Updated to incorporate annual JS‐SSA member comments.

Text and figures updated to create tighter coupling between IG and MIL‐STD‐882E Tasks

B 14 March 2018 Out of cycle revision to incorporate JS‐SSA approved comments and recommendations resulting from U.S. Navy initiated Carnegie Mellon (CM) Software Engineering Institute (SEI) review of Rev. A. Comments resulted in revising Section 3.9 Perform Code‐Level Safety Analysis, as well as CM SEI recommendations to clarify importance of application within the software development life‐cycle and processes. Technical content and data structure is unchanged. Corrects identified administrative and clerical errors in text and figures.

1.0 Software System Safety Abstract

Software System Safety Engineering (SSSE) focuses on two primary objectives; first to design, code, test, and support software with the appropriate Level‐of‐Rigor (LOR) to instill a confidence, or the assurance of safe software; and to define the necessary safety requirements for the design, code, test, verification, and validation of software that specifically target and mitigate the software “causes” of the defined hazards and mishaps of the system. Each of these two objectives is covered in detail within the Joint

Software Systems Safety Engineering Handbook (JSSSEH). Requirements to meet the SSSE objectives are specified in MIL‐STD‐882E. The challenge is getting Acquirers (Customer) and Developers (software developers) to specify how they will turn the objectives of MIL‐STD‐882E and the JSSSEH “guidance” into actual SSSE requirements. The objective of this document is to provide Department of Defense (DoD)

Acquirers and their Developers with the implementation details necessary to take the requirements of

MIL‐STD‐882E and the “guidance” of the JSSSEH and define the process and tasks required for a compliant SSSE program. MIL‐STD‐882E and guidance of the JSSSEH will continue to be the parent source for guidance on how to meet identified software safety engineering requirements. This document is also appropriate for use by non‐DoD entities developing software for safety‐significant systems.

This revision of the originally released version of this Implementation Guide focuses on correcting known errors and inconsistencies in the document, create greater alignment between the document and the parent MIL‐STD‐882E requirements and tasks, and incorporate results and lessons learned from the successful initial release of the document. This revision maintains the core purpose and structure of the original version, which is the process and tasks to implement and execute a MIL‐STD‐882E compliant

SSSE program as part of System Safety Engineering (SSE) and integrated within the overall software development processes.

Carlos.Y.Velez Highlight

2.0 Specialty Task Outline and Process

This distillation of MIL‐STD‐882E and the JSSSEH into implementable process task requirements is presented as a decomposition of parent and children activities in a process task numbering format. The parent tasks are graphically represented depicting inputs to the tasks and the products that the task would likely produce. Tasks identified as MIL‐STD‐882 requirements are coded in the graphics using an extreme bold border of the task box. Task decomposition is to the level necessary for a basic understanding of the process, the tasks that implement the process, and the products the tasks would likely produce. The requirements derived that apply to each task will be specified and cross referenced to both the applicable MIL‐STD‐882E requirements and JSSSEH sections and paragraphs that provide guidance on meeting the requirements. As such, any DoD Acquirer or Developer should be able to develop SSSE tasks and requirements that comply with MIL‐STD‐882E and the guidance of the JSSSEH.

Appendix A of this document is a LOR task table that should be used to develop the defined process tasks necessary to meet MIL‐STD‐882E Table V LOR requirements. The LOR task table also supports accomplishment of the MIL‐STD‐882E Tasks for the SSSE contribution to SSE. The LOR table should be assessed for tailored implementation for any given program, and tailoring is permitted as long as the tailored LOR tasks are approved by both the Acquirer and Developer.

3.0 Process and Process Tasks for Software System Safety (SSS)

The process for accomplishing a successful SSS program begins with the contract between the Acquirer

(typically a DoD Agency, Program, Project or Product Office) and the Developer (generally referred to as the Developer or Software Developer). It is essential for the DoD Acquirer to adequately specify the SSE and SSSE tasks and artifacts necessary to meet the requirements of MIL‐STD‐882E on contract. If the

Statement of Work (SOW) does not define the required Developer safety tasks and artifacts, then the overall safety program is likely to not meet either the service‐specific or the Joint Services safety requirements. The vast majority of SOW tasks are reflected in Appendix A under SSE Tasks required for adequately supporting the software system safety effort. Additionally, the SOW must specify the frequency of meetings; Contract Deliverable Requirements List (CDRLs) items; and necessary reviews in order for the developer to adequately bid their efforts.

The Acquirer must adequately plan for the tasks that will be required and implemented by the

Developer. This planning is accomplished prior to the Request for Proposal (RFP) (or contract change for existing programs) and documented in the System Safety Management Plan (SSMP) as referenced in

JSSSEH Para 4.2.1 and detailed in Section 3.1 Process Task 1.0. Specific Acquirer tasks that must be accomplished prior to contract award include (but are not limited to);

Develop SSMP.

Utilize the Mishap Risk Matrix, Software Criticality Matrix (SCM) and associated input definitions of MIL‐STD‐882E, unless a tailored version has been approved in accordance with (IAW) DoD

Component Policy.

Charter the System Safety Working Group (SSWG) to include all managerial, organizational, and technical relationships.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Develop Safety input to the RFP, SOW and other contractual documentation (this is where Tasks, CDRLs, and required analyses, etc. should be specified, as well as when/where delivered/documented). Required analyses should include: MIL‐STD‐882E Task 102 System

Safety Program Plan (SSPP), Task 106 Hazard Tracking System (HTS), Task 201/202 Preliminary

Hazard List (PHL)/ Preliminary Hazard Analysis (PHA), Task 203 System Requirements Hazard

Analysis (SRHA), Task 204 Subsystem Hazard Analysis (SSHA), Task 205 System Hazard Analysis

(SHA), Task 206 Operating and Support Hazard Analysis (O&SHA), Task 208 Functional Hazard

Analysis (FHA), and Task 301 Safety Assessment Report (SAR). As applicable, Task 209 System‐of‐

Systems (SoS) Hazard Analysis may be required.

Define Acquirer specification safety requirements.

Provide safety requirements input to other relevant documentation (e.g., Software

Development Plan (SDP), Test and Evaluation Master Plan (TEMP), System Engineering Master

Plan (SEMP), and Configuration Management Plan (CMP)).

Work with the Program/ Project/ Product Manager (PM) to ensure the system safety and software system safety program is adequately resourced and staffed.

Ensure Acquirer Safety is part of the configuration control process (voting member of Acquirer chaired boards, participant/reviewer of safety impacted items at the level (MIL‐STD‐882E Task

304). Evidence can be incorporated into the CMP and/or Board Charter(s).

Perform analyses required to define the System Level Mishaps and interfaces/contributions provided by supporting system elements (e.g., multiple Developers may be developing different critical subsystems and each must account for their respective contributions to system mishaps).

Figure 1.0 includes the initial process tasks required by the Acquirer and then transitioning to the tasks required by the Developer after contract award. This document will step through the parent process tasks beginning with Task 1.0: Prepare System Safety Management Plan. Subtasks (children to the parent task) will also be presented and discussed to ensure that the reader fully comprehends the scope and details of each major task described. Where applicable, references to MIL‐STD‐882E and the JSSSEH are provided for further detail.

The SSSE process and tasks described in this document can be applied within an integrated system and software development process regardless of software development technique. Current software development best practices have shifted from the classical, aligned with the overall system development schedule, waterfall process towards more rapid (e.g., Agile), model‐based software development processes. Current processes use varying terminology to describe their tasks and life‐cycle phases.

However, at their core, all software development processes follow the “Establish the Program, Requirements, Design and Architecture, Implementation, and Test and Verification” process steps. The primary “difference” is that within the rapid, model‐based software development processes, the development steps are applied to smaller subsets of overall software functionality and capabilities during a given development cycle and the process occurs within a much smaller timeframe than the overall acquisition schedule. For example, the “Requirements Phase” may focus on taking the system engineering domain architecture artifacts and developing Use Cases to implement the “Requirements and Capabilities” specified by the architecture artifacts as opposed to a natural language Software

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Requirements Specification (SRS). The tailoring of the LOR Tasks specified in Appendix A becomes even more important to accomplish at program outset, to include updating of terminology to match the software development, and subsequent integration within the software development process activities.

SSSE must be integrated within the software development team, as well, to both be able to provide SSSE analysis in support of the software development effort and to ensure the development team is meeting their SSSE LOR task requirements.

Figure 1.0: Initial SSS Process Chart for Pre‐Contract and Requirements Phases

3.1. Process Task 1.0: Prepare the SSMP

It is standard practice within an Acquirer’s program office to develop a SSMP for a program (or family of programs). This document defines the Acquirer’s requirements for the establishment, structure, resourcing, and implementation of a system safety and software system safety activity for the program, or family of programs, to be managed by an individual Acquirer program office. The SSMP must document the system safety program requirements as established by applicable Federal and Civil law, and DoD acquisition authorities. Subtasks to this process task are depicted in Figure 1.1.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

3.1.1. Reference Documents

The following documents provide the basis for the format and criterion for the SSMP and this implementation guide:

DoD Instruction 5000.02, Change 3 – Operation of the Defense Acquisition System, August 10, 2017.

MIL‐STD‐882E – Department of Defense Standard Practice, System Safety, May 11, 2012.

DoD Joint Software System Safety Engineering Handbook, Version 1.0, August 27, 2010.

RTCA DO‐178C, Software Considerations in Airborne Systems and Equipment Certification, 2011.

SAE Aerospace Recommended Practice (ARP) 4754, Certification Considerations for Highly‐

Integrated or Complex Aircraft Systems, November 1, 1996.

SAE Aerospace Recommended Practice (ARP) 4761, Guidelines and Methods for Conducting the

Safety Assessment Process on Civil Airborne Systems and Equipment, 1996.

Figure 1.1: Process Task 1.0 Prepare the SSMP Subtasks

3.1.2. Process Subtask 1.1: Obtain Inputs from Acquirer Regulations and Policies

The requirements for a system safety program are explicitly documented in MIL‐STD‐882E. The

Acquirer’s specific regulations and policies provide the requirements for generation of the SSMP. The

SSMP must reflect the criterion established in these regulations and policies as well as in MIL‐STD‐882E.

Examples may include such things as Air Worthiness Certification criteria for air vehicles to the requirements established by individual safety boards (i.e., regulatory, Service and Joint Safety Review

Boards). The SSMP must include these additional safety program requirements that will aid the Acquirer in meeting all certification or acceptance authority criteria. The SSMP should ensure that all of the

Acquirer’s system safety and software safety requirements are adequately transitioned to the RFP and the SOW, and ultimately flowed down to the Developer. This flow down of the SSMP ensures the

Developer’s System Safety Program Plan (SSPP) supports the Acquirer meeting their safety requirements. Developers bidding on the contract must have a clear understanding of the Acquirer’s expectations for the system and software safety engineering efforts. This allows the Developer to bid and propose a system safety program based upon Acquirer requirements and expectations.

3.1.3. Process Subtask 1.2: Obtain Inputs from MIL‐STD‐882E and Compliance Documents

MIL‐STD‐882E, Task 101 provides direction on content for system safety program management.

Individual Acquirer programs may possess system safety requirements that are not explicitly covered in

Carlos.Y.Velez Sticky Note https://www.acq.osd.mil/se/docs/Joint-SW-Systems-Safety-Engineering-Handbook.pdf

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

MIL‐STD‐882E, regulations or policies, but deemed important by the Program Office. The development of a SSMP must take into consideration the requirements that are defined by other compliance documents.

3.1.4. Process Subtask 1.3: Obtain Commitment from Program Management

Without Program Management “buy‐in” regarding the necessity and Return‐On‐Investment (ROI) of a comprehensive system safety engineering effort, the probability of successfully influencing the design from a safety perspective is greatly reduced. The system safety program defined by the SSMP must possess concurrence and acceptance from the PM. This is the best opportunity for the System Safety

Manager to adequately communicate the system safety ROI to Program Management in terms of the total life‐cycle costs associated with mishaps as it affects human injury or death, programmatic costs, schedule, operational readiness, operation effectiveness, and organizational reputation.

3.1.5. Process Subtask 1.4: Prepare SSMP for Review and Approval

Ultimately, it is the Acquirer who must meet their respective program requirements. The SSMP defines the path forward for all system safety efforts to be performed by both the Acquirer and the

Developer(s). This plan establishes the overall system safety requirements whereas the Developer’s

SSPP defines the processes, methods, tasks, and tools to be implemented to meet the SSMP and contracted safety requirements. The SSMP must also include all applicable requirements for the establishment and implementation of a software system safety program.

3.1.6. Process Subtask 1.5: Provide Inputs to the RFP and SOW

Once the SSMP is produced and approved by Acquirer Management, the system safety requirements language defined in the plan must be captured in each RFP and SOW that are published by the program office to support the design, development, and test, of each program asset being developed or updated.

If the system safety requirements are not captured in the RFP and the supporting SOW, the Developers will possess no contractual basis to perform the necessary tasks to complete a successful system safety or software system safety program.

3.2. Process Task 2.0: Prepare SSPP

[Ref: JSSSEH Paragraph 4.2.1, Fig. 4‐6, and MIL‐STD‐882E Task 102]

The SSPP is the document of compliance for the contract as it applies to system safety and software system safety engineering. Figure 1.2 depicts the process subtasks as they apply to the task of preparing the SSPP for approval. The Developer’s SSPP, including the Software System Safety Program Plan

(SwSSPP) requirements, must define how the Developer’s contractual safety requirements are flowed down, implemented and verified by their development team, sub‐developers, subcontractors, or vendors.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Sticky Note The contractor shall develop an SSPP to provide a basis of understanding between the contractor and the Program Manager (PM) on how the safety hazard management effort will be integrated into the SE process.

Figure 1.2: Process Task 2.0 SSPP Task and Subtasks

3.2.1. Process Subtask 2.1: Obtain Inputs from the SSMP

The SSMP (or equivalent Acquirer document) defines the relevant compliance criteria from standards, regulations, and handbooks, and defines the terms and term definitions to be used on the program and to charter the SSWG. From the SSMP and Contract tasks, the Developer prepares the SSPP that defines and documents the processes, tasks, and deliverables to be accomplished on the program to comply with the contractual safety requirements. The SSPP should contain, as a minimum, the information defined by MIL‐STD‐882E, Task 102 and the corresponding Data Item Description (DID), DI‐SAFT‐80100A, System Safety Program Plan. If the JSSSEH is cited in the SOW, SSMP, and/or SSPP, then this JSSSEH

Implementation document should be used to develop Software System Safety Program (SwSSP) requirements.

3.2.2. Process Subtask 2.2: Obtain Inputs from Compliance Documents

The primary compliance document is MIL‐STD‐882. Depending upon whether this is a new acquisition program or a fielded system in the Sustainment phase (such as a legacy program), the contractual version of MIL‐STD‐882 may be Revision E or an earlier version. In addition, each DoD Service may have separate compliance documents for software system safety. On aviation related contracts, aviation specific compliance documents or standards may be required. This is important to understand because each individual standard can use terms that are common to the safety community but possess totally different meanings. As an example, the FHA as defined by SAE ARP 4761, Guidelines and Methods for

Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, has a different purpose, content, and format as an FHA as defined by a MIL‐STD‐882E.

3.2.3. Process Subtask 2.3: Integrate Software Safety Engineering Criteria

The specific processes, tasks, and deliverables to support SSS engineering should be completely integrated into the main text of the SSPP. IAW with MIL‐STD‐882E requirements, the SSPP must detail how the SSS requirements are going to be addressed for all safety‐significant software (as software is defined in MIL‐STD‐882E) within the system. The SSS input to the SSPP must address the requirements for each development phase and also address validation and approval of tools, models, and simulations that will be used in the development, support, and verification/validation of safety‐significant software.

The SSS engineering criteria to be specified in the SSPP, and implemented, should be extracted from both MIL‐STD‐882E and the JSSSEH.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

3.2.4. Process Subtask 2.4: Prepare LOR Appendix

[Ref: JSSSEH Paragraph 4.2.1.5, and 4.3.2, JSSSEH Figure 4‐13, Table 4‐3, and Table 4‐4; and Appendix A‐

Level of Rigor Task Table]

The SSPP must contain the comprehensive LOR Task Table that establishes both the Developer’s process and design requirements for SSS. The Acquirer, either via reference to the SSPP, or inclusion in the SSMP must specify an initial LOR Task Table for the Developer to tailor and implement as part of their SSS and software development programs. The LOR Table contains the specific required process tasks and design requirements to obtain the necessary body of evidence that software introduces an acceptable contribution to mishap risks for the program, as well as to implement and meet the intent of the general requirements of MIL‐STD‐882. This confidence can only be obtained if the defined tasks for each software development life cycle phase are successfully defined and accomplished. The subtasks of

Process 2.0 are presented in Figure 1.3.

Figure 1.3: Sub‐Process Task 2.4 Prepare LOR Appendix to SSPP

3.2.4.1. Process Subtask 2.4.1: Obtain LOR Task Inputs from Compliance Documents

Preparation of a LOR Table that will be accepted by the Developers’ development team and approved by the Acquirer and their independent safety reviews, necessitates that compliance documents become the foundational input to the table. For example, in MIL‐STD‐882E, Table V defines the general LOR requirements for each level of Software Criticality. The purpose of Process Subtask 2.4 is to take those general requirements and then specify the specific implementation requirements the program will execute to fulfill the MIL‐STD‐882E criteria. DoD Service requirements must also be assessed for inclusion into the table, as well as the requirements of the various Service and Joint Safety Reviews.

For aviation‐related programs, SAE ARP 4754/4761 and RTCA DO‐178C, Software Considerations in

Airborne Systems and Equipment Certification, are called out for the purposes of ensuring that airworthiness requirements are established and fulfilled to obtain an Air Worthiness Release (AWR). In addition, each of the Services, either jointly or independently, may have unique LOR requirements for specific subsystems that require separate approvals, such as fuze, ignition and laser subsystems.

3.2.4.2. Process Subtask 2.4.2: Prepare the LOR Task Table Appendix

An initial LOR task table is provided in Appendix A. An initial LOR task table can also be included in the

Acquirer’s SSMP and provided separately by the Acquirer to the Developer. This table can be tailored for each individual program’s capabilities and requirements based upon the criticality, complexity, and

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight constraints of the program. All tailoring must be approved by the SSWG and the Acquirer. It is highly recommended that the Acquirer obtain concurrence of tailored tasks from the various applicable review authorities as well. Where tailoring is implemented, it must be adequately explained, justified and approved.

Within the LOR Table, the criticality is ranked in accordance with both the mishap severity definitions and the software control category definitions of MIL‐STD‐882E. LOR ranking is from lowest criticality

Software Criticality Index (SwCI 5) to highest criticality (SwCI 1) as referenced in MIL‐STD‐882E Table V.

System Functions that are deemed Safety‐Significant Function (SSF) IAW MIL‐STD‐882E are assessed for their criticality (see Sections 3.5.2, 3.5.3, and 3.5.4) and are architected, designed, coded, and verified in accordance with the LOR tasks documented in the program’s approved LOR Table. LOR tasks must include the software development process tasks, software test and verification tasks, and design assurance features that are required for each SSF.

In reality, budgetary and schedule constraints may play a role in tailoring requirements. However, if the budget and schedule do influence the tailoring process, it will likely produce more safety risk for the system, or at minimum impact acceptability by review authorities. Table VI of MIL‐STD‐882E provides requirements for notifying management and risk acceptance authorities of the consequences of lack of

LOR application. When potential programmatic or safety risks resulting from budget and schedule impacts are identified, they may also require inclusion in the overall Program Risk tracking system to maintain management visibility. Risk acceptance performed in one contractual activity should be reassessed for the next contractual activity.

3.2.4.3. Process Subtask 2.4.3: Obtain LOR Concurrence from Development and Test

The software developers, architects, and testers must be integrated into the software SSE activities and be involved with the definition and implementation of LOR tasks. This is an important step in that the safety team must understand the system and software architecture to define the software criticality and the derived LOR tasks. In addition, the software developers and testers must fully comprehend their role in the execution of a successful software system safety (SSS) program. They must understand what they are required to accomplish by LOR definition and safety assurance rationale of the tasks to be accomplished. The software developers and testers should have an input to the definition and tailoring of LOR tasks. Any task that is perceived to possess little ROI for the resources expended should be flagged as candidates for tailoring with appropriate justification to include the potential safety risk rationale.

3.2.4.4. Process Subtask 2.4.4: Integrate LOR Tasks with Development and Test Processes

The approved LOR tasks must be fully integrated into the software development, coding, and test activities of the Developer. Some of the LOR tasks are accomplished by the system safety team, whereas many are actually accomplished by the software design, code, and test teams. Those tasks assigned to software development and test must be part of their defined processes as documented in their planning documents.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

3.2.4.5. Process Subtask 2.4.5: Integrate LOR Tasks into Pertinent Program Plans

The approved LOR Table tasks must be adequately documented in the applicable Developer specifications, plans, and process documentation as requirements. Documents typically include:

Software Requirements Specification (SRS), SDP, Software Test Plan (STP), Software Configuration

Management Plan (SCMP), and Software Quality Assurance Plan (SQAP). The Developer must ultimately be able to answer the questions “How did you meet LOR requirements?” and, “Where is the evidence?”

3.2.5. Process Subtask 2.5: Obtain Acquirer Approval of the Developer’s SSPP

The Developer’s SSPP must be submitted for review and approval by the Acquirer to ensure it adequately addresses SSE and SSS requirements and tasks, to include references to other Developer documentation that may implement SSS requirements. This review and approval includes the approval of the LOR Appendix. Acquirer approval of the LOR Table, including concurrence from their safety review authorities, represents Acquirer concurrence that the tasks defined in the table are sufficient (if implemented and evidenced) to provide the necessary assurance that safety‐significant software is being designed, coded, and tested in accordance with defined best practices. All LOR tailoring must be explained and justified. As the program matures, changes to the LOR table should be coordinated with and approved by the Acquirer (often via the SSWG) and Developer, as well as the applicable review authorities.

3.3. Process Task 3.0: Preliminary Hazard Analysis

[Ref: JSSSEH Paragraph 4.3.4 and MIL‐STD‐882E, Tasks 201 and 202]

The software system safety process as initiated in Figure 1.0 continues as depicted in Figure 2.0 below.

Within the software development life cycle, this is considered the requirements and preliminary design phase of development.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Figure 2.0: SSS Process Chart for Requirements and Preliminary Design Phases

Figure 2.1 depicts the initial Developer PHA effort in Process Task 3.0. The PHA commences almost immediately after contract award. Notice that the Functional Hazard Analysis (Section 3.4 Process Task

4.0) is likely to be performed concurrently with the PHA. This is considered acceptable because these two analyses basically provide specific and essential information that brings accuracy and fidelity to each individual analysis. The safety DID pertaining to the PHA is DI‐SAFT‐80101A.

Figure 2.1: Process Task 3.0 PHA Task and Subtasks

The PHA is performed under the responsibility of SSE and its scope is dictated by the SOW and contract.

The PHA is the initial analysis performed on the system for the purpose of the identification of potential hazards and mishaps which are documented within the PHA. The PHA begins with development of the

PHL. The PHL, detailed in MIL‐STD‐882E Task 201, provides a summary list of potential hazards and mishaps for the system, including those with software contributions. SSSE must support the development of the PHA by providing assessment of the system’s software within the context of the system. Another important purpose of the PHA is to identify potential failure modes and causes of the hazards in order to define (as early as possible) mitigation requirements for the system and software specifications. Mitigation requirements should be defined as early in the analysis process as possible and documented in the specifications, resulting in fewer derived safety requirements after the design matures within the life cycle process. Section 3.6.3 provides discussion of Generic System Safety

Requirements (GSSR). During the PHA, mitigating requirements will likely consist of high level specification requirements and GSSRs. The PHA is one of the earliest opportunities to influence the design and design decisions regarding the use of software in performing SSFs. PHL and PHA results are used to populate the initial Hazard Tracking System (HTS) records as defined in MIL‐STD‐882E, Task 106.

As the results of the PHL and PHA mature and evolve in subsequent safety analyses, the HTS records will also evolve and mature.

3.3.1. Process Subtask 3.1: Identify Hazards Pertaining to the Baseline System

[Ref: MIL‐STD Task 202 and JSSSEH paragraph 4.3.4]

The preliminary mishaps and hazards are identified based upon the capabilities the system is to provide, the preliminary design baseline, and the safety risk potential that the system could possess. Preliminary hazards may be either formalized or eliminated as they are peer reviewed by system designers and the

SSE team within the SSWG. Regardless of the final disposition of the identified hazard, all hazards are captured and documented in the HTS (MIL‐STD‐882E, Task 106).

3.3.2. Process Subtask 3.2: Identify Hazard Failure Modes

Hazard failure modes are the primary failure paths leading to a hazard as represented in the example logic diagram of Figure 2.2. In the depicted example, “Loss of Engine” is the system‐level hazard with four primary failure modes (there are likely others); Bird Strike; Loss of Fuel to Engine; Failure of Engine

Control; and Failure of the Compressor. It should be noted that these failure modes will likely be tracked as separate sub‐system‐level hazards in a subsequent SSHA. Continuing the logic diagram lower, it is evident that each sub‐system‐level hazard possesses individual failure modes. It is important to accomplish the analysis for the PHA in a “top‐down” manner in order to keep track of the context between mishaps, system‐level hazards, sub‐system‐level hazards, failure modes, and failure mode lower‐level causes. Once the hazard failure modes are identified, each failure mode can then be further analyzed for specific causes from a hardware, software, and human error perspective.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Figure 2.2: Example of Hazard Failure Modes Represented in Simple Logic Diagram

Both “loss of fuel to the engine” and “failure of engine control” events are likely to contain one or more software causes (contributions to fault or failure). The PHA should continue as far down the causal pathway as the design will allow in order for the definition of as many safety‐significant software mitigation requirements as possible early in the system’s design cycle.

3.3.3. Process Subtask 3.3: Identify Hazard Causes (Hardware/Software & Human Error)

The PHA must be performed in such a way as to be able to see the context of how software reacts to hardware and human operators, and how the hardware and the human reacts to how the software functions. Hardware, software and human operator hazard causes must be addressed within the PHA to ensure that functional and physical interfaces are included in the analysis. Note: It is essential that the

PHA and follow‐on analyses be performed to the depth necessary for the identification of specific hazard mitigation requirements that provide the evidence of sufficient AND‐Gate protection (e.g., design redundancy) against the probability of failure propagation to the top event.

3.3.4. Process Subtask 3.4: Identify Mitigation Requirements

[Ref: JSSSEH paragraph 4.3.5.1.3]

Because the PHA is performed early in development, the hazard mitigation requirements that are identified by the PHA and the FHA analysis might be more general (high level requirement) in nature.

Multiple derived lower‐level requirements may be necessary to fulfill a high‐level requirement as the design matures. This derivation of lower level requirements must occur as the system design matures.

From the SSSE perspective, it is important to understand context for potential mitigation requirements that may be assigned to software and to ensure their integration into the PHA and software specifications.

3.3.5. Process Subtask 3.5: Categorize Hazards with Risk Assessment Code (RAC)

Each identified and documented hazard and mishap is initially categorized in terms of mishap severity and likelihood of occurrence. This initial RAC is assigned prior to any mitigation action unless there is evidence of specific provisions, alternatives, and mitigation measures that have been verified to have been implemented within the design to reduce risk. MIL‐STD‐882E defines severity and likelihood of occurrence (probability) and must be used unless tailoring has been approved by the Program’s DoD

Component Executive. Each hazard and mishap is assigned an initial risk assessment, commonly known as a RAC, and documented in the HTS hazard record. RACs can be obtained from the Risk Assessment

Matrix as defined in Table III of MIL‐STD‐882E. Software does not have a probability of occurrence component, so it is not necessary to assign a probability at the software causal level (of the hazard), but the PHA should consider how a software cause(s) affects the overall hazard and mishap probability of occurrence.

RAC is the allocation of severity and probability of the mishap when all hazard mitigations are considered in the design and requirements are implemented for the procedures and training of personnel operating and maintaining the system. In most instances, the severity of the hazard or mishap will not change, unless the associated system capabilities and design changes. Changes in RAC, from initial assignment to risk acceptance, will likely be a reduction in probability only. The PHA task concludes with the capture of all PHA data in the hazard analysis worksheets that are imported into the

Acquirer‐approved HTS.

3.4. Process Task 4.0: FHA

[Ref: JSSSEH paragraph 4.3.3, and MIL‐STD‐882E Task 208]

The FHA is another foundational SSE analysis performed under the responsibility of system safety engineering and its scope is dictated by the SOW and contract. Additionally, virtually all safety review authorities expect a FHA as part of the program’s objective evidence for identifying and classifying the system functions and the safety consequences of functional failure or malfunction prior to obtaining review acceptance and concurrence. The FHA is one of the most important analyses that the system safety analyst will perform. As the software implements functions within the context of system, it is essential to understand which functions are safety‐significant and which of these will be implemented by the software. It is also important to ensure (by LOR analysis and test tasks) that the SSFs implemented by the software perform exactly as intended and that they do not perform any unintended functions. Further still, and given the fact that software will possess control over safety‐significant functions and that undesired events are likely to occur, it is important that fault/failure detection, isolation, annunciation, and tolerance is built into the system and software design architectures. The

FHA is the first step in reaching these objectives. The Process Subtasks of the FHA are presented in

Figure 2.3 below.

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Carlos.Y.Velez Highlight

Figure 2.3: Process Task 4.0 Task and Subtasks

The FHA described here is not the same as the FHA described in SAE ARP 4761 that is required for

Airworthiness Release. There are different purposes for the two analyses. The primary purpose of the

FHA described in SAE ARP 4761 is the identification of mishaps and hazards by analyzing the system functionally. Conversely, a primary purpose of the FHA described here and in MIL‐STD‐882E is to identify all system functionality, determine which are safety‐significant and implemented by the software, and then map these SSFs to the software design architecture. Once mapped to the architecture, mitigating requirements can be identified. By performing the FHA described here and in

MIL‐STD‐882E, the analyst will be afforded insight to the mishaps and hazards of the system. It should also be noted that there is no reason why the FHA format cannot be formatted in such a way to meet the intent and purpose of both SAE ARP‐4761 and the safety FHA described here.

3.4.1. Process Subtask 4.1: Functionally Decompose the System

The information contained in the FHA reflects the same level of maturity as the design architecture. This is expected, and reinforces that the FHA must be kept current through all phases of the development lifecycle, to include functional, physical, and contractual changes made under configuration control.

Frequency of updates to the FHA should be specified within the SOW and contract. However, SSSE should update the software inputs to the FHA IAW the software development process and schedule. The format of the FHA should reflect that which will provide the analysis “answers” required by the analyst and criteria of the contract.

The first step of the analysis is to decompose the system. If the system is mature enough, this first step may be a physical decomposition of the system. If the system has not yet been allocated to specific pieces of hardware, this decomposition will be functional. The system must be analyzed functionally from the perspective of both “what the system is documented to do functionally,” and “what you think the system can do functionally.” The former is an assessment of documented functionality from the functional specifications and the latter is assessed by analyzing the functionality of the physical components of the system.