IAW JS-SSA-IG Rev.B.pdf

JOINT SERVICES – SOFTWARE SAFETY AUTHORITIES (JS-SSA)

Software System Safety Implementation Process and Tasks

Supporting MIL-STD-882E With Joint Software System Safety Engineering Handbook References

Developed by the JS-SSA Sub-Working Group in Support of the Joint Services Weapon Safety Review (JSWSR)

Boards

April 1, 2016

Distribution Statement A Approved for public release; distribution is unlimited.

This report is provided in fulfillment of the JS-SSA responsibility to advise system safety engineering programs on safety specific issues or concerns. It provides implementation guidance for Software System Safety program requirements specified in MIL-STD-882E and guidance detailed in the JSSSEH.

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

3.1. Process Task 1.0: Prepare the System Safety Management Plan (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 Request for Proposal (RFP) and Statement of Work (SOW)

3.2. Process Task 2.0: Prepare System Safety Program Plan (SSPP)

3.2.1. Process Subtask 2.1: Obtain Inputs from the System Safety Management Plan (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 Level-of-Rigor (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 Subtasks 3.1: Identify Hazards Pertaining to the Baseline System

3.3.2. Process Subtask 3.2: Categorize Hazards with Preliminary RAC

3.3.3. Process Subtask 3.3: Identify Hazard Failure Modes

3.3.4. Process Subtask 3.4: Identify Hazard Causes - Hardware, Software and Human Error

3.3.5. Process Subtask 3.5: Identify Hazard Mitigation Requirements

3.4. Process Task 4.0: Functional Hazard Analysis (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 Safety-Significant Functions

3.4.6. Process Subtask 4.6: Identification of SwCI for SSFs

ii

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

3.4.8. Process Subtask 4.8: Identify Failure Mitigation Requirements

3.5. Process Task 5.0: LOR Allocations to Safety-Significant Functions

3.5.1. Process Subtask 5.1: Assess SSF against Software Control Categories (SCC)

3.5.2. Process Subtask 5.2: Assess the SSF for the Consequence Severity

3.5.3.Process Subtask 5.3: Compare SCC and Severity with the Software Safety Criticality Matrix

(SSCM)

3.5.4. Process Subtask 5.4: Assign the Criticality LOR to the Safety-Significant Function

3.6. Process Task 6.0: Preliminary Safety Requirements Analysis (SRA)

3.6.1. Process Subtask 6.1: Review System and Functional Specifications

3.6.2.Process Subtask 6.2: Identify and Tag Contributing Safety-Significant Requirements (CSSR)

3.6.3. Process Subtask 6.3: Identify and Tag Generic Safety-Significant Requirements (GSSR) .. 20

3.6.4.Process Subtask 6.4: Identify and Tag Mitigating Safety-Significant Requirements (MSSR)

3.7. Process Task 7.0: Perform In-Depth Hazard Analysis

3.7.1. Process Subtask 7.1: Integrate Hazards from the Preliminary Hazard Analysis

3.7.2. Process Subtask 7.2: Categorize Hazard with an Initial RAC

3.7.3. Process Subtask 7.3: Perform In-Depth Hazard Causal Analysis

3.7.4. Process Subtask 7.4: Derive Lower-Level Mitigation Requirements

3.7.5. Process Subtask 7.5: Categorize Hazards with a Final RAC

3.8. Process Task 8.0: Perform Detailed Safety Requirements Analysis

3.8.1. Process Subtask 8.1: Reassess Preliminary Requirements

3.8.2. Process Subtask 8.2: Reassess Mitigation Requirements

3.8.3. Process Subtask 8.3: Verify Requirements in Design

3.8.4. Process Subtask 8.4: Author Appropriate Defects Against Design Requirements

3.9. Process Task 9.0: Perform Safety Requirements Traceability

3.9.1. Process Subtask 9.1: Trace Safety Requirements to Design Architecture

3.9.2. Process Subtask 9.2: Trace Safety Requirements to Hazards

3.9.3. Process Subtask 9.3: Trace Safety Requirements to Implementation

3.10. Process Task 10.0: Perform Code-Level Safety Analysis

3.10.1. Process Subtask 10.1: Determine the Software Functionality to Analyze iii

3.10.2. Process Subtask 10.2: Determine the Software Functionality to be Analyzed

3.10.3. Process Subtask 10.3, Determine the Objectives of Analysis

3.10.4. Process Subtask 10.4, Analyze LOR-1 Software

3.11. Process Task 11.0: Perform Software Test Planning

3.11.1. Process Subtask 11.1: Ensure Correctness and Application of the LOR Test Criteria

3.11.2. Process Subtask 11.2: Ensure Safety Functionality is Tested

3.11.3. Process Subtask 11.3: Comply with the LOR Test Criteria

3.11.4. Process Subtask 11.4: Assist in Writing Test Cases and Test Procedures

3.12. Process Task 12.0: Monitor Safety-Significant Software Testing

3.12.1. Process Subtask 12.1: Ensure Software Testing Conforms to LOR Test Criteria

3.12.2. Process Subtask 12.2: Ensure Safety Functionality is Tested

3.12.3. Process Subtask 12.3: Monitor Test Defects and Corrective Actions

3.12.4. Process Subtask 12.4: Review Final Software Test Results

3.13. Process Task 13.0: Perform Residual Safety Risk Assessment

3.13.1. Process Subtask 13.1: Reassess all Documented Hazards

3.13.2. Process Subtask 13.2: Verify Hazard Mitigation

3.13.3. Process Subtask 13.3: Assess Partial Mitigation or Failure to Mitigate

3.13.4. Process Subtask 13.4: Support Residual Safety Risk Assessment

3.13.5. Process Subtask 13.5: Document and Communicate Residual Safety Risk

3.14. Process Task 14.0: Participate in Life-Cycle Management and Support

3.14.1. Process Subtask 14.1: Assess all Functional and Physical Changes to the System

3.14.2. Process Subtask 14.2: Assess the Change Against Documented Hazards

3.14.3. Process Subtask 14.3: Identify New Hazards, Failure Modes, or Causes

3.14.4. Process Subtask 14.4: Mitigate Hazards, Failure Modes, or Causes

3.14.5. Process Subtask 14.5: Document and Communicate Safety Risk

3.14.6. Process Subtask 14.6: Update all Safety-Related Artifacts

4.0 Acronym List

5.0 Glossary

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 1.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 Task 5.0 LOR Allocation Task and Subtasks Figure 2.7: Process Task 6.0 Safety Requirements Analysis Task and Subtasks Figure 3.0: SSS Process Chart for Detail Design and Implementation Phases Figure 3.1: Process Task 7.0 Perform In-depth Hazard Analysis and Subtasks Figure 3.2: Process Task 8.0 Detailed Safety Requirements Analysis and Subtasks Figure 3.3: Process Task 9.0 Perform 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 10.0 Perform Code Level Analysis and Subtasks Figure 4.2: Process Task 11.0 Perform Software Test Planning and Subtasks Figure 4.3: Process Task 12.0 Monitor Safety-Related Testing and Subtasks Figure 4.4: Process Task 13.0 Perform Residual Safety Risk Assessment and Subtasks Figure 4.5: Process Task 14.0 Participate in Life Cycle Management and Subtasks Figure A.1: Preferred LOR Tailoring Method Example

Appendices

Appendix – A Preferred Level-of-Rigor Table

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 Services SSSE 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 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 proper 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.

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 LOR requirements. The LOR table should be tailored for any given program as agreed to by the Acquirer and Developer.

3.0 Process and Process Tasks for Software System Safety

The process for accomplishing a successful Software System Safety (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 System Safety Engineering (SSE) and SSSE tasks and artifacts necessary to meet the requirements of MIL-STD-882E. 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 items (CDRLs); 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 Define/Tailor the Mishap Risk Matrix, Software Criticality Matrix and associated input definitions Charter the System Safety Working Group (SSWG) to include all managerial, organizational, and technical relationships 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 SSPP, Task 106 HTS, Task 201/202 PHL/PHA, Task 203 SRHA, Task 204 SSHA, Task 205, SHA, Task 206

O&SHA, Task 208 FHA, and Task 301 SAR. As applicable, Task 209 SoS Hazard Analysis may be required.

Define Acquirer specification safety requirements Provide Safety requirements input to other relevant documentation (ex. Software Development Plan (SDP), Test and Evaluation Master Plan (TEMP), System Engineering Master Plan (SEMP), Configuration Management Plan (CMP)) Work with PM to ensure the systems 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 (ex. 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.

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

3.1. Process Task 1.0: Prepare the System Safety Management Plan (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.

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 (Interim) 5000.02 – Operation of the Defense Acquisition System, November 25, 2013 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 Request for Proposal (RFP) and the Statement of Work (SOW), and ultimately flowed down to the developer.

This flow down of the SSMP ensures the Developer’s 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 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 program manager. 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 System Safety Program Plan (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 Request for Proposal (RFP) and Statement of Work (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 RFPs and SOWs 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 System Safety Program Plan (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.

Figure 1.2: Process Task 1.0 SSPP Task and Subtasks

3.2.1. Process Subtask 2.1: Obtain Inputs from the System Safety Management Plan (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 (aka 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. However, it is important to note that Service and Joint Safety Reviews and safety risk assessment/acceptance are based upon the criteria of most current versions of DODI 5000.02 and MIL-STD-882 regardless. 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 Functional Hazard Assessment (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 a Functional Hazard Analysis (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.

3.2.4. Process Subtask 2.4: Prepare Level-of-Rigor (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 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 (SwCI-5) to highest criticality (SwCI-1) as referenced in MIL-STD-882E Table V.

System Functions that are deemed safety-significant (SSF) IAW MIL-STD-882E are assessed for their criticality (see Section’s 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 residual 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 accepted in one contractual activity should never be carried over as the baseline 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 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.

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: the Software Requirements Specification (SRS), Software Development Plan (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 concurred to by the SSWG and 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.

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

Figure 2.1 depicts the initial Developer Preliminary Hazard Analysis (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 top-level mishaps (TLM’s) which are documented within the PHA. The PHA begins with development of the Preliminary Hazard List (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 Subtasks 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 official hazard record keeping system (MIL-STD-882E, Task 106).

3.3.2. Process Subtask 3.2: Categorize Hazards with Preliminary RAC

Each identified and documented hazard and mishap is initially categorized in terms of mishap severity and likelihood of occurrence prior to any mitigation action. 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 Risk Assessment Code (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.

3.3.3. Process Subtask 3.3: 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 subsequent Sub-System Hazard Analyses (SSHA) if the SSHA is a contractually required artifact or deliverable item. 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.

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.

3.3.4. Process Subtask 3.4: Identify Hazard Causes - Hardware, Software and 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. Hazard causes must be integrated 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 against the probability of failure propagation to the top event.

3.3.5. Process Subtask 3.5: Identify Hazard Mitigation Requirements

[Ref: JESSSEH 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. The PHA task concludes with the capture of all PHA analysis data in the Acquirer-approved Hazard Tracking System (HTS).

3.4. Process Task 4.0: Functional Hazard Analysis (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 to obtain 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 safety-significant functions (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 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.

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 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, 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 SW 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. The analysis of the physical attributes of the system is likely to provide insight to “hidden” or undocumented functionality. This is especially true for systems heavily using COTS components.

Figure 2.4: Example FHA Format

Figure 2.4 provides an example of a FHA format that will provide the analyst with the most basic of information required by the analysis. If the analyst (or the Acquirer) requires more than this simple example format can provide, add the appropriate columns to the format to identify and track the information required. The decomposition of the system is documented in Column one. System decomposition can be done in a WBS-like structure which may aid in structure, flow, traceability and assignment of responsibilities. For instance, on large, complex programs such as an Aircraft (Refer:

Figure 2.2) the hazard “Loss of Engine” may be completely under the control of the Engine Integrated Product Team (IPT). The Engine IPT is more likely to support safety if the FHA can readily show the IPT which parts it is responsible for.

3.4.2. Process Subtask 4.2: Identification of All Functionality

Column two of the example FHA format in Figure 2.4 depicts where the system functionality is documented. For the initial FHA, the functionality may be “higher level” functions that haven’t yet been decomposed to lower level functionality. For an initial FHA this is sufficient for this level of analysis maturity as lower-level functionality will likely take on the same criticality as their parent higher-level

FUNCTIONAL HAZARD ANALYSIS

System

Decomposition Individual Functional

Descriptions

Functional Failure Modes

Consequence of Each Failure

Mode

Severity of Consequence of Failure Modes

Safety- Significant Functions

Assignment of SCC and LOR

Map to Software

Design

Failure Mitigation

Requirements

Process Subtask 4.1

Process Subtask 4.2

Process Subtask 4.3

Process Subtask 4.3

Process Subtask 4.4

Process Subtask 4.5

Process Subtask 4.6

Process Subtask 4.7

Process Subtask 4.8 functions. Ensure that all functionality is identified. First, identify what you think it can or should do functionally. Second, compare the functionality identified with the documented functionality of the functional specification and reconcile the two lists. Last, identify any functionality that is identified in hardware literature or the performance specification to determine whether there are “hidden” or unintended functions residing in the system. During this activity, it is also good to keep a list of undesired functions from a safety perspective. It will be imperative to ensure that the system either does not have the capability to perform undesired functions or that the system possesses the necessary inhibits in place to ensure these functions do not occur when they pose a safety risk.

3.4.3. Process Subtask 4.3: Document Functional Failure Consequences

Once all known functionality of the system is identified and documented, each function must be assessed against the following scenarios:

The function is unavailable (does not occur when expected to occur) The function malfunctions (degraded, partial, or unexpected results of the function) The function performs its intended activity but is out of sequence The function performs its intended activity, but at the incorrect time (too early, too late, outside defined window)

When documenting the consequences of functional failure it is important to understand that the consequences can (and will likely) be different for each of the failure scenarios described above. Each functional failure consequence must be documented in the FHA table to ensure that the worst-case scenario is adequately documented.

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

After all functional failure consequences are adequately identified and documented, each must be assessed against the hazard and mishap severity definitions as defined by the SSPP. This is only an assessment against severity of the consequence and not the likelihood that it will occur. Once a severity allocation is determined for each functional failure scenario consequence, these allocations are documented in column five of the example FHA depicted in Figure 2.4. While MIL-STD-882E Task 208 specifies inclusion of a probability component to the analyses, functional failure probability is not determined via the FHA. If appropriate for the program, a column may be added to the analysis worksheet to document the probability objective for the function to be allocated to the functional designer. The probability of a function failing or malfunctioning as a causal factor to a hazard must be accounted for within the context of the hazard (record) that it applies.

3.4.5. Process Subtask 4.5: Identify Safety-Significant Functions

Each functional failure consequence is assessed against the severity definitions and formally documented in the FHA. For an individual function, there may be multiple severity consequences, and severity of consequences for that function. The function takes on the worst-case severity consequence as determined by the analysis. The functions will be identified as having a safety consequence or no safety consequence based upon their linkage to a mishap/hazard. Those with a safety consequence will be referred to as SSFs and be assigned to the following two subcategories:

Safety-Critical Function (SCF): Functions that possess either a Catastrophic or Critical severity consequence Safety-Related Functions (SRF): Functions that possess either a Marginal or Negligible severity consequence

3.4.6. Process Subtask 4.6: Identification of SwCI for SSFs

Software’s functional criticality as described in MIL-STD-882E, Table V, is determined by the unmitigated severity of the consequence of functional failure (or malfunction) in conjunction with the software control category assignment as defined in MIL-STD-882E, Table IV. The result is the SwCI assignment from SwCI-1 to SwCI-5. The SwCI will be assigned for each function assessed. The SwCI assignment become the LOR by definition and provides the software developers and testers with the safety assurance requirements for the design of each SSF.

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

Once all SSFs have been identified, the analyst must map each function to its software design architecture (to either software modules of code or “use cases” in Object Oriented Design (OOD)). This is required both for end-to-end traceability of requirements and to support subsequent detailed analyses. This will be important when specific hazard analysis is accomplished and software causes to hazards are identified and analyzed. This mapping will provide the analyst with a defined point of entry to the software in order to analyze the software’s contribution to hazard initiation or propagation. This mapping will also allow the analyst to determine the simplicity or complexity of the design of the SSFs and the effectiveness of functional and physical partitioning of the software design architecture. An example of the SSF mapping that is required is presented in Figure 2.5.

Figure 2.5: SSF Mapping to Software Design Architecture Example

Function LOR Criticality

CSCI CSC CSU

Weapon Firing LOR 1 High

Target Authenticate

Target AcquisitionWeapon FiringMissile

Missile Fire Command

3.4.8. Process Subtask 4.8: Identify Failure Mitigation…