T4_-_Attachment_003_PM_UAS_SSMP_(JAN_2018).pdf

Distribution Statement D:

System Safety Management Plan for

Unmanned Aircraft Systems

JANUARY 2018

C , Project Manager, Unmanned Aircraft Systems

Distribution authorized to the Department of Defense and U.S. DoD contractors only;

Administrative or Operational Use, 30 Sept 2013. Other requests shall be referred to the Program

Executive Office (PEO) Aviation, Unmanned Aircraft Systems Project Management Office (UAS

PMO), Technical Management, SFAE-AV-UAS-TM, Redstone Arsenal, AL 35898-5000.

Approved By:

H

Attachment 003

ProperNJ Text Box

ProperNJ Text Box ii

Table of Contents

1.0 INTRODUCTION

1.1 Purpose

1.2 References

1.3 Scope

1.4 System Safety Program (SSP) Goal

1.5 Policy

2.0 ORGANIZATION AND RESPONSIBILITIES

2.1 General

2.2 Integration of Associated Disciplines

2.3 Responsibilities

2.3.1 Project Manager (PM)

2.3.2 UAS Safety Manager

2.3.3 Product Manager (PdM)

2.3.4 Product Safety Manager (PdSM)

2.3.5 AMCOM Safety Office

2.3.6 Aviation & Missile Research, Development, and Engineering Center (AMRDEC)

2.3.7 Training and Doctrine Command (TRADOC)

2.3.8 Program Executive Officer, Aviation (PEO AVN) Safety

2.3.9 Contractor System Safety Support

3.0 RISK MANAGEMENT

3.1 Hazard Identification

3.1.1 System Safety Analysis Tasks and Products

3.2. Risk Assessment

3.2.1 Hazard Severity Categories

3.2.2 Hazard Probability Levels

3.2.3. Risk Assessment Code (RAC)

3.3 Risk Resolution

3.4 Risk Acceptance

3.4.1 Materiel Developer Risk Acceptance

3.4.2 Interface with User Mission Risk Assessment (and Acceptance) Actions

3.5 Hazard Tracking

iii

3.6 Risk Management for Test

4.0 SOFTWARE SYSTEM SAFETY (SwSS)

4.1 Software Safety

4.2 Software Safety Analysis

4.3 Software Safety Assessment

4.4 Software Verification and Validation

4.5 Software Updates

4.6 Role of Software System Safety Working Group (SwSSWG)

4.7 Role of SSSTRP

4.7.1 Software System Safety Technical Review Panel (SSSTRP) Reviews

4.8 Contracting for Software Requirements

4.8 COTS Validation

5.0 System Safety Working Group (SSWG)

6.0 Safety and Maintenance Notification Messages

7.0 Definitions

8.0 Acronyms

APPENDIX A - Product Manager System Safety Working Group (SSWG) Charter

APPENDIX B - PM UAS Software Safety Minimum Level of Rigor (LOR) Table

APPENDIX C - Safety and Maintenance Notification System (UAS Workflow Diagram)

APPENDIX D – System Safety Risk Assessment (Example Format)

APPENDIX E - SSSTRP Finding/Assessment Response (Template)

1.0 INTRODUCTION

The Project Manager (PM) for Unmanned Aircraft Systems (UAS) has overall responsibility for the life cycle of Army UAS and related systems, which includes ensuring System Safety, as required by Army Regulation (AR) 385-10. These responsibilities include implementing a tailored System Safety Program (SSP) encompassing all systems and development, implementation, and maintenance of a System Safety Management Plan (SSMP) as part of the acquisition strategy for products in PM UAS.

1.1 Purpose

This SSMP establishes management policies, objectives, and responsibilities for developing and executing a SSP for the life cycle of all, current and emerging, UAS Project Office (PO) managed systems.

This plan provides procedures to identify and control or eliminate hazards associated with these systems. This SSMP describes the methodology for accepting residual risks. It also establishes a hazard tracking system (HazTrak) for all UAS PO managed systems.

1.2 References

a. AMCOM Regulation 385-17, Software System Safety, 15 Mar 08.

b. AR 25-50, Preparing and Managing Correspondence, 2 Nov 12.

c. AR 385-10, The Army Safety Program, 24 Feb 17.

d. AR 40-10, Health Hazard Assessment Program, 27 July 2007.

e. AR 750-6, Army Equipment Safety and Maintenance Notification System, 3 Feb 09.

f. ASA (ALT) Memorandum, Subject: Environmental, Safety and Occupational Health (ESOH) Risk

Review, 15 Nov 13.

g. DA PAM 385-16, System Safety Management Guide, 13 Aug 13.

h. JSSEH, Joint Software Systems Safety Engineering Handbook, 1 Apr 16.

i. MIL-STD-882E, System Safety Program Requirements, 11 May 12.

j. PEO AVN 13-08, System Safety Risk Management Process, 27 Sep 13.

k. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, 5 Jan 2012.

1.3 Scope

This SSMP will be executed by the UAS Project Management Office (PMO), who will ensure requirements are appropriately levied on supporting government organizations and on Prime Contractors via contractual statements of work (SOW). The SSMP defines the relationship between the PMO and the U.S. Army Aviation and Missile Command (AMCOM), other governmental agencies, major contractors. It establishes System Safety management responsibilities. The SSMP establishes the methods by which each Product Manager (PdM) monitors, evaluates and ensures the execution of the SSP. This SSMP will be reviewed and updated annually.

1.4 System Safety Program (SSP) Goal

The UAS SSP goal is to identify, assess, and mitigate or eliminate hazards in a timely manner and obtain risk acceptance of residual risks at appropriate levels for hazards associated with system operation, maintenance, and support as defined in approved operational requirements and system specifications.

1.5 Policy

It is the PMO Policy to conduct the following at the PdM level:

a. Search continuously and systematically for potential system hazards and assess their risk in terms of credible severity and probability.

b. Utilize this SSMP, add a product annex, or create a Product SSMP to document significant deviations in the System Safety approach for managing hazards, including hardware and software contributions and controls. Product Annex (es) or SSMP should be staffed via PM-UAS- TM Safety.

c. Use a System Safety Working Group (SSWG) team approach to risk management with particular emphasis on including all stakeholders when assessing universal products (those items common/interoperable across multiple platforms) and how their hazards integrate with other systems.

d. Resolve hazards in a time frame commensurate with the level of risk and program resources.

e. Whenever possible, engineering controls will be used to eliminate hazards, procedure and administrative controls will only be used whenever engineering controls are not feasible (for example, affordability, availability, lack of training resource and/or trained personnel, and so forth).

f. Identify and document hazards and resultant actions in a tracking system through final resolution.

g. Exercise residual risk acceptance in accordance with (IAW) PEO Policy, reference (f).

h. Assist the User in defining materiel and operational constraints, and risks associated with proposed local mission or material changes as an interface with their mission risk assessment process.

2.0 ORGANIZATION AND RESPONSIBILITIES

2.1 General

The PM has overall responsibility for ensuring System Safety throughout all UAS system life cycles. A formal System Safety Working Group (SSWG) will be established by each PdM using the Charter in Appendix A. The SSWG will convene periodically (at least twice per annum) during the life of the system to ensure appropriate coordination of the System Safety concerns and to assist in identification, coordination, tracking, and correction of the System Safety hazards. The SSWG will consist of primary and associate members selected to represent their respective activities. The voting members of the SSWG consist of a representative from Army Engineering Directorate (AED), AMCOM Safety, TCM, Program Executive Office (PEO) AVN and the PM (normally represented by the PM).

The PM (or PdM) Safety Manager facilitates the SSWG and when multiple PdMs are involved, a Safety Manager from each product will be in attendance. In the event of a tie vote, the PM will make the final decision. The SSWG facilitator will enter the voting results into the SSWG minutes along with any supporting information requested to be included by one of the voting members. SSWG meeting minutes will be provided in draft form for the voting members’ concurrence before final signature.

Findings and conclusions of the SSWG will be provided as recommendations to PM-UAS for approval.

2.2 Integration of Associated Disciplines

a. UAS Human Systems Integration (HSI) - System Safety will maintain independence from the HSI domain for day-to-day operations. However, System Safety, through the AMCOM Safety Office, will participate fully as a primary member of the HSI Joint Working Group and will receive and provide input to the HSI program.

b. Test and Evaluation (T&E) Integrated Product Team (IPT) - System Safety specific testing issues and test data will be exchanged to ensure hazards are identified and resolutions verified. The general safety of the test effort will also be reviewed IAW para 3.6. The PdM Test Coordinator is responsible for providing System Safety documentation required by test activities.

c. U.S. Army Human Research and Engineering Directorate (HRED) - System Safety will utilize the

HRED expertise to identify hazards caused or compounded by human performance constraints.

d. U.S. Army Public Health Center (PHC) and the Army Material Command (AMC) Surgeon - System Safety will use medical and occupational health expertise to identify health hazards and to obtain recommendations for their elimination or mitigation. The AMC Command Surgeon is the central point of contact within AMC regarding Health Hazard Assessment (HHA) information, and will coordinate with PHC to establish an Independent Medical Assessor (IMA). System Safety may then coordinate directly with the IMA.

e. Environmental - The SSP may identify environmental issues during the hazard analysis and resolution process. System Safety will coordinate environmental issues with the proper agencies.

2.3 Responsibilities

Individual and organizational responsibilities to implement this SSMP are described in the following paragraphs.

2.3.1 Project Manager (PM)

The PM UAS has overall responsibility for System Safety management of assigned systems. The PM will review the PdM’s System Safety products and staff safety documents for external coordination. The PM will assign a UAS Safety Manager (at the project level to function as a Safety Team Lead) to ensure PdM Safety Manager coordinate activities, cross-level knowledge and support integrated products such as universal UAS products. The PM or designated representative will represent the PM at UAS SSWGs and Co-chair with the AMCOM Safety Representative. In the absence of the PM, the succession of UAS representation at UAS SSWGs is the Chief, Technical Management Division (TMD); Chief, UAS Engineering Operations, or UAS Safety Manager.

The PM will coordinate actions with external agencies and ensure PdM System Safety efforts are conducted proactively within program limitations. The PM Safety Manager will act as the primary POC for execution of this SSMP.

The PM is the risk acceptance authority for Low and Medium level hazards.

2.3.2 UAS Safety Manager

The PM will designate a Project Safety Manager who acts as the focal point for all safety actions. A formal SSWG will be established and convened every 6 months to coordinate system safety concerns as defined in Para 5.0 within. The Project Safety Manager assists in identification, coordination, tracking, and correction of all hazards opened by the SSWG Charter Members as defined in Appendix A.

2.3.3 Product Manager (PdM)

The PdM will:

a. Designate a Product Safety Manager (PdSM) and delineate or delegate appropriate SSP implementation authority.

b. Establish and Charter the SSWG (Appendix A).

c. Ensure that applicable System Safety engineering and management instructions, regulations, specifications, and standards are implemented with contract Statements of Work (SoW) and system specifications.

d. Ensure that specific SSP objectives, requirements and funding are incorporated into planning and execution documents.

e. Assign budget and manpower resources to accomplish System Safety management tasks required by Army regulation, PEO AVN 13-08, and this SSMP.

f. Ensure that Hazard Analyses are performed, documented, and reviewed IAW Army Regulation (AR) and PEO AVN 13-08.

g. Ensure that hazard risk management and residual risk acceptance is accomplished IAW AR and

PEO AVN 13-08.

h. Maintain a documentation system, hazard tracking and/or System Safety Risk Assessment

(SSRA) files, for risk acceptance decisions. HazTrak (https://avnhaztrak.peoavn.army.mil) has been established for this purpose.

i. At each milestone, review the hazards, residual risks, risk acceptance recommendations, and provide Hazard Resolution Plans and status.

j. Establish government and contractor relationships and interactions that will ensure positive contributions to, and an understanding of, contractual System Safety requirements.

k. Establish procedures to evaluate Material Change Programs, and any other configuration change for conformity to System Safety standards.

l. Establish procedures for tracking System Safety performance.

m. Develop procedures for incorporating integrated human factors and health safety data identified by the cognizant disciplines throughout the product lifecycle.

n. Establish relationships with the CBTDEV and the User to ensure that the actual system use environment is known, and make recommendations to the CBTDEV when hazardous differences are identified.

o. Ensure that a safety assessment is conducted for all change proposals to confirm that new hazards are not introduced by design changes.

p. Ensure that Software System Safety (SwSS) is managed IAW PEO AVN 13-08 and this SSMP.

q. Request issuance of Safety and Maintenance Notification by the AMCOM Safety Office in accordance with AR 750-6 (reference c.).

r. Request a HHA from the U.S. Army PHC at each major milestone and provide the most recent version to U.S. Army Test and Evaluation Command (ATEC) 60 days prior to the start of all testing. The most recent HHA shall be provided to the AMCOM Safety Office when requesting a safety and health assessment in support of a Materiel Release.

s. Monitor the Contractor’s SSPP.

https://avnhaztrak.peoavn.army.mil/

2.3.4 Product Safety Manager (PdSM)

The PdSM will:

a. Support and execute safety tasks for the PdM.

b. Use the PEO HazTrak for tracking hazards, findings, supporting information and recommendations to final resolution; the final resolution being an appropriate program decision based on the findings as they relate to program constraints, and/or risk acceptance at the appropriate level.

c. Ensure that HHAs are requested from the AMC Office of the Surgeon in accordance with AR 40-

10 and that resulting issues are presented to the SSWG to be adjudicated as required.

d. Prepare and present appropriate documentation for accepting residual risks IAW PEO AVN 13- 08.

e. Review all relevant reports including (but not limited to): Abbreviated Aviation Accident Reports

(AAAR), Failure Reporting, Analysis and Corrective Action System (FRACAS) Reports, and Preliminary Reports of Aviation Mishaps (PRAM) to identify safety concerns.

f. Convene pre-coordination meetings and/or facilitate the SSWG (Appendix A).

g. Develop a SSWG meeting schedule, record meeting notes, voting member votes, position papers from voting members (if supplied) and distribute SSWG minutes once signed by the PM.

h. Maintain all relevant archival documents including, but not limited to, hazard tracking, deliverable safety reports, and meeting minutes.

i. Ensure all development, sustainment and integration contracts and applicable delivery orders contain the optimum System Safety requirements in accordance with the philosophy of this Plan.

j. Coordinate CBTDEV requests for System Safety assistance in reducing risks identified in their

Risk Management Process.

k. Ensure that System Safety documents required for Milestone Decision Reviews (MDR) are generated and provided for use in the review package.

l. Ensure that Hazard Tracking Records are reviewed prior to each SSWG meeting to determine any change in hazard status, and provide resulting conclusions and recommendations to the group.

m. Prepare a Hazard Executive Summary (EXSUM) to alert the Army Safety Action Team (ASAT)

Chairman when a hazard is identified that has a potentially significant impact on training or operations, IAW PEO Aviation Policy.

n. Respond to accident board findings and recommendations submitted by the U.S. Army Combat

Readiness Center (CRC) IAW PEO Aviation Policy.

o. Prepare Risk Determinations to document, but not accept, risk (e.g. to support safety messages).

p. Prepare and staff Risk Decision Memorandum (RDM) for interim risk pending SSRA staffing, or accept risk where a SSRA is not applicable (such as for test) IAW PEO AVN 13-08.

q. Prepare SSRA Part I (per Appendix D), staff and track through to acceptance of risk per Appendix B.

r. Submit Commander’s Critical Information Requirements (CCIR) relating to mishaps or other safety related events.

s. Provide an initial and mitigated risk determination to AMCOM Safety Office for all ASAM and AMAM Messages along with a recommendation for the type of message to be requested IAW the PEO AVN 13-08 and AR 750-6.

2.3.5 AMCOM Safety Office

The AMCOM Safety Office will:

a. Advise PdM on System Safety requirements.

b. Participate as the SSWG Co-Chairperson.

c. Coordinate on PMO documents relating to System Safety, including recommendations for changes to MIL-Specs and Standards.

d. Assist in maintaining active/working files of all safety related documentation.

e. Track accident findings and recommendations received from the U.S. Army CRC from notification to resolution.

f. Perform System Safety analyses to define specific issues for SSWG.

g. Perform other System Safety support tasks as identified in the matrix support agreement.

h. Coordinate and Issue Safety and Maintenance Notifications IAW AR 750-6 by request from the

PM.

2.3.6 Aviation & Missile Research, Development, and Engineering Center (AMRDEC)

The AED, TMD, SED, and others, as applicable, will provide a description of safety issues identified during design, development, production, and fielding, and contractor quality program and materials evaluations. This includes requests from the field for materiel or operational deviations or waivers presenting a serious or high level risk. They will also apply their expertise toward resolution action identification and implementation.

2.3.7 Training and Doctrine Command (TRADOC)

The TRADOC Capabilities Manager (TCM) will be the system point of contact, unless otherwise directed, for official user coordination on hazard resolution actions. The TCM will also be the point of contact for operational requirements issues.

2.3.8 Program Executive Officer, Aviation (PEO AVN) Safety

PEO AVN Safety Officer has overall responsibility for System Safety management of assigned systems.

The PEO reviews the PM’s SSMP and staff safety documents for external coordination.

2.3.9 Contractor System Safety Support

The Prime Contractor will execute the contracted statement of work, which includes participation as a SSWG member.

3.0 RISK MANAGEMENT

Risk Management (RM) is the process of identifying, assessing, and controlling hazards or risks and making decisions that balance risk costs with mission benefits. All hazards associated with PM-UAS Products will be documented and managed in the PEO HazTrak (https://avnhaztrak.peoavn.army.mil).

The basic steps in the RM cycle are:

a. Perform a systematic analysis using a defined, repeatable process.

b. For each identified issue, determine the most serious credible outcome in terms of severity and probability and assign a Risk Assessment Code (RAC).

c. Based upon the assessed risk, assign a resolution priority and eliminate or control the hazard accordingly.

d. For hazards that cannot be completely eliminated, for whatever reason, perform risk acceptance procedures commensurate with the residual risk level IAW PEO AVN 13-08.

e. Monitor the hazard. All hazards associated with PM-UAS Products will be documented in the

PEO HazTrak.

NOTE: Software embedded in systems presents unique challenges for risk analysis and hazard identification. These challenges are greater for developed, fielded systems. Hazard identification and risk acceptance must be conducted within the landscape of operational requirements, patch updates and information assurance needs. Software hazard analysis for UAS will adhere to the spirit of AMCOM Regulation 385-17 and the criticality matrix of MIL-STD 882E. Software Risk Management is addressed in Section 4.0 within.

3.1 Hazard Identification

The purpose of risk analysis/safety analysis is to identify hazards to personnel, equipment, and or the environment, and generate safety requirements. Hazard identification and tracking will include the entire UAS. Ground Control Station (GCS) or aircraft hazards will be addressed by the cognizant Product Office with PM oversite (as SSWG Chair) to ensure equitable hazard management across product lines.

Whenever possible, the PdSM should attend sister-product SSWGs.

A systematic analysis processes will be used to identify potential hazardous conditions. Analyses are not restricted to MIL-STD-882E processes but will also include reliability, human factors and environmental methods. All means will be used to proactively identify hazards before related mishaps occur in the field. Priority will be given to identification before a design is finalized.

(1) Potential hazards identified during analysis will be tracked as issues until the SSWG adjudicates them.

(2) Each Issue will be expressed using the “Source, Mechanism, Outcome” method to allow for consistent management of risk by the PdM.

(3) Issues can be proposed by any involved party, but must be adjudicated by the SSWG to become a hazard. Issues determined to be “not a credible hazard” will be recorded in the SSWG minutes and, if time and workload permit, recorded in the hazard log and closed.

(4) Software failure is not a stand-alone hazard, rather a source for an eventual outcome (usually with a related hardware mechanism). Refer to Section 4.0 within for management of software hazards.

3.1.1 System Safety Analysis Tasks and Products

System Safety analysis will be conducted early and often in the product lifecycle. Each change in design or function will include a safety analysis to limit the injection of new hazards into the system. The majority of this analysis will be based on vendor documentation, test results and field experience. The safety analysis tasks to be performed by the developer and documented in support of the program shall consist of but are not limited to the following:

a. SSPP IAW Task 102 of MIL-STD-882E

b. Preliminary Hazard List IAW Task 201 of MIL-STD-882E

c. Functional Hazard Analysis (FHA); Analysis must also include failure effects on the aircraft

d. NOTE: The Family of Systems (FoS) FHA database will be provided and shall be used by the developer as the baseline.

e. Preliminary Hazard Analysis (PHA) IAW Task 202 of MIL-STD-882E

f. Failure Modes and Effects Analysis (FMEA)

g. Quantitative Fault Tree Analysis (FTA)

h. Operating & Support Hazard Analysis (O&SHA)

i. Hazard Tracking Reports

j. Safety Assessment Report (SAR) IAW Task 301 of MIL-STD-882E

When issues are presented that relate to non-PM UAS developed or managed hardware or software, the issue will be logged in HazTrak as “Not a UAS Hazard” and transmitted to the cognizant material developer via memorandum. This issue will be closed in HazTrak with a copy of the transmittal memorandum and, whenever possible, a reference to the underlying standard attached.

An example of an issue is a vehicle’s roll-over limits that are not exceeded by addition of UAS equipment during vehicle integration with the UAS system.

Issues that relate to Operational Health standards, such as lifting weight/height, tripping hazards, etc., the appropriate army guidance shall be used to develop labeling and technical manual documentation necessary to meet Army requirements. The issue will be logged in HazTrak as a closed hazard when labeling and Technical Manual ™ changes are complete. Risk acceptance documentation will be completed and managed IAW PEO AVN 13-08. A memorandum from the PdM that references the appropriate Army guidance and certifies completion of the labeling requirement will be uploaded as a supporting document in the HazTrak record and the issue will be closed with a Risk Assessment Code (RAC) of OS (zero-S as defined in Section 3.5) without further voting from the SSWG.

3.2. Risk Assessment

For each issue identified by analysis, the PdSM shall determine the most credible outcome in terms of severity and probability. The Hazard Severity and Hazard Probability Categories described in the following subparagraphs will be used to assign a RAC.

(1) Care must be taken to separate “possible” outcomes from credible outcomes.

(2) Issues and their outcome(s) shall be expressed at the system level to allow a common frame of reference for the SSWG, the PdM and their staff. (i.e. the “fuel starvation” Outcome will not be expressed as “engine failure” when the engine failure would credibly lead to an outcome of “loss of air vehicle” – the system level event).

(3) Expression of risk at the system level is not synonymous with combining multiple sources into a single issue or hazard. In rare cases, with SSWG concurrence, multiple hazards (with multiple sources) may be combined within a single component hazard acceptance document with the focus being elimination of the hazard at the appropriate component, sub-system or system level. For example, multiple alternator failure sources may be combined into a single risk acceptance document if the material solution involves sourcing a replacement alternator.

3.2.1 Hazard Severity Categories

The PEO AVN hazard severity categories assess the consequences of the hazard outcome. Mishap severity categories provide a quantitative and/or qualitative measure of loss that could result from environmental conditions, design inadequacies, procedural deficiencies, or component failure/malfunction. The term “aircraft loss” in PEO AVN 13-08 does not directly correlate to UAS due to the intentionally disparate nature of UAS vs manned systems. The most unique UAS feature is the separation of the flight crew and many of the system components from the air vehicle. UAS severity will be assessed using dollar values as the primary determinant.

Assessments will be conducted on standard basis of issue configuration. If a non-standard configuration change causes a system to exceed the dollar-value threshold for a given risk severity (e.g. a $7M UAS carrying a $5M non-standard payload presents a potential loss greater than $10M), the associated hazards must be re-evaluated and will require separate hazard acceptance(s) for the higher risk configurations. Specific situations must be analyzed by the PdM, the PM UAS and other stakeholders.

Configuration limitations posed by dollar values must be documented as part of the SSRA and/or AWR.

a. Category 1 – Catastrophic: Death or permanent total disability; irreversible significant environmental damage; or monetary loss exceeding $10M.

b. Category 2 – Critical: Severe injury or severe occupational illness (permanent partial disability) or hospitalization of three or more personnel, reversible significant environmental damage or monetary loss exceeding $1M but less than or equal to $10M.

c. Category 3 – Marginal: Minor injury or minor occupational illness (no permanent effect/1 or more lost work days), reversible moderate environmental damage, or monetary loss exceeding $100K but less than or equal to $1M.

d. Category 4 – Negligible: Less than minor injury or occupational illness (less than one lost workday), minimal environmental damage or monetary loss less than or equal to $100K.

3.2.2 Hazard Probability Levels

The hazard probability will reflect the quantitative and/or qualitative expectation that the potential mishap, at the credible severity, will occur during operation.

NOTE: There will be times when an additional probability should be referenced to show a high risk in relation to a specific phase or environment. This can be done in the hazard narrative with an explanation of the specific condition. Probability must be framed in an appropriate exposure interval.

For example, a specific maintenance hazard may have a very low hazard probability due to very infrequent performance. However, if the activity is required, there is a more increased probability of injury. Without an additional condition specific reference point, the actual high-risk activity would be missed.

TABLE 3-1. MISHAP PROBABILITY LEVELS

Level Description Individual Item (qualitative)

Probability (mishaps per 100,000 flight hours)

A Frequent Likely to occur often in the life of an item.

Greater than 100

B Probable Will occur several times in the life of an item.

Less than or equal to 100 and greater than 10

C Occasional Likely to occur sometime in the life of an item.

Less than or equal to 10 and greater than 1

D Remote Unlikely but possible to occur in the life of an item.

Less than or equal to 1 and greater than 0.1

E Improbable So unlikely, it can be assumed occurrence may not be experienced.

Less than or equal to 0.1 and greater than 0.01

F Very Improbable

So unlikely that occurrence may be a complete surprise.

Less than or equal to 0.01 but greater than zero

3.2.3. Risk Assessment Code (RAC)

The RAC is the combination of the hazard severity category and the hazard probability level, written as a number and a letter. An initial RAC is assigned upon hazard identification and may change as the hazard is better defined or mitigation actions are taken. The change must be justified and documented in the Hazard Log, or suitable supporting document. The goal is to complete the mitigation action by bringing the probability to zero. RACs for hazards with no residual risk requiring acceptance are described in paragraph 3.5.h.

TABLE 3-2. RISK MANAGEMENT MATRIX

Severity Probability

Catastrophic Critical Marginal Negligible

1 2 3 4

Frequent >100

A High

AAE

High

AAE

Serious

PEO

Medium

PM

Probable >10 and <=100

B High

AAE

High

AAE

Serious

PEO

Medium

PM

Occasional >1 and <=10

C High

AAE

Serious

PEO

Serious

PEO

Medium

PM

Remote >0.1 and <=1

D Serious

PEO

Serious

PEO

Medium

PM

Medium

PM

Improbable >0.01 and <=0.1

E Serious

PEO

Medium

PM

Medium

PM

Low

PM

Very Improbable >Zero and <0.01

F Medium

PM

Low

PM

Low

PM

Low

PM

RISK ASSESSMENT CODE RISK LEVEL PRIORITY AUTHORITY

1A – 1C; 2A – 2B HIGH URGENT AAE

1D – 1E; 2C – 2D; 3A – 3C SERIOUS CRITICAL PEO

2E; 3D – 3E; 4A – 4D MEDIUM ELEVATED PM*

1F; 2F; 3F; 4E-4F LOW ROUTINE PM*

*Per PEO AVN 13-08, PM system level medium and low risk acceptance authority may not be delegated.

3.3 Risk Resolution

Once the appropriate RAC is determined, the PdM will assign a resolution priority within the overall scope of program efforts and eliminate or control the hazard accordingly. Hazards will be addressed according to the priority of Table 3-2. Potential mitigations should be developed to eliminate or lower the risk to an acceptable level. The SSWG will evaluate potential methods for controlling or eliminating a hazard and estimate the expected effectiveness of each method. The SSWG will provide a report/meeting minutes to the PM and PdM setting forth the risk assessment results based on the hazard control recommendations. All hazards will be annotated and managed in the HazTrak until resolved. Hazards eliminated by design or architecture changes will be re-adjudicated and closed by the

SSWG.

a. The PdM team will eliminate or control hazards as part of the overall product management effort.

b. The total system is evaluated in the PdM systems engineering (and other) efforts, providing a

“top down” and “bottom up” look at safety, reliability, suitability, and supportability within the constraints of cost, schedule and performance.

3.4 Risk Acceptance

3.4.1 Materiel Developer Risk Acceptance

For hazards that cannot be completely eliminated, for any reason, mitigate the risk to the lowest possible level consistent with Operational requirements and resource constraints and perform risk acceptance procedures commensurate with the residual risk level IAW PEO AVN 13-08.

Hazard/Risk resolution recommendations should serve as the initial documentation for a risk-acceptance decision. Table 3-2 defines the Command level decision authority for accepting the risk associated with each hazard.

The consequences of risk acceptance of the proposed configuration and alternative actions should be stated quantitatively when practical. The decision to accept the risk shall also consider impact on schedule, operational effectiveness, and other factors and should be included in the overall program risk assessment. In accordance with AR 385-10, the responsible CBTDEV will make recommendations on risk assessments, and include their recommendations for alternative or supplemental actions.

Risk will be accepted by the appropriate authority IAW PEO AVN 13-08.

The SSRA will be drafted for all serious and higher level risks for which available controls cannot reduce the residual risk to a medium or low level in less than one year. The SSRA will include mitigation plans and an expiration date with the intent of reducing risk. The SSRA will be staffed through the AMCOM Safety Office, to the Commander, AMCOM; Commander, U.S. Army Aviation Center of Excellence (USAACE), prior to forwarding to the PEO for signature or other action.

If a risk is mitigated to the lowest possible level, but not completely eliminated, it may be incorporated into the underlying risk of the system by execution of a memorandum for record which will serve to document that the risk has been reduced to the lowest possible level within the constraints of the program.

3.4.2 Interface with User Mission Risk Assessment (and Acceptance) Actions

User/Operator Risk Assessments are encouraged. When the User requests a deviation from established configuration or procedures, the PdM will address the request, coordinating directly with the requester and the Risk Acceptance Authority.

3.5 Hazard Tracking

IAW PEO AVN Directive, HazTrak will be utilized by the PdM to track all identified hazards at https://avnhaztrak.peoavn.army.mil/.

a. The status of a hazard or issue will be listed as “Proposed” when it is submitted from any source and until opened or dismissed as not a hazard by the SSWG or PdM.

b. A hazard is in the “Open” status when the SSWG or PdM formally acknowledges it.

c. The “Monitor” status identifies a category of open hazards that is assigned by the SSWG or PdM to hazards which are awaiting test completion for better definition of the hazard, hazards awaiting test for substantiation of corrective action, hazards which are based on isolated events and more data is needed to justify corrective action/hazard closure, or hazards for which corrective action has been defined and is in progress.

d. The “Accepted” status applies to hazards if the decision authority (Table 3-2) has given written approval of the final risk category. “Accepted” risks will generally have a periodic review date and, potentially, an expiration date for the acceptance (if set by the acceptance authority).

Open-ended hazard acceptance will be reserved for the very few hazards which have no foreseeable potential for elimination or further mitigation. These hazards should be considered for closure by the Milestone Decision Authority (MDA).

e. Hazards within the PM risk acceptance authority may be accepted without a formal SSRA. The

SSWG will recommend closure to the PM as part of the SSWG briefing and/or minutes. PM signature on the minutes shall constitute interim risk acceptance. The SSWG recommendation and reference to the signed minutes shall be noted in the HazTrak Record.

f. The “Recommended Closed” status applies to hazards which the SSWG or PM has deemed to be impractical to reduce and that further tracking will impair the ability of the SSWG to conduct its chartered tasks.

g. The status of a hazard will be listed as “closed” under normal circumstances if the risk has been eliminated, is determined by the SSWG to be not a credible hazard. Closed hazards may be reopened if circumstances warrant.

h. In the HazTrak Database, hazards closed with no residual risk are defined below. Previously accepted or closed hazards will be reviewed by the PM/PdM Safety Managers and AMCOM Safety prior to SSWG meetings, or at least twice annually for changes in risk. The SSWG will approve recoding and the PM will be notified through the meeting minutes. “Open” or “Monitor” hazards may be recommended for zero residual risk closure with SSWG and PM approval. The HazTrak details will be updated to show the date of the review, the justification for RAC assignment, the action taken by the PM, and the final severity and probability. RACs for hazards with no residual risk will be assigned as follows:

0A (zero A) – Hazards which are no longer valid due to errors, superseded by other hazards and/or similar actions will be administratively coded 0A and the action taken section appropriately annotated.

0R (zero-R) – Hazards eliminated by a materiel/design change, to include a life or overhaul change.

0S (zero-S) – Hazards with no residual risk requiring acceptance by virtue of the design meeting or exceeding all applicable consensus and/or military standards and being operated in an environment consistent with those standards, i.e., being operated with published procedures that may include operating limitations, field inspections, and maintenance procedures.

3.6 Risk Management for Test

The processes discussed in the preceding paragraphs are used for material risks of the UAS fleet. For UAS products involved in testing, hazards shall be assessed by the Test Flight Authority (typically the PdM) and the associated risks will be accepted at an appropriate level.

A Test Flight Authorization (TFA) Memorandum will be developed for each test prior to execution. The format is standard AR 25-50 memorandum format. The TFA will describe the test to be conducted to include a description of the components/functions being tested and success/fail criteria. Other contents at the discretion of the PdM with minimum topics of:

a. Test risk assessments with hazards and mitigations with responsible parties, and Program risk assessment with hazards, mitigations and responsible parties. Also required is an explicit statement of the residual test risk and residual program risk.

b. Test risk analysis and assessment will be included in the TFA along with a program risk analysis and assessment relating to the test activity (e.g. if the test involves the only capital asset in the program, the severity of loss of the test asset increases program risk).

The test risk is accepted when the TFA is signed by the appropriate Risk Acceptance Authority. Low test risk may be accepted at the PdM level with a copy furnished to the PM.

Medium test risk will be accepted by the PM. Acceptance authority for serious (and higher) test risk will be determined on a case-by-case basis at the PM’s discretion.

The TFA will be addressed to the party responsible for execution of the test and a complete copy will be furnished to the PM UAS. The TFA will be signed by the PdM or their delegate (and endorsed by the risk acceptance authority if risk level exceeds the PdM level).

The TFA is not mission risk acceptance. Responsibility for the operational/mission risk assessment for any flight (including test) rests with the appropriate mission risk acceptance authority and shall be conducted IAW AR 385-10 and local Statement of Procedures (SOP).

Test risk will not be adjudicated by the SSWG nor entered into the hazard log. The PdM responsible for the test will assess and record test risk IAW this SSMP. Record keeping after test is at the discretion of the PdM.

4.0 SOFTWARE SYSTEM SAFETY (SwSS)

Within the System Safety organization, SwSS provides the interface between System Safety Engineering and Software Development (SD). Software System Safety is the application of System Safety principles, criteria and techniques to software. The Software Development lifecycle initiates at concept refinement and results in a software release, this lifecycle is executed multiple times during the product acquisition lifecycle. Throughout the SD lifecycle, emphasis should be placed on the system and how software contributes to or mitigates failures. Development of Safety Critical SW should be part of the overall Software Development Plan (SDP). Sound analysis, rigorous testing, and proper verification and validation methods will ensure that safety requirements are met. This process will provide confidence that the software will perform as specified and allow for successful certification.

The PdM will ensure UAS software is developed with the goal of achieving an airworthiness approval recommendation from the SED’s JS-SSA JSSEH Implementation Guide and the SEDs PM Handbook for Aviation Software Airworthiness (PMHASA) provide detailed guidance to ensure software safety and to support the flight software airworthiness approval. While the documents were developed to address new system acquisition, the analysis and activities should be applied to enhancements and modifications of PM UAS legacy systems.

Software hazard analysis has unique challenges. These challenges are greater for developed, fielded systems. Hazard identification and risk acceptance must be conducted within the landscape of operational requirements, patch updates and information assurance needs. Software hazard analysis for UAS will adhere closely to the guidance in AMCOM Regulation 385-17, MIL-STD 882E, JSSEH Implementation Guide, and SED’s PM Handbook for Aviation Software Airworthiness.

4.1 Software Safety

Software Safety success is dependent on a safety-significant software development process, sound hazard assessment process, and accomplishment of the depth and breadth of software analysis validations and verification activities necessary to provide a sufficient level of confidence that a safety-critical or safety-related software function will perform as required. These activities are described as a Level of Rigor (LOR) have been codified and included here as Appendix B. The table in Appendix B contains the PM UAS base Level of Rigor required tasks and minimum standard for LOR artifacts expected in all developments. The LOR artifacts generated as a result of this stringent process will be available for a SSSTRP review, software certification efforts, and ultimately evidence to support a favorable Software Safety Statement for Material Release.

4.2 Software Safety Analysis

Software faults may contribute to hazards, in either control of, or interface with, the supported system.

Software contributions to hazards arise through defects, errors, and omissions, leading to a failure of the system to operate correctly. In depth hazard analysis will be conducted to identify potential or existing software contributions to hazards and requirements developed to either eliminate those hazards or reduce them to an acceptable level. The software safety analysis tasks to be performed by the developer and documented in support of this effort shall consist of but are not limited to the following:

a. Software contributions to identified system hazards and documented in the Preliminary Hazard Analysis (PHA) IAW MIL-STD-882E Task 202.

b. Identification and documentation of System Software Critical Safety Functions (SCSFs) in the

FHA IAW MIL-STD-882E Task 208.

c. Safety Requirements Hazard Analysis IAW Task 203 of MIL-STD-882E, or equivalent in AMCOM 385-17.

d. Software Test Description, Software Test Plans and subsequent Software Test Reports.

e. System Hazard Analysis (SHA) IAW Task 205 of MIL-STD-882E, or equivalent in AMCOM 385-17.

f. Subsystem Hazard Analysis (SSHS) IAW Task 204 of MIL-STD-882E, or equivalent in AMCOM 385- 17.

g. Software Hazard Analysis Reports.

h. Change Impact Analysis, if applicable.

i. Demonstrated LOR Compliance.

NOTE: A list of required Software Development Artifacts is available in SED’s PMHASA, Appendix B, Table 19.

4.3 Software Safety Assessment

Unlike material risks, the assessment of risk due to software cannot rely solely on severity and probability.

Software risk considers the Degree of Control that software exercises over the hardware and the Potential Risk Severity to determine the criticality of the hazard. Finally, software risk, more appropriately, the Software Contribution to System Risk, is quantified by using the tables within MIL-STD 882E.

a. The degree of software control is defined using the Software Control Categories (SCC) listed on MIL-STD 882E, Table IV.

SOFTWARE CONTROL CATEGORIES

Level Name Description

Autonomous

(AT)

Software functionality that exercises autonomous control authority over potentially safety-significant hardware systems, subsystems, or components without the possibility of predetermined safe detection and intervention by a control entity to preclude the occurrence of a mishap or hazard.

(This definition includes complex system/software functionality with multiple subsystems, interacting parallel processors, multiple interfaces, and safety-critical functions that are time critical.)

Semi-

Autonomous

(SAT)

Software functionality that exercises control authority over potentially safety-significant hardware systems, subsystems, or components, allowing time for predetermined safe detection and intervention by independent safety mechanisms to mitigate or control the mishap or hazard.

(This definition includes the control of moderately complex system/software functionality, no parallel processing, or few interfaces, but other safety systems/mechanisms can partially mitigate. System and software fault detection and annunciation notifies the control entity of the need for required safety actions.)

Software item that displays safety-significant information requiring immediate operator entity to execute a predetermined action for mitigation or control over a mishap or hazard.

Software exception, failure, fault, or delay will allow, or fail to prevent, mishap occurrence.

(This definition assumes that the safety-critical display information may be time-critical, but the time available does not exceed the time required for adequate control entity response and hazard control.)

Redundant

Fault Tolerant

(RFT)

Software functionality that issues commands over safety-significant hardware systems, subsystems, or components requiring a control entity to complete the command function.

The system detection and functional reaction includes redundant, independent fault tolerant mechanisms for each defined hazardous condition.

(This definition assumes that there is adequate fault detection, annunciation, tolerance, and system recovery to prevent the hazard occurrence if software fails, malfunctions, or degrades. There are redundant sources of safety-significant information, and mitigating functionality can respond within any time-critical period.)

Software that generates information of a safety-critical nature used to make critical decisions. The system includes several redundant, independent fault tolerant mechanisms for each hazardous condition, detection and display.

Influential

Software generates information of a safety-related nature used to make decisions by the operator, but does not require operator action to avoid a mishap.

No Safety

Impact

(NSI)

Software functionality that does not possess command or control authority over safety-significant hardware systems, subsystems, or components and does not provide safety-significant information. Software does not provide safety-significant or time sensitive data or information that requires control entity interaction. Software does not transport or resolve communication of safety-significant or time sensitive data.

b. The potential risk severity of the hazard combines with the degree of control in MIL-STD 882E, Table V to determine the Software Criticality Index.

SOFTWARE SAFETY CRITICALITY MATRIX

SEVERITY CATEGORY

SOFTWARE

CONTROL

CATEGORY

Catastrophic (1)

Critical (2)

Marginal (3)

Negligible (4)

SwCI 1

SwCI 3

SwCI 4

SwCI 2

SwCI 5

c. The Software Criticality Index (SwCI) is used to define the required LOR tasks.

SwCI

Level of Rigor Tasks

Program shall perform analysis of requirements, architecture, design, and code; and conduct in-depth safety-specific testing.

SwCI 2 Program shall perform analysis of requirements, architecture, and design; and conduct in-depth safety-specific testing.

SwCI 3 Program shall perform analysis of requirements and architecture; and conduct in-depth safety-specific testing.

SwCI 4 Program shall conduct safety-specific testing.

SwCI 5 Once assessed by safety engineering as Not Safety, then no safety specific analysis or verification is required.

d. LOR tasks are performed to assess the software contributions to the system-level risk.

Results of the LOR tasks provide a level of confidence in safety-significant software and document causal factors and hazards that may require mitigation. If the required LOR tasks are not performed, then the system risk(s) contributions associated with unspecified or incomplete LOR tasks shall be documented according to MIL-STD 882E, Table VI. Table VI depicts the relationship between SwCI, risk levels, completion of LOR tasks, and risk assessment. All software developed will maintain current LOR status in development of all affected functions. Affected functions must be tested with regression test of the highest assessed SwCI level for that function.

RELATIONSHIP BETWEEN SwCI, RISK LEVEL, LOR Tasks, AND RISK

Software Criticality

Index (SwCI)

Risk Level

Software LOR Tasks and Risk Assessment/Acceptance

High

If SwCI 1 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as HIGH and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 1 LOR tasks or prepare a formal risk assessment for acceptance of a HIGH risk.

Serious

If SwCI 2 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as SERIOUS and provided to the PM for decision.