AMCOM
Regulation 385-17
Software System Safety
AMCOM
Software System
Safety Policy
Headquarters
US Army Aviation and Missile Command
Redstone Arsenal, AL 35898-5000
15 March 2008
UNCLASSIFIED
Commander, US Army Aviation and Missile Command, ATTN: AMSAM-SF, Redstone
Arsenal, AL 35898-5000.
DISTRIBUTION. This publication is approved for public release, distribution unlimited.
FOREWORD. Software currently performs safety-critical functions in many AMCOMmanaged weapon systems. The role of software as a safety-critical subsystem is rapidly
expanding as legacy, developmental, and joint service systems are being integrated into
larger and more complex systems of systems (SOS). SOS requires software to execute
safety-critical functions with little or no Warfighter intervention. Furthermore, the
Warfighter desires increasing capabilities in the areas of embedded training and
concurrent training and operations that rely on safety-critical software. Software defects
affecting safety-critical functions are causes of system level hazards, such as
unplanned missile launch. Multiple software-caused safety hazards, near misses and
restrictions on system capabilities have occurred in fielded systems as a result of
software defects or inadequate specification of software system safety requirements.
AMCOM systems have been, and continue to be, developed under a variety of software
development processes and requirements. Achieving adequate software safety
assurance in AMCOM systems is hampered by the lack of regulatory standards for
software system safety and verification requirements.
An AMCOM Software System Safety regulation is required to enhance Warfighter safety
and effectiveness, to support timely Materiel Release of systems containing safetycritical software, and to provide consistent software system safety application across
platforms and product offices. This regulation provides the overall software system
safety (SwSS) process for U.S. Army Aviation and Missile Command (AMCOM)
programs. It serves as a single source of information to be used for implementing a
range of Department of Defense (DoD), Department of the Army (DA), Military Standard
(MIL-STD), international, commercial and command level standards, regulations and
guideline documents pertaining to SwSS. It is consistent with the responsibilities, policy
and objectives outlined in Army Regulation (AR) 385-10 and DA Pam 385-16.
AMCOMR 385-17
TABLE OF CONTENTS
1. General ..................................................................................................................... 2
a. Introduction ....................................................................................................... 2
b. Purpose and Scope........................................................................................... 2
c. Goals and Objectives ........................................................................................ 3
d. AMCOM Safety Office Software System Safety Organization........................... 4
(1)
Key Personnel and Responsibilities .................................................... 4
2. Applicable Documents .............................................................................................. 5
a. Government Documents ................................................................................... 5
(1)
Specifications ...................................................................................... 6
b. Non-Government Documents............................................................................ 6
(1)
Program Documents ........................................................................... 6
3. Overview................................................................................................................... 6
a. Definitions ......................................................................................................... 6
b. Software System Safety .................................................................................... 8
(1)
System Acquisition Lifecycle ............................................................... 8
(2)
Integration of System Safety (SS) into the Acquisition
Lifecycle .............................................................................................. 8
(3)
Integration of Software System Safety (SwSS) into the
System Safety Program ...................................................................... 8
c. Software versus Hardware Controls................................................................ 10
4. Software System Safety Program........................................................................... 11
a. System Concept Refinement........................................................................... 12
(1)
System Safety Management Plan ..................................................... 13
(2)
Statement of Work............................................................................. 14
(3)
Software System Safety Program Plan ............................................. 14
(4)
Specification Safety Requirements.................................................... 14
(5)
Safety Integration into the Software Development
Process ............................................................................................. 15
(6)
Software System Safety Working Group ........................................... 15
(7)
Software Development Program Phase Safety
Requirements .................................................................................... 15
(8)
Software Safety Analyses and Activities............................................ 16
(9)
Software System Safety Program tailoring ........................................ 16
(10) Software system safety program data and record
retention and archiving ...................................................................... 18
b. Software System Safety during Software Requirements and
Architecture Development ............................................................................... 19
(1)
Identify and Track System Level Hazards ......................................... 20
i
AMCOMR 385-17
(2)
(3)
c.
d.
e.
Identify Safety-Critical Software and SCSFs ..................................... 20
Identify System Level Hardware and Software
Requirements .................................................................................... 20
(4)
Software Safety Requirements for Software
Development ..................................................................................... 21
(5)
Support Configuration Control and Requirements
Management ..................................................................................... 21
Software System Safety during Software Design, Coding, and
Implementation................................................................................................ 21
(1)
Perform Detailed System Safety and Software System
Safety Analyses................................................................................. 22
(2)
Refine SCSFs, Hardware and Software Control
Measures to Mitigate Hazards........................................................... 22
(3)
Ensure and Track Integration of Software Safety
Requirements .................................................................................... 22
(4)
Determine Criticality of SCSFs .......................................................... 22
(5)
Identify Verification Methods and Apply Level of Rigor to
Determine and Specify Software Safety Verification
Requirements .................................................................................... 23
Software System Safety During Software Verification and
Validation ........................................................................................................ 23
(1)
Develop Formal Test and Verification Plans...................................... 23
(2)
Provide Recommendations for Safety Specific Tests........................ 24
(3)
Ensure Safety Requirements are Verified in Accordance
with Level of Rigor and Approved Test Procedures .......................... 24
(4)
Update Safety Traceability Artifacts .................................................. 24
(5)
Monitor Execution of Verification Activities ........................................ 24
(6)
Analyze Verification Results .............................................................. 24
(7)
Track Verification Failures, Corrective Actions,
Implementation and Regression Testing ........................................... 24
(8)
Update Safety Artifacts...................................................................... 24
Software System Safety to Support Software Release ................................... 25
(1)
Review Hazard Data ......................................................................... 25
(2)
Identify Additional Safety Recommendations to Support
Software Release .............................................................................. 25
(3)
Support Final System Safety Risk Assessment................................. 26
5. Hazard Assessment Approach ............................................................................... 26
a. Software Safety Analysis................................................................................. 26
6. Software Safety Verification.................................................................................... 27
a. Software Hazard Control Categories............................................................... 27
ii
AMCOMR 385-17
b.
c.
Software Safety Verification Requirements ..................................................... 29
Software Independent Verification and Validation ........................................... 30
7. AMCOM Software System Safety Technical Review Panel.................................... 31
8. Summary ................................................................................................................ 31
APPENDICES
Appendix A Aviation and Missile Command (AMCOM) Safety Office Integrated
Air and Missile Defense (IAMD) Tailored Software Safety
Requirements Matrix Checklists (Draft) ..................................................... 32
Appendix B AMCOM Safety Office Guidelines for the Use of Re-use, COTS, GFE
and NDI Software....................................................................................... 54
Appendix C Example Safety-Critical Software Functions (SCSFs) ............................... 67
Appendix D Software Safety Requirements Verification Guidelines.............................. 69
Appendix E Evaluation of Software System Safety Programs....................................... 72
Appendix F AMCOM Software System Safety Technical Review Panel
(SSSTRP) Charter ..................................................................................... 80
LIST OF FIGURES
Figure 1. Acquisition Lifecycle ......................................................................................... 8
Figure 2. SSE and SwSS interface with the acquisition and SD ..................................... 9
Figure 3. SwSS Process Overview................................................................................ 11
LIST OF TABLES
Table 1. SS and SwSS during System Concept Refinement ....................................... 12
Table 2. SS and SwSS during Software Requirements and Architecture
Development.............................................................................................. 19
Table 3. SS and SwSS during Software Design, Coding, and Implementation ........... 21
Table 4. SS and SwSS during Software V&V............................................................... 23
Table 5. SS and SwSS to Support Software Release .................................................. 25
Table 6. Software Control Categories .......................................................................... 28
Table 7. Software Hazard Criticality (SHCM) ............................................................... 28
iii
AMCOMR 385-17
ACRONYMS & ABBREVIATIONS
AMC
AMCOM
AMRDEC
AR
ASTS
CCB
CDRL
CECOM
CM
CONOPS
COTS
CR
CRC
DA
DoD
EMI
FMEA
FTA
GFE
GOTS
HMI
HRI
HW
IAW
IPT
ISSRB
IV&V
JSSSC
Army Materiel Command
Aviation and Missile
Command
Aviation and Missile
Research, Development
and Engineering Center
Army Regulation
AMCOM Safety Tracking
System
Configuration Control
Boards
Contract Deliverable
Requirements List
CommunicationsElectronics Command
Configuration Management
Concept of Operations
Commercial-Off-The-Shelf
Change Request
Cyclic Redundancy Check
Department of the Army
Department of Defense
Electron Magnetic
Interference
Failure Modes and Effects
Analysis
Fault Tree Analysis
Government Furnished
Equipment
Government-Off-The-Shelf
Human Machine Interface
Hazard Risk Index
Hardware
in accordance with
Integrated Product Team
Ignition System Safety
Review Board
Independent Verification
and Validation
JSSSH
LCMC
MAP
MDA
MIL-STD
MRRB
NAVSEA
NDI
NSR
O&S
PHA
PHL
PLV
PM
PO
RF
RFP
SAR
SC
SCF
SCSF
SD
SDD
SDP
SE
SED
SHA
iv
Joint Software System
Safety Committee
Joint Services Software
System Safety Handbook
Life Cycle Management
Command
Missile Defense Agency
Assurance Provisions
Missile Defense Agency
Military Standard
Material Release Review
Board
Naval Sea Systems
Command
Non-Developmental Item
Non-Safety Related
Operations and Support
Preliminary Hazard Analysis
Preliminary Hazard List
Program Load Verification
Program Manager
Project Office
Radio Frequency
Request for Proposal
Safety Assessment Report
Safety-Critical
Safety Critical Function
Safety-Critical Software
Function
Software Development
Software Design
Document/Description
Software Development Plan
Systems Engineering
Software Engineering
Directorate
Safety Hazard Assessment
AMCOMR 385-17
SHCI
SHRI
SHCM
SME
SOW
SQA
SR
SRCA
SS
SSE
SSHA
SSMP
SSP
SSPP
SSR
SSRA
System Safety Risk
Assessments
SSSTRP Software System Safety
Technical Review Panel
SSWG
System Safety Working
Group
STANAG Standardization Agreement
SW
Software
SwSS
Software System Safety
SwSSPP Software System Safety
Program Plan
SwSSWG Software System Safety
Working Group
TIR
Test Incident Reports
TM
Technical Memo
TR
Technical Report
UHF
Ultra High Frequency
VCRM
Verification CrossReference Matrix
V&V
Verification and Validation
Software Hazard Criticality
Index
Software Hazard Risk Index
Software Hazard Criticality
Matrix
Subject Matter Experts
Statement of Work
Software Quality Assurance
Safety-Related
Safety Requirements
Criticality Analysis
System Safety
System Safety Engineering
System Safety Hazard
Analysis
System Safety Management
Plan
System Safety Program
System Safety Program
Plan
System Safety
Requirements
v
AMCOMR 385-17
1.
GENERAL
This regulation describes the overall software system safety (SwSS) process for U.S.
Army Aviation and Missile Command (AMCOM) programs. It serves as a single source
of information to be used for implementing a range of Department of Defense (DoD),
Department of the Army (DA), Military Standard (MIL-STD), international, commercial
and command level standards, regulations and guideline documents pertaining to
SwSS. It is consistent with the responsibilities, policies and objectives outlined in Army
Regulation (AR) 385-10 and DA Pam 385-16.
a. Introduction
A number of SwSS guidance documents have been developed (STANAG 4404,
CECOM TR 92-2, Joint Services Software System Safety Handbook (JSSSH), NAVSEA
SW020-AH-SAF-010). Generally, these are guidance documents and not requirements
standards. The pace of advances in software development (SD) techniques has
rendered some sources obsolete or has introduced new safety concerns. Software
applications such as firmware and programmable logic devices present safety issues.
An approved SwSS standard for SD, design, testing, and verification requirements is
needed for safety-critical SD programs within AMCOM.
b. Purpose and Scope
The primary purpose of this regulation is to provide a tailorable set of software safety
requirements to be used by system safety (SS) engineers, project office (PO) SS
management personnel, and contractor SwSS personnel in carrying out the SS
responsibilities for safety-critical SD programs. It identifies responsibilities for SwSS and
describes the various SwSS tasks and processes to be implemented as part of a SS
and SD program.
The scope of this regulation applies to all System Safety Programs (SSPs) under the
management authority of AMCOM Life Cycle Management Command (LCMC). Its
scope includes the SwSS activities to be accomplished in all phases of a system
lifecycle, beginning with concept refinement, and continuing through technology
development, system development and demonstration, production and deployment,
operations and support (O&S) (to include training, embedded training and concurrent
operations and training), and disposal of the system. It is recognized that many AMCOM
managed programs are already either far into development or fielded. The Government
PM and AMCOM Safety Office must coordinate and agree upon a practical technology
phase-in for the requirements of this regulation. However, even mature programs
should schedule periodic presentations to the AMCOM SSSTRP in order to assess their
safety and risks until a phase-in of this regulation is accomplished. New AMCOM
managed programs must meet the requirements of this regulation.
This regulation also addresses contractor SwSS tasks, as appropriate to support the
Army’s development of contract SS requirements, to aid in monitoring and evaluating
contractor SS performance. In this regard, it includes certain Army expectations
2
AMCOMR 385-17
regarding contractor safety performance that are critical to the Army’s safety risk
management process.
The requirements of this regulation can be, and are encouraged to be, tailored for each
specific program, provided tailoring is coordinated and approved by the respective
Government Program Management Office and the AMCOM Safety Office prior to
implementing. Substitution of equivalent or more stringent industry standards for the
requirements given in this regulation is allowed, provided approval is received from the
Government Program Management Office and the AMCOM Safety Office.
AMCOM Aviation SwSS programs must meet the requirements of this regulation.
However, AMCOM Aviation programs may use DO-178B, Software Considerations in
Airborne Systems and Equipment Certification, as guidance in establishment of SwSS
program requirements within aviation software development. AMCOM programs must
also meet any additional international SwSS requirements that may be applicable as a
result of foreign military sales.
c. Goals and Objectives
The SSP goal is to ensure that design and operations meet applicable safety
requirements, all hazards associated with the system are identified and eliminated, or
controlled in a manner consistent with program objectives and constraints. The goal of
SwSS is to provide requirements and guidance for accomplishing the SSP goals for
safety-critical software subsystems throughout the system’s acquisition life-cycle. The
SSP also provides for management visibility of safety risks inherent in design and
planned operations, and defines the process required for management to formally
reduce or accept the SS risks.
The primary objectives of Army SSP, supported by the SwSS effort, are as follows:
A. Enhance operational readiness and mission effectiveness by ensuring measures
to prevent accidents and minimize their effects are incorporated in system
designs.
B. Identify all hazards associated with the system, and ensure they are eliminated,
or effectively controlled, through timely incorporation of safety features in design
and procedures.
C. Ensure that safety risks due to unknowns associated with hazards and
effectiveness of hazard controls are minimized through testing and analysis
during system development.
D. Ensure that safety features are verified for compliance with requirements, and for
consistency with safety recommendations, where practical, through test; and that
any identified shortcomings are resolved and documented.
E. Identify and assess the risks associated with residual hazards, and ensure they
are accepted by the appropriate risk management authority and documented.
F. Apply effective hazard identification and risk management practices throughout
the system’s lifecycle; and for all configuration and mission variations, and for all
design and procedure changes.
3
AMCOMR 385-17
d. AMCOM Safety Office Software System Safety Organization
The Chief, AMCOM Safety Office has established the position of AMCOM SwSS
Program Manager (PM) to serve as the AMCOM Safety Office subject matter expert in
SwSS. The mission of the AMCOM SwSS PM is to:
• Serve as the AMCOM Safety Office central point of contact regarding SwSS of all
AMCOM managed programs.
• Chair the AMCOM Software System Safety Technical Review Panel (SSSTRP).
• Ensure SwSS is adequately addressed on all AMCOM programs.
• Develop SwSS policy for AMCOM managed programs.
• Interact with joint and other Army and Service agencies to coordinate SwSS reviews.
• Ensure SwSS policy is adequately addressed in SSMPs.
• Ensure contractor SSPs comply with the requirements of this regulation.
• Ensure SwSS training and education is conducted for AMCOM Safety Office
personnel and other AMCOM personnel, as necessary.
(1) Key Personnel and Responsibilities
AMCOM SAFETY OFFICE SOFTWARE SYSTEM SAFETY PROGRAM MANAGER –
The AMCOM SwSS PM reports directly to the Chief, AMCOM Safety Office, on matters
related to SwSS for AMCOM SSPs. The AMCOM SwSS PM has the overall
responsibility for ensuring SwSS is adequately addressed on AMCOM managed
programs. Key responsibilities include: AMCOM SwSS Policy and Guidelines, ensure
that AMCOM Software Safety Policy and Guidelines are addressed across all AMCOM
managed programs, training to support AMCOM SwSS Policy, and serve as Chair of
the AMCOM SSSTRP. The AMCOM SwSS PM coordinates SwSS issues and concerns
with the AMCOM Safety Office SS PM. The AMCOM SwSS PM will provide technical
support and subject matter expertise to the Chief, AMCOM Safety Office in coordinating
with Government Program Managers on implementation of this regulation.
GOVERNMENT PROGRAM MANAGER – PM responsibilities are defined in AR 38510. The PM is responsible for ensuring the SSP (which includes SwSS) is implemented
and has adequate funding and resources. The PM is responsible for coordinating with
the AMCOM Safety Office on an approved implementation plan and schedule for this
regulation. In addition, software Independent Verification and Validation (IV&V) efforts
are funded by the individual AMCOM PMs.
GOVERNMENT PROGRAM SAFETY MANAGER – The Government Program Safety
Manager is the PM’s agent charged with the responsibility of ensuring the SSP defined
in the program’s System Safety Management Plan (SSMP) is implemented. The
Government Program Safety Manager is responsible for ensuring the program’s SSMP,
Statement of Work (SOW), Request for Proposal (RFP), specifications and contractor’s
SSP adequately address the requirements and guidelines of this regulation. The
Government Program Safety Manager is the primary interface to the contractor’s SS
manager and team. In that role, he or she is responsible for monitoring and ensuring the
contractor SSP complies with contractual safety requirements, which should include
4
AMCOMR 385-17
compliance with this regulation. The Government Program Safety Manager is the PM’s
primary interface with the AMCOM Safety Office, AMCOM SwSS Lead for program
related SwSS matters, and SSSTRP.
The Government Program Safety Manager is Chair or Co-Chair (with the contractor SS
Manager if specified in the System Safety Working Group (SSWG) charter) of the
program’s SSWG and is responsible for ensuring implementation and execution of the
SSWG’s responsibilities.
CONTRACTOR PROGRAM MANAGER – The Contractor PM has parallel
responsibilities to the Government PM, but those responsibilities apply to contractor
activities, including the contractor SSP. The Contractor PM is the primary interface
between the contractor and Government PM. The Contractor PM is ultimately
responsible for implementation and execution of the contractor’s SSP and its
compliance with contractual requirements.
CONTRACTOR SYSTEM SAFETY MANAGER – The Contractor SS Manager is the
Contractor PM’s agent charged with the responsibility of ensuring the SSP defined in
the program’s System Safety Program Plan (SSPP) is implemented. The Contractor SS
Manager is responsible for ensuring the program’s compliance with the SSPP, SOW,
RFP, specifications and sub-contractor’s SSP, and that those documents and programs
adequately address the requirements and guidelines of this regulation. The Contractor
SS Manager is the primary interface to the Government Program Safety Manager.
The Contractor SS Manager may be the Co-Chair (with the Government Program
Safety Manager if specified in the SSWG charter) of the program’s SSWG. The
Contractor SS Manager will chair contractor safety working groups, as well as provide
safety support to Integrated Product Teams (IPTs), working groups, and program
processes.
CONTRACTOR SOFTWARE SYSTEM SAFETY ENGINEER – Supports the Contractor
SS Manager in the areas of SwSS.
SOFTWARE INDEPENDENT VERIFICATION AND VALIDATION – Each AMCOM PO
is responsible for funding its IV&V efforts. IV&V responsibilities may include
independent review and assessment of SwSS programs, safety requirements, and
verifications per the directed scope of the IV&V contract.
2.
APPLICABLE DOCUMENTS
a. Government Documents
• DoD 5000.1, The Defense Acquisition System
• DoDI 5000.2, Operation of the Defense Acquisition System
• DoDI 5000.61, DoD Modeling and Simulation (M&S) Verification, Validation, and
Accreditation (VV&A)
• AR 385-10, The Army Safety Program
• DA Pam 385-16, System Safety Management Guide
• MDA-QS-001-MAP, Missile Defense Agency (MDA) Assurance Provisions (MAP)
5
AMCOMR 385-17
• Joint Software System Safety Committee (JSSSC) Software System Safety
Handbook (JSSSH)
• NASA-GB-1740.13, NASA Guidebook for Safety Critical Software
Specifications
•
•
•
•
•
•
MIL-STD-882D, Department of Defense Standard Practice for System Safety
MIL-STD-882C, System Safety Program Requirements
SED-SES-PMHSS 001, Program Manager Handbook for Software Safety
CECOM TR 92-2, Software System Safety Guide
DO-178B, Software Considerations in Airborne Systems and Equipment Certification
NAVSEA SW020-AH-SAF-010, Weapons System Safety Guidelines Handbook
b. Non-Government Documents
Program Documents
• IEEE Std 1228-1994, IEEE Standard for Software Safety Plans
• STANAG 4404 – Edition 2, Safety Design Requirements and Guidelines for Munition
Related Safety Critical Computing Systems
• AOP-52 Edition 1 – Draft, Guidance on Software Safety Design and Assessment of
Munition-Related Computing Sensors
• IEC 61508 – Functional Safety of Electrical/ Electronic/ Programmable Electronic
Safety-related Systems
3.
OVERVIEW
a. Definitions
The following definitions and terminology are used in developing this regulation:
WILL – Used to indicate a Government requirement.
SHALL – Used to indicate a Contractor requirement or Government Agency software
developer requirement.
SOFTWARE – Software is a combination of associated computer instructions and
computer data that enable a computer to perform computational or control functions.
Software includes computer programs, procedures, rules, and any associated
documentation pertaining to the operation of a computer system. Software system
safety requirements apply to firmware and software burned into programmable logic
devices, such as field programmable gate arrays (FPGA).
FIRMWARE – Software that resides in a nonvolatile medium that is read-only in nature,
which cannot be dynamically modified by the computer during processing (write
protected during operation).
SAFETY-CRITICAL – A function that has been determined, through SS analysis, to
potentially contribute to a catastrophic or critical SS hazard if not performed correctly. A
6
AMCOMR 385-17
function whose failure may either directly result in the identified hazard(s), present
erroneous information to an operator/user whereby they could initiate the hazard
occurrence, or results in the transmission of erroneous information to another safetycritical system, which in turn may enter into a hazardous condition.
SAFETY-RELATED (SR) – A function that has been determined, through SS analysis,
to perform a function related to safety, but is not safety-critical. Software functions,
whose failures do not directly result in a catastrophic or critical hazardous condition (i.e.
the functions provide safety related information (example warnings and alerts, cautions,
error logging)) or the consequence of SR function failure is a hazard of Marginal or
Negligible Mishap/Hazard Severity.
NON-DEVELOPMENTAL ITEM (NDI) – Items (hardware, software,
communications/networks, etc.) that are used in the system development program, but
are not developed as part of the program. NDIs include, but are not necessarily limited
to, Commercial-Off-The-Shelf (COTS), Government-Off-The-Shelf (GOTS),
Government Furnished Equipment (GFE), Re-use items. Previously developed items
provided to the program “as is”.
COMMERCIAL-OFF-THE-SHELF (COTS) – Previously developed items that are
commercially available from existing inventory.
GOVERNMENT-OFF-THE-SHELF (GOTS) – Previously developed items that are
available for procurement from existing Government inventory.
GOVERNMENT FURNISHED EQUIPMENT (GFE) – Property in the possession of or
acquired directly by the Government, and subsequently delivered to or otherwise made
available to the contractor for use.
GOVERNMENT FURNISHED INFORMATION – Information in the possession of or
acquired directly by the Government, and subsequently delivered to or otherwise made
available to the contractor for use. Government Furnished Information may include
items such as lessons learned from similar systems or other data that may not normally
be available to non-government agencies.
RE-USE ITEMS – Items previously developed under another program or for a separate
application that are used in a development program.
SOFTWARE RE-USE – The use of a previously developed software module, or
software package, in a software application for a developmental program.
SOFTWARE DEVELOPER – Organization (Contractor, Other Government Agency,
etc.) charged with the responsibility for developing AMCOM LCMC-managed program
software.
SAFETY ASSURANCE – Adequate confidence and evidence, through due process,
that safety requirements have been met.
7
AMCOMR 385-17
b. Software System Safety
(1) System Acquisition Lifecycle
The acquisition lifecycle, defined in DoDI 5000.2, is shown in Figure 1 below.
Development proceeds in accordance with the figure, beginning with Concept
Refinement. At pre-determined points in the development, assessments are made to
determine if the program is ready to proceed to the next development phase. In
preparation for each major milestone, a number of intermediate reviews occur.
Figure 1.
Acquisition Lifecycle
(2) Integration of System Safety (SS) into the Acquisition Lifecycle
SS is the application of engineering and management principles, criteria, and
techniques to achieve acceptable mishap risk within the constraints of operational
effectiveness and suitability, time, and cost, throughout all phases of the system
lifecycle. SS hazard analyses and processes are tied to the program’s acquisition
lifecycle and processes. The SSPP defines the interactions, requirements and data
products required for the SSP to support the Acquisition Lifecycle. The System Safety
Engineering (SSE) organization is responsible for compliance with acquisition milestone
safety requirements.
(3) Integration of Software System Safety (SwSS) into the System Safety Program
Within the SS organization, SwSS provides the interface between SSE and SD. SwSS
is the application of SS principles, criteria and techniques to software. The SD lifecycle
is executed one or more times during the product acquisition lifecycle. SD lifecycles
initiate at concept refinement and end with a software release. In general, multiple
software releases may be required to occur during acquisition, based upon
User/Operational needs, test events, and/or product release strategy (spirals, spinouts,
limited capability, etc.). Releases subsequent to the initial software release typically
build upon that initial release with additional capabilities, enhancements to existing
capabilities, and corrections to known defects. Figure 2 gives a general overview of how
SSE and SwSS interface with the acquisition and SD processes.
8
AMCOMR 385-17
Figure 2.
SSE and SwSS interface with the acquisition and SD
Software comprises a major subsystem of many Army Materiel Command (AMC)
systems. Increasingly, software is being procured, re-used, or designed and developed
to control hardware that performs safety-critical functions. This includes increasingly
autonomous and unmanned systems, as well as the integration of multiple safety-critical
software systems into Systems of Systems configurations. Software alone is not a
safety issue; it is only an issue in the context of these larger systems and the hardware
with which it interfaces. Hence, SwSS must begin with an understanding of the larger
system and its mission/capabilities and be considered in the context of the system’s
associated hardware, environment, operators, and interfaces. The safety premise
driving the analyses is that uncontrolled software hazard contributors can be
propagated, via the interfaces, onto supported hardware and systems, and that those
systems may be placed into a hazardous condition as a result.
Optimally, SwSS is an integral aspect of the system and SD processes. Not only is this
the optimum method for identification and control of software contributions to system
level hazards, it is also the optimum means to minimize impact to the overall SD cost
and schedule. This regulation outlines an acceptable approach to assuring that
identified potential hazard causes in safety-critical software are mitigated. Included in
Appendix A is a set of detailed requirements for SD efforts. Detailed software safety
analyses and verification activities provide evidence that safety risks associated with the
use of safety-critical software are mitigated.
Software’s contribution to system level hazards must be assessed within a structured
and disciplined system safety program. Section 4 of this regulation addresses SwSS
program requirements within both the SD and SS processes to identify and incorporate
9
AMCOMR 385-17
hazard mitigation measures (controls) into the design as early as practical. This proactiveness enhances early correction of safety issues and results in the least impact to
cost and schedule. Software hazard controls are specified through requirements and
those requirements are traceable to both the hazard analyses and the software design
and implementation. The SwSS program must be able to provide evidence of end-toend traceability (from system assessment and hazard identification through verification
of safety controls) to satisfy software safety assurance requirements. The program’s
implementation of the requirements in this regulation, to include evidence of traceability,
should be specified in the SSMP, the contractor’s SSPP and software development
documentation.
Detailed implementation guidance for the requirements in this regulation is readily
available in the reference documentation and this regulation does not attempt to repeat
that level of detail.
The existence of this regulation should not discourage or prohibit the imposition of
additional or more stringent requirements where the need exists. An assessment should
be made for each specific software project to ensure adequacy of coverage and safety
assurance. Where this regulation is invoked for a project engaged in producing several
software products, the applicability of the document should be specified for each of the
software products encompassed by the project. The latest issues of the following
documents provide guidelines that SS and SwSS should mine for requirements and
processes to insert into each program. Successful incorporation, implementation, and
execution within the program development and safety efforts will enhance the potential
of achieving software safety assurance for the program.
• Joint Services Software System Safety Handbook
• NAVSEA SW020-AH-SAF-010, Weapons System Safety Guidelines Handbook
• STANAG 4404, Ed. 1, Safety Design Requirements and Guidelines for Munition
Related Safety Critical Computing Systems
• DO-178B, Software Considerations in Airborne Systems and Equipment Certification
c. Software versus Hardware Controls
In general, a software only approach to weapons system and munitions safety has
difficulty obtaining review board approval (Ignition System Safety Review Board
(ISSRB), Fuze Board, and Materiel Release Review Board (MRRB)). Specifically, the
safety requirements for munitions and ordnance implemented through hardware
designs are not directly replaceable by implementation of software (including firmware
and programmable logic devices) controls. For example, an initiator that cannot pass
the electrical stimulus tests of MIL-STD-1901A requires a physical interrupt in the
ordnance initiation train to preclude the potential for inadvertent activation of the
ordnance device. A software control cannot be used to meet the requirement for
physical interruption, because the design would still not be able to pass the electrical
stimulus tests. However, if the hardware design is compliant with the applicable
requirements standards, independent software controls may be acceptable to augment
mitigation of the risk of inadvertent system activation provided the software design and
independence of the software controls is sufficiently verified.
10
AMCOMR 385-17
4.
SOFTWARE SYSTEM SAFETY PROGRAM
Figure 3 is provides a graphical depiction of the SwSS processes detailed in this Section.
1 System Concept
Refinement Phase Identify
3 Software Design, Code and Implementation Phase
Program Initiation/Safety
Planning/System Assessment
• Assess the user needs, system
capabilities, etc.
• Develop safety management
documentation
• Assess system and SW
development structure and
processes.
• ID resources req’d, SOW & RFP
inputs
• Tailor the SS and SwSS programs
• Integrate SwSS processes within the
SW development (SDP, SDD, SEP)
• Initiate hazard analysis activities
Execute the SwSS Program. Mitigate SW Hazard Causes
• Perform detailed SS and SwSS analyses
• Refine SCSFs.
• Identify detailed hazard control measures
• Specify safety requirements in SW requirements documentation
• Determine verification methods for safety requirements (A, I, D, T)
• Track integration of SW control measures into the system level hazard
analyses, system and SW requirements, and design documentation,
including requirements Tag and Hazard Links
• Determine Safety-criticality of SW and SW reqts.
• Assess Level of Rigor and verification requirements for Safety-critical SW
• Assess SW hazard controls as hazard risk reduction measures
Iteration and
Feedback
2 Software Requirements
and Architecture
Development Phase –
Identify & Assess
Identify System Hazards and SCSFs
• Identify and track system level
hazards
• Identify SCSFs
• Identify SW contributions to
identified system hazards
• Identify, Tag in requirements
database, and Link to Hazards
System Level Safety Requirements
(HW & SW)
• Identify, Tag and Link to Hazards
System Level Software Development
Safety Requirements
• Support Configuration Control
Process
Figure 3.
4 Software Test, Verification and Validation Phase
Monitor Test, Verification, and Validation
• Ensure unit, system and integration test plans address SW safety Level of
Rigor.
• Support development of safety specific test cases
• Monitor test and verification activities
• Review results of test and verification activities
• Ensure test failures related to safety are documented, corrective actions
identified and implemented, and regression testing performed
• Update requirements tracking database and hazard tracking logs to reflect
verified requirements
5 Software Release Phase
Support Software Release/Assess Hazard Risk /Track Risks to
Acceptance
• Monitor software release process
• Review system level hazards, controls and verifications
• Assess adequacy and independence of hazard controls
• Determination of formal final and/or residual risk
• Support development of SSRAs for residual risks
• Monitor software issues and resolutions after fielding
SwSS Process Overview
11
AMCOMR 385-17
The SwSS activities, roles, and responsibilities described in this section of the
document apply to all AMCOM LCMC-managed programs’ SDs and include Re-use,
COTS, GFE, and NDI as well as firmware and programmable logic devices that may be
implemented on the program. Appendix B provides AMCOM Safety Office guidelines for
programs that implement Re-use, COTS, GFE and other NDI.
Models and simulations that are used to support software system safety verification
shall be accredited in accordance with DoDI 5000.16, DoD Modeling and Simulation
(M&S) Verification, Validation, and Accreditation (VV&A). Models and simulations shall
be validated against actual hardware and data.
a. System Concept Refinement
SS and SwSS activities and artifacts during concept development to support safety
program initiation and system assessment shall include the items identified in Table 1.
Table 1. SS and SwSS during System Concept Refinement
Activity
Primary Responsibility
Supporting Responsibility
Artifacts Produced
Assess User Needs, System
Capabilities & Requirements,
CONOPS, Life-cycle data,
program schedules, etc.
SSE, SwSS
Program Management
Initial SS assessment,
preliminary identification of
safety resources required
Assess program development
processes (hardware (HW),
software (SW))
SSE, SwSS
PM, Systems Engineering
(SE), SD
SwSS approach, initial
tailoring of standard SSE &
SwSS processes, SwSS reqts.
for SD process
Develop SSE & SwSS inputs
to RFP and SOW
SSE, SwSS
RFP Team
SSE & SwSS requirements for
contractor’s programs
Tailor SSE and SwSS
programs
SSE, SwSS
SE, SD
Tailored SSE and SwSS
program and processes
Develop SS Management and
Programmatic documentation
SSE, SwSS
PM, SE, SD,
SSMP (Government), SSPP
(Contractor), Software System
Safety Program Plan SwSSPP
(Contractor)
Begin IPT support and
integrate SS and SwSS
processes into system and SD
SSE, SwSS
All
SSE and SwSS inputs to
documentation and processes
(e.g. Software Development
Plan (SDP), Software Design
Document/Description SDD,
SEP)
Initiate SSE and SwSS
activities
SSE, SwSS
All
Inputs to Software
Requirements and
Architecture Development
Phase
System capabilities and requirements are identified from the available documentation
and specifications. Examples of system capabilities and requirements include:
• Ordnance activation and missile launch to counter identified threats
• Command and control of missile defense activities to increase capabilities against
identified threats
• Presentations and displays of information and data required to support engagement
decisions (includes decisions to cease or halt pending/planned engagements) to
improve Warfighter effectiveness
12
AMCOMR 385-17
• Radio Frequency (RF) sensor surveillance and fire control activities to counter threats
• Aircraft control systems to provide terrain following flight
• Unmanned vehicles and aircraft remote control operations
SS and SwSS personnel shall initiate system level hazard identification, hazard
analysis, and hazard tracking based upon the assessment of the system capabilities.
The safety requirements contained in MIL-STD-882, AR 385-10, DA Pam 385-16, and
past experience with similar developmental programs support the system-level
identification of hazards and the hazard analysis at this early stage of program
development. This initial assessment supports identification of safety focus areas and
safety resources required for the program, as well as subsequent identification of
safety-critical software functions (SCSFs).
As hazards are identified and hazard analyses are conducted, results shall be
documented in hazard logs (including the effects of software) which are maintained
throughout the lifecycle of the system. The PO Safety Manager and AMCOM Safety
Office shall have access to, and review and concur with the contractor’s proposed
hazards, and hazard logs. Hazards, controls and verification of controls require AMCOM
Safety Office and program SSWG approval to be recommended for closure. Formal
hazard closure and residual risk acceptance is in accordance with the individual
program’s approved SSMP.
(1) System Safety Management Plan
The PO Safety Manager’s performance or management of the tasks in Table 1 provides
the basis for a tailored SSP, to include the SwSS program requirements. An SSMP will
be developed by the Government PO in accordance with AR 385-10. The SSMP
establishes Army management objectives and responsibilities for execution of a SSP for
the lifecycle of the system. The SSMP will be updated annually or per request of the
PM. The SSMP is the instrument used to:
1. Apply SS and SwSS requirements to a particular program
2. Designate the Government PO Safety Manager, who serves as the PM’s safety
expert.
3. Set forth a plan or action for the SSWG
4. Establish ground rules for Government and contractor interaction
5. Assign tasks, financial requirements, training requirements, schedules, data and
personnel.
6. Designate which safety analyses and trade studies are required and when they
should be performed.
7. Define the program’s formal hazard closure and residual risk acceptance
process.
Refer to AR 385-10 and DA PAM 385-16 for full detailed guidance on development of
the SSMP.
13
AMCOMR 385-17
(2) Statement of Work
The safety inputs to the SOW will clearly and concisely identify the contractor safety
requirements for the SSP. The SOW will contain sufficient information and detail to
provide respondents an opportunity to adequately scope the safety effort and the
Government PO Safety Manager a clear means for evaluation of responses. The safety
SOW will include specification and standards requirements, guidance documents, and
a contract deliverable requirements list (CDRL). The SOW requirements for the SSP
will include the requirement to develop a SwSS program that meets the requirements of
this regulation and the SSMP.
(3) Software System Safety Program Plan
The software developer shall document their approach to meeting the requirements of
this regulation. The software developer shall either document their SwSSPP as an
integrated part of the SSPP or as a standalone CDRL document. The SwSSPP shall
detail how the SwSS tasks will be accomplished within the specific SD life-cycle for the
project. The SwSSPP shall include a detailed safety schedule and identification of tasks
to be accomplished for each specific phase of the program SD lifecycle. Documents that
provide guidance on establishing SwSS plans and programs include JSSSH, IEEE Std
1228.1994, NAVSEA SW020-AH-SAF-010, and SED-SES-PMHSS 001
The SwSSPP shall apply to the contractor and all sub-contractors, including developers
of COTS, GFE, non-developmental software, and Re-use software. The SwSSPP shall
address how the SwSS requirements and activities are addressed in:
•
•
•
•
•
SD
Configuration Management (CM)
Software Quality Assurance (SQA)
Software Validation and Verification (V&V)
SS
(4) Specification Safety Requirements
During System Concept Refinement, preliminary specification safety requirements will
be developed to support overall program specification for hardware and software
development. Safety requirements can be derived from the safety assessment of
program documentation, as well as the safety requirements contained in MIL-STD-882,
AR 385-10, DA Pam 385-16, and past experience with similar developmental programs.
The contractor SSE organization shall ensure adequate SS requirements and/or
capabilities are incorporated into the contractor’s system specifications. SwSS and SSE
shall ensure that SwSS requirements are flowed down and traceable to the lower level
software requirements specifications (SRS) safety requirements, as they are developed.
SRS safety requirements may result from a direct flowdown of system requirements
and/or capabilities or may be derived from SS and SwSS analyses. Derived software
safety requirements shall be traceable to system level hazards and SCSFs.
14
AMCOMR 385-17
(5) Safety Integration into the Software Development Process
SwSS personnel should participate on all IPTs involved in the development of safetycritical software. SwSS should work in coordination with SQA, Test, and V&V groups on
all software issues that affect safety. This enhances the early detection and correction
of software safety issues with the least adverse impact to program development, cost,
and schedule.
Safety shall be part of the CM process. SwSS personnel shall review all software
change requests (CRs) and shall determine if there is a safety impact. CRs assessed to
affect safety shall be identified and tracked within a configuration controlled process.
Software CRs “tagged” safety shall require approval by SwSS prior to being closed.
SwSS personnel shall support SQA verifications of SD and safety processes, SQA
verification of safety requirements implemented by the SD process and SQA audits.
SwSS personnel shall be part of the V&V effort for safety-critical software and safety
requirements. SwSS personnel shall support development of Software Test Plans, Test
execution, review of Test Results, Test Incident Reports (TIRs), and regression testing.
SwSS personnel shall support detailed safety analyses performed as part of V&V.
SwSS personnel shall support the SS risk assessment process.
SwSS personnel, as part of the program SS effort, shall document software safety
efforts and provide software safety inputs to support SS requirements, working groups,
reviews, and documentation.
(6) Software System Safety Working Group
The software developer shall establish a Software System Safety Working Group
(SwSSWG), either as part of the SSWG or as a standalone chartered group. The
function of the SwSSWG shall be to assist the PM and project Safety Manager on
SwSS issues. The SwSSWG shall provide input and recommendations to the program
SSWG.
(7) Software Development Program Phase Safety Requirements
The software developer, in coordination with SwSS, shall develop safety entry/exit
criteria for each program phase of the SD (for example: concept refinement,
requirements and architecture development, detailed design, coding, and
implementation, V&V, software release). The safety entry/exit criteria shall be
documented in the appropriate sources. SwSS and SQA share responsibility for
verifying compliance with criteria. The software developer shall provide the necessary
evidence of compliance to SS, the SSWG, PO, AMCOM Safety, and SSSTRP for
acceptance and approval in support of program milestones.
Safety entry/exit evidence shall be provided to the PO and AMCOM Safety a minimum
of 30 days prior to milestone reviews or IAW the delivery dates on the Safety Program
Schedule.
15
AMCOMR 385-17
(8) Software Safety Analyses and Activities
The SOW, RFP, and SSMP will, and the SSPP and SwSSPP shall identify and
describe the SwSS analyses and activities, and compliance evidence necessary to
support software safety assurance. Required SwSS analyses and activities shall
include:
• Identification of System SCSFs
• Preliminary Hazard Analysis (PHA) of software contributions to identified system
hazards
• Software Safety Requirements Analysis
• Identification of software and hardware controls to mitigate software contributions to
system hazards
• Hazard Tracking of Software Contributions to System Hazards
• Assess safety-criticality of SCSFs and verification level of rigor
• CM of software safety requirements in the requirements database
• Support test plan development and V&V activities
• Detailed Software Design Analysis (Fault Tree Analysis (FTA), Failure Modes and
Effects Analysis (FMEA), Code/Logic Analysis, Traceability, etc.) to assess adequacy
of hazard controls
• End-to-end traceability of SwSS activities, from initial system assessment through
implementation and verification of SCSFs, software release, fielding and sustainment
• SwSS inputs to SSP analyses and deliverable items, such as: Subsystem and
System Hazard Analysis, Safety Assessment Report (SAR), Operating and Support
Hazard Analysis (O&SHA)
• Inputs to System Safety Risk Assessments (SSRAs) to support residual risk
acceptance and software release
Draft SwSS analyses shall be provided to the PO and AMCOM Safety 60 days prior to
milestone reviews, and final software safety analyses shall be provided NLT 30 days
prior to milestone reviews in order to give the PO and AMCOM Safety sufficient time to
review, comment and approve the analyses.
(9) Software System Safety Program Tailoring
General: The requirements of this regulation can be, and are encouraged to be, tailored
for each specific program, provided tailoring is coordinated and approved by the
respective Government Program Management Office and the AMCOM Safety Office
prior to implementing. Substitution of equivalent or more stringent industry standards for
the requirements given in this regulation is allowed, provided approval is received from
the Government Program Management Office and the AMCOM Safety Office.
Process: Tailoring should be performed as early in the program as possible, preferably
during the System Concept and Software Requirements and Architecture Development
phases. Software System Safety Tailoring will begin with the tailoring of the AMCOM
Software System Safety Regulation in the System Concept Refinement phase.
16
AMCOMR 385-17
(a) System Concept Refinement
The software developer’s processes will be reviewed and assessed by the Government
Program Management Office and the AMCOM Safety Office to determine compliance
with the AMCOM Software Safety Regulation. The results of the assessment will
provide the basis for tailoring of this policy. The Government Program Management
Office and the AMCOM Safety Office will collaborate on establishment of a tailored
software system safety policy, with the understanding that the tailored safety policy will
be the basis for the contractually binding safety requirements to be levied on the
software developer. The results of the tailoring discussions will be documented and
preserved for future reference. In addition, a tailored version of the AMCOM Software
System Safety Regulation for the program will be prepared and signed. Government
and software developer System Safety Engineering and Software System Safety
Engineering shall be implemented in accordance with the tailored AMCOM Software
System Safety Regulation. The following artifacts shall reflect agreements from the
tailoring discussions.
•
•
•
•
•
•
Prime Contract
Subcontracts
System Safety Management Plan
System Safety Program Plan
Software System Safety Program Plan
Software Development Plan
(b) Software Requirements and Architecture Development
The Government Safety Office and the software developer shall tailor the matrix of
safety requirements for development of safety-critical software based on STANAG 4404
and the JSSSH provided in Appendix A
• The set of tailored SD requirements, approved by AMCOM Safety (via the
SSSTRP), shall be formally documented and incorporated into appropriate
program documentation and maintained under CM control.
• The requirements tailoring effort shall be performed and completed prior to the
software System Requirements Review.
• The software developer shall maintain records of compliance with the tailored
safety requirements.
(c) Software Design, Coding, and Implementation
Software design, coding, and implementation shall be conducted in accordance with
the tailored AMCOM Software System Safety Regulation.
(d) Software Verification and Validation
The level of rigor required for safety verification is largely independent of SD technique.
Verification may be tailored to the SD process implemented, provided the required level
of rigor for software safety verification is performed. The software developer shall
17
AMCOMR 385-17
implement verification tailoring per Software Safety Requirements Verification
Guidelines, Appendix A.
(e) Software Release
The software developer shall support the software release process. The software
developer shall be prepared to justify the tailoring and shall ensure that the tailored
artifacts are readily available for examination. The software developer shall ensure that
software changes conform to the tailored policy.
(f) Software System Safety Activities after Software Release
The software developer shall support software system safety activities required after
software release. These activities support Materiel Release of software upgrades,
software releases and fixes to support updates of the fielded system, problem correction
in released software and software maintenance activities. The software developer shall
ensure that software maintenance activities required in fielded systems incorporate
safety controls and are properly documented in technical manuals.
(10)
Software System Safety Program Data, Record Retention and Archiving
The Government PM, software developer, and AMCOM Safety Office each have
responsibilities for software system safety program data and record retention and
archiving. Retention and archiving of software system safety data is vital not only to the
software system safety of the program under development, it is crucial to applying
lessons learned to other programs. The Government PM and the AMCOM Safety Office
must decide on the archive media for each artifact, document the decision, and inform
the software developer of the required archive media for each artifact. Safety data and
records should be retained for the entire life of the program as overall evidence of
program safety compliance. The Government PM and AMCOM Safety Office are
responsible for maintaining the ASTS, which will contain the hazard tracking data for
AMCOM managed programs. Data and documentation to be retained includes:
• Hazard Tracking Logs – The hazard tracking database and approved program
hazard tracking logs will be maintained by the AMCOM Safety Office. Exceptions
are existing AMCOM managed programs using hazard tracking databases
approved by the Government PM and maintained by the Government PO.
• Government Approved Hazard Analyses will be retained by the PO and AMCOM
Safety Office. The software developer shall retain Government approved hazard
analyses in their configuration managed system, along with the appropriate
Government review and approval correspondence.
• Safety Contract Data Requirements List (CDRL) Items will be retained by the PO
and AMCOM Safety Office. The software developer shall retain Government
approved safety CDRL items in their configuration managed system, along with
the appropriate Government review and approval correspondence.
• System Safety Risk Assessments (SSRAs) generated will be retained by the PO
and AMCOM Safety Office. SSRAs and their disposition shall be entered as part
of the applicable hazard log in the hazard tracking database.
18
AMCOMR 385-17
• Engineering Change Proposals (ECPs) that impact safety shall be tracked and
maintained in a configuration controlled data management system accessible to
the Government PO.
• Safety Checklists approved by the software developer software quality
assurance, software system safety and software IPT shall be retained as
evidence of compliance with required processes.
• Data relevant to Accident/Incident Reports and Corrective Actions shall be
retained by the software developer and the PO and AMCOM Safety Office will
retain Accident/Incident Reports and any corrective actions related to
accidents/incidents.
• Lessons learned that impact safety shall be documented and retained by the
software developer. The Government PO and AMCOM Safety Office will retain
documentation related to safety lessons learned.
• Tailoring/Exemptions/Waivers Justification shall be retained by the software
developer. The PO and AMCOM Safety will retain copies of tailored artifacts,
exemptions and waivers.
• Key Safety Decision Engineering Memorandums shall be retained by the
software developer.
• Software Test Plans, Test Reports, Problem Reports, Corrective Actions and
Verification of Corrective Actions related to software system safety requirements
shall be retained by the software developer.
b. Software System Safety during Software Requirements and Architecture
Development
SS and SwSS activities and artifacts during Software Requirements and Architecture
Development shall include the items identified in Table 2.
Table 2. SS and SwSS during Software Requirements
and Architecture Development
Activity
Primary
Responsibility
Supporting
Responsibility
Artifacts Produced
Identify and Track System Level
Hazards
SSE, SwSS
All
PHL/ PHA, hazard tracking logs
Identify SCSFs associated with
identified system hazards (includes
SCSF and SW controls)
SwSS, SSE
SD
SCSF list, SW hazard controls (which
are also SCSFs), inputs to system
hazard logs
Identify system level requirements
(HW & SW)
SSE, SwSS
SE, SD
Safety requirements in specifications
Identify SD safety requirements,
based upon SD process and
guidance documentation (JSSSH,
STANAG 4404)
SwSS
SD
SD safety requirements incorporated
into SD process documentation (eg.
SDP, SDD)
Support Configuration Control
process to ensure requirements
incorporation into specifications
SSE, SwSS
PM, SE, SD,
SSMP (Government), SSPP
(Contractor), SwSSPP (Contractor)
19
AMCOMR 385-17
(1) Identify and Track System Level Hazards
All system hazards shall be identified and documented using a systematic hazard
analysis approach. Hazard tracking is required by AR 385-10 and MIL-STD-882. The
web-based AMCOM Safety Tracking System (ASTS) shall be the hazard tracking
database used by all AMCOM managed programs. Access to the ASTS will be
provided by the AMCOM Safety Office ASTS Administrator. User account access can
be requested via the ASTS home page. The ASTS incorporates features that allow
software hazard criticality values to be input. All identified credible hazards for the
program will be entered and managed via ASTS.
(2) Identify Safety-Critical Software and SCSFs
SCSFs are those software functions that relate to safety critical software, as identified in
the system assessment and hazard analyses. The objectives of SwSS are identification,
control and verification of safety-critical software capabilities/functions. These activities
ensure that a failure of a SCSF does not result in the software contributing to a system
level hazard. Upon review of the system, its requirements and capabilities, and the
initial system level safety analyses, SwSS personnel shall identify the SCSFs. SCSFs
shall also include the software control functions identified for hazard control and
mitigation. The JSSSH Appendix E, repeated in Appendix C, provides guidelines for
identification of SCSFs.
A SCSF list, including both SCSFs and identified software hazard control functions,
shall be developed and maintained as part of the requirement to identify and trace
SCSFs from identification through software implementation. As software and system
development proceeds, detailed SS analyses shall be performed to include system and
subsystem hazard analysis, SAR, and FTA, as appropriate. These artifacts provide
analyses to support software safety assurance and SS evaluations.
SwSS personnel shall collaborate with systems engineers, software developers and
testers in development of software safety requirements that implement the applicable
software control functions specified in the SCSF list and addressed in the hazard logs.
SCSFs and safety-critical software requirements implementing hazard mitigation
controls shall be incorporated into the software requirements specifications and tracked
in a configuration controlled database. Safety-critical software requirements shall be
traceable from their parent SCSFs, to the hazard analyses, to the software
implementation, and subsequently to their verification. Full regression testing shall be
performed for any software modification affecting SCSFs.
(3) Identify System Level Hardware and Software Requirements
SSE and SwSS shall support the development of safety requirements for system
specifications for both hardware and software. SwSS shall identify software safety
requirements based upon identified SCSFs, failures and mitigation measures, as well as
review of similar systems software safety requirements and lessons learned. SwSS
shall support SSE and SE in ensuring that clear concise software safety requirements
are incorporated into specifications and formally tracked in the requirements tracking
database.
20
AMCOMR 385-17
(4) Software Safety Requirements for Software Development
A tailorable matrix of safety requirements for development of safety-critical software
based on STANAG 4404 and the JSSSH is provided in Appendix A. Each AMCOM SD
program shall assess compliance with the requirements of Appendix A. Tailoring,
deviations, and waivers associated with non-compliances shall be documented (i.e.
requirement not met, rationale for not meeting, alternatives/trade studies, mechanisms
to meet intent in alternative manner, etc.) and coordinated with the SSSTRP for
acceptance. The set of tailored SD requirements, approved by AMCOM Safety (via the
SSSTRP), shall be formally documented and incorporated into appropriate program
documentation and maintained under CM control. The requirements tailoring effort shall
be performed and completed prior to the software System Requirements Review. The
software developer shall maintain records of compliance with the tailored safety
requirements.
(5) Support Configuration Control and Requirements Management
SSE and SwSS shall support the configuration control and requirements management
process to ensure software safety requirements are incorporated into the specifications,
tracked in the requirements database and incorporated into verification plans.
c. Software System Safety during Software Design, Coding, and Implementation
SS and SwSS activities and artifacts during Software Design, Coding, and
Implementation shall include the items identified in Table 3.
Table 3. SS and SwSS during Software Design,
Coding, and Implementation
Activity
Primary
Responsibility
Supporting
Responsibility
Artifacts Produced
Perform Detailed SS and SwSS
Analyses
SSE, SwSS
All
Hazard Logs, SCSF lists, SRCA,
System Safety Hazard Analysis
(SSHA), Safety Hazard Assessment
(SHA), SW reqts. analysis, FTA, etc.
Refine SCSFs, HW and SW
detailed control measures to
mitigate hazards IAW emergent
system SW design and operation
SwSS, SSE
SD
SCSF list, SW hazard controls (which
are also SCSFs), inputs to system
hazard logs
Ensure and track integration of SW
safety reqts. (SW hazard controls)
into the SSE hazard analyses,
reqts. documentation and design
implementation
SSE, SwSS
SE, SD, CM, SQA
Safety requirements in specifications
Determine safety-criticality of
SCSFs and SW safety reqts.
SSE, SwSS
All
SHCI assigned to each SCSF and
SW safety reqt., SHCIs for reqts.
entered into verification plans and
reqts. tracking database
ID verification methods for reqts.,
Apply level of rigor to specify
verification reqts. for SW safety
reqts.
SwSS
SD, V&V
Verification Cross-Reference Matrix
(VCRMs) addressing SW safety
reqts., SW verification plans
assigning verification reqts. to each
SCSF and SW safety reqt.
21
AMCOMR 385-17
(1) Perform Detailed System Safety and Software System Safety Analyses
Detailed analysis activities performed during this SD phase shall include:
• Completion of PHA
• Updated Hazard Tracking Logs addressing SCSFs, (causes, controls, proposed
verification)
• SCSF lists to support traceability requirements
• Safety Requirements Criticality Analysis (SRCA) for both hardware and software
• Subsystem Hazard Analysis
• System Hazard Analysis
• Software Level of Rigor Analysis (See Section 6 and Appendix D)
• FTA (or equivalent detailed safety analyses) to determine adequacy and
independence of proposed hazard controls
• Assessments of compliance with SD safety requirements
• Artifacts necessary to provide evidence of End-to-end traceability of SwSS activities,
from initial system assessment through implementation and verification of SCSFs,
software release, fielding and sustainment.
• SwSS inputs to SSP analyses and deliverable items, such as: Subsystem and
System Hazard Analysis, Safety Assessment Report (SAR), Operating and Support
Hazard Analysis (O&SHA)
Guidance for performing detailed safety analyses can be found in the latest issues of
MIL-STD-882, Rev. C, the JSSSH, NAVSEA SW020-AH-SAF-010, and DO-178B.
(2) Refine SCSFs, Hardware and Software Control Measures to Mitigate Hazards
As the software design matures and coding is performed, additional levels of
detail/fidelity of SCSFs, software hazard causes and mitigation will require
development. During this phase, detailed software hazard controls shall be specified in
the form of software specification requirements and traced to their parent SCSFs,
hazard analyses, and code implementation.
(3) Ensure and Track Integration of Software Safety Requirements
SwSS shall support both hardware and software configuration control boards (CCB)
and IPTs to monitor integration of software safety requirements into the specifications
and design implementation. SwSS shall review all software CRs for safety impact and
provide feedback to the CCBs regarding safety-criticality, level of rigor, and/or potential
residual risk impacts.
(4) Determine Criticality of SCSFs
Based upon detailed SS and SwSS analyses (such as FTA), as well as the criteria
stated in the Software Hazard Criticality Matrix (SHCM), the criticality of SCSFs shall be
determined. The criticality of the SCSF determines the level of rigor required for
verification of the SCSF.
22
AMCOMR 385-17
(5) Identify Verification Methods and Apply Level of Rigor to Determine and
Specify Software Safety Verification Requirements
A number of factors influence the level of rigor requirements specified for SCSFs. Level
of rigor is based upon the criticality of the SCSF (also referred to as the software hazard
criticality index (SHCI)). As hazard severity and level of software autonomy of SCSFs
increases, the corresponding level of rigor for verification also increases. The level of
rigor for each SHCI value in the SHCM will be specified in the SSMP, shall be specified
the SSPP (or SwSSPP) and be reflected in requirements verification plans.
d. Software System Safety During Software Verification and Validation
SS and SwSS activities and artifacts during Software V&V shall include the items
identified in Table 4.
Table 4. SS and SwSS during Software V&V
Activity
Primary
Responsibility
Supporting
Responsibility
Artifacts Produced
Develop Formal Test and
Verification Plans
SD, V&V
SwSS, SSE
Test and Verification Plans
Provide recommendations for
safety specific tests and test inputs
SwSS, SSE,
SD, V&V
Test and Verification Plans for safety
specific tests, approved by SwSS and
SSE
Ensure SW safety reqts. are
verified IAW level of rigor and
procedures in approved plans
SwSS, SSE
V&V, SQA, SD
Test and Verification Plans for safety
reqts. reflecting level of rigor
implementation
Update safety traceability artifacts
to provide evidence of end-to-end
traceability of SW safety
SwSS
SD, V&V
Hazard logs, FTA, SCSF lists, SD
peer reviews/minutes, checklists
Monitor execution of verification
activities
SSE, SwSS, SQA
V&V, SD
Signed test procedures, pre-test
meetings, SQA stamped procedures
Analyze verification results for
safety compliance
SSE, SwSS, SQA
All
Documented assessment findings,
safety approval of verifications, SQA
sign-off of test results, peer review
minutes
Track safety verification failures,
resolution/corrective actions,
implementation and regression
testing
V&V, SwSS, SQA, CM,
SD
SSE, SE
CM, SQA documentation, SW/test
problem/incident reports, CRs,
regression test plans, tests, and
reports
Update Safety Artifacts
SSE, SwSS
Hazard Logs, SAR
(1) Develop Formal Test and Verification Plans
Formal test and verification plans are developed by either the SD or test/verification
organizations, or a combination of both. SwSS shall support formal test plan
development by making recommendations on test cases that include safety
verifications. SwSS shall ensure any code or other software analyses, as defined by
SHCI and level of rigor, is performed. SwSS shall assess all test plans that include
SCSFs and their verification to ensure:
• Test plans include verification of SCSFs
• Test plans include the appropriate level of rigor cases for each SCSF (failure testing,
off-nominal, Go-No-Go testing, black box testing, etc.)
• Test case inputs provide adequate coverage
23
AMCOMR 385-17
• Test outputs provide adequate data for assessment and verification
(2) Provide Recommendations for Safety Specific Tests
SwSS shall provide inputs and recommendations for any safety specific tests that may
be required as part of software verification activities.
(3) Ensure Safety Requirements are Verified in Accordance with Level of Rigor
and Approved Test Procedures
SwSS shall monitor safety verification activities to ensure that all safety requirements
are verified IAW their specified level of rigor and approved test procedures. SwSS shall
collaborate with SQA to ensure test procedures are properly conducted and any
redlines to procedures that impact safety verifications are reviewed by SwSS.
(4) Update Safety Traceability Artifacts
SwSS shall provide evidence of traceability of SCSFs. Traceability shall encompass
the end-to-end flow of SCSFs, from initial identification to hazard analyses, to
specification as requirements, to code implementation and final verification. As SCSFs
are V&V’d, the safety artifacts that serve as evidence of traceability shall be updated.
(5) Monitor Execution of Verification Activities
SwSS shall be invited to observe and monitor the verification of any SCSFs. SwSS
shall coordinate with SQA and the V&V organizations to obtain verification results for
assessment. The PO Safety Manger and/or AMCOM Safety Office shall be invited to
witness verification of SCSFs.
(6) Analyze Verification Results
SwSS shall analyze and assess verification results for SCSFs. SwSS shall provide
feedback to the V&V organization for safety issues identified.
(7) Track Verification Failures, Corrective Actions, Implementation and Regression
Testing
As an artifact of SwSS’s assessment of verification results, SwSS shall track
verification failures, proposed corrective actions (or the risk associated with no
corrective action), the implementation of the corrective actions, and the required
regression testing of any software changes that impact safety. SwSS shall review
software CRs associated with safety verification and approve corrective actions. SwSS
shall support corrective action and CCBs that address verification failures.
(8) Update Safety Artifacts
Upon completion of safety verification activities, SSE and SwSS shall update the safety
analyses and hazard tracking logs, and ensure CM updates requirements databases to
incorporate verifications and evidence.
24
AMCOMR 385-17
e. Software System Safety to Support Software Release
SS and SwSS activities and artifacts in support of Software Release shall include the
items identified in Table 5.
Table 5. SS and SwSS to Support Software Release
Activity
Primary
Responsibility
Supporting
Responsibility
Artifacts Produced
Review hazards, controls,
implementation and verifications to
determine adequacy of hazard
mitigations and verifications
SSE, SwSS
All
Final hazard logs, closed or
conditionally closed. Residual risks
identified and documented
Identify recommendations for
additional conditions, limitations,
and procedural controls
U, SSE, SwSS
SE, SD
Updates for Safety Release, TMs,
operating procedures, etc.
Perform final system hazard risk
assessment and process through
management approval process
SwSS, SSE, PM
SE, SD
SSRAs, accepted residual risks by
appropriate management authority
(1) Review Hazard Data
SwSS shall support SSE review of hazard analyses and tracking data. Hazards,
controls, and verifications shall be reviewed to assure adequacy of hazard mitigations.
SwSS shall support SSE’s recommendations for closure of hazard logs and/or residual
risk assessment and acceptance processing. Hazard log closure recommendations and
residual risk assessments shall be presented to the SSWG for closure or further
acceptance processing. Final hazard risk and residual risk acceptance processing will
be approved by the AMCOM LCMC PM and AMCOM Safety Office.
(2) Identify Additional Safety Recommendations to Support Software Release
In the event that not all of the SCSFs are adequately verified, but the system and
software will be tested or fielded (based on critical need, etc.), SwSS and SSE shall
support the AMCOM LCMC PM and AMCOM Safety office in identifying potential usage
limitations/restrictions, procedural controls and/or work-arounds that may be
implemented to support hazard risk mitigation/ reduction and safety release. These
restrictions, procedures, and work-arounds are reflected in technical memos (TMs),
operating procedures, warnings/cautions/alerts, and Safety-of-Use type messages and
must be approved by the SSWG and AMCOM Safety Office. Personnel shall be
adequately trained to implement these deviations from the planned system and
operation. These safety recommendations shall only cover the system and software
until permanent software fixes/verifications are implemented at the earliest opportunity.
SS and SwSS activities do not end with software release. The requirements of this
regulation will (Government)/ shall (software developer) apply throughout each
software development cycle within the entire system acquisition life-cycle. Safety issues
discovered after software release will be addressed in accordance with the Army’s and
program’s Materiel Release (AR 700-142) and SS risk after fielding processes. The
AMCOM SSSTRP will continue to function as the vehicle for evaluating safety-critical
software and providing endorsements to the Materiel Release Review Board. Software
25
AMCOMR 385-17
developers responsible for software post-software release shall ensure compliance with
the applicable requirements of this regulation.
(3) Support Final System Safety Risk Assessment
SSE shall perform a final risk assessment for all hazards and shall present it to the
SSWG and AMCOM Safety for approval. SwSS shall support SSRAs for residual risks,
as impacted by software, and the processing of SSRAs through the management
approval process prescribed in the SSMP. Contractors do not have authority to accept
residual risks.
5.
HAZARD ASSESSMENT APPROACH
As stated previously, software, as a standalone entity, is not hazardous. Software
failures, however, may contribute to hazards, including catastrophic hazards, of
supported systems with which it interfaces.
Software does not fail due to excessive wear or other traditional hardware failure
modes. Generic software contributors (causes) to a hazard include:
•
•
•
•
•
•
•
Not performing a required function
Performing a function not required
Performing a function out of sequence
Failure to recognize existing hazardous conditions
Inadequate response to contingencies
Wrong decision on problem solution
Poor timing – operation/command performed too soon or too late (latency, priority)
Software contributions to hazards may arise through defects, errors, or omissions,
leading to a failure of the system to operate correctly. Improper identification,
specification, and verification of software safety requirements are major contributors to
system hazards caused by software.
a. Software Safety Analysis
The responsibility for assuring that software is adequately analyzed and tested is
shared between the SD team (Software Systems Engineering, Development and Test)
and SwSS. Each is responsible for meeting the software safety analyses and
verification requirements for the SD.
The objective of SwSS is to ensure that the software will be analyzed, designed, and
tested to verify that software contributions to system level hazards are identified and
either eliminated or controlled sufficiently. Success of the SwSS effort will form the basis
for closure of software causes (or separately identified software hazard contributor
(hazards)) within hazard tracking logs which support system level hazard mitigation
efforts.
A failure attributed to software is caused by the presence of a software fault such as a
missing, extra, or defective instruction or set of instructions. When, or if, a particular
26
AMCOMR 385-17
fault is encountered, a failure due to software may or may not ensue; it depends on the
machine state, i.e., values of program variables and registers.
Other ways faults can enter the software are:
• Through design inadequacy (inadequate definition of requirements, the design does
not conform to all the requirements or does something extra that is not required)
• Interface mismatches (inadequate definition of interface requirements, overlooking
interactions among various parts of the system)
• Programmer error (improper, vague or ambiguous definition of requirements, the
programmer misunderstands some aspect of the programming language)
The system prime contractor and software developer are required to demonstrate that
its software is safe. Verification of Safety-critical software can be combinations of
analysis, demonstration, inspection and testing, with emphasis on testing. Softwareinduced hazards shall be eliminated or controlled in accordance with the SS order of
precedence: 1) Design changes, 2) Incorporate Safety Devices, 3) Alerts and Warning
Devices, 4) Operating Limits, Training and Procedures, and workarounds at either the
component/subsystem level or at the system level. Once a hazard is identified, its status
shall be maintained in the safety documentation as a permanent record. For those
hazards that are eliminated, particularly those eliminated as a result of a design change,
the method by which the hazard was eliminated shall be noted in the permanent record
in order to maintain visibility of the hazard.
SwSS is responsible for the identification of SCSFs, along with any code and events
associated with those system functions, to identify software functionality, which may
contribute to the manifestation of a hazardous state, or software functionality that
reduces the probability or severity of a potentially hazardous outcome.
SwSS personnel are responsible for ensuring that the activities and artifacts defined in
Section 4 of this regulation are performed and that the requirements defined in Section
4 are met.
6.
SOFTWARE SAFETY VERIFICATION
a. Software Hazard Control Categories
The assessment of risk for software-controlled or software-intensive systems cannot
rely solely on the hazard severity and probability that is used to describe hardware
hazards. Determination of the probability of failure of a single software function is
difficult at best and cannot be based on historical data. Software is generally application
specific and reliability parameters associated with it cannot be estimated in the same
manner as hardware is. Therefore, another approach is recommended for the initial
software risk assessment that considers the potential hazard severity and the degree of
control that software exercises over the hardware. The degree of control is defined
using the software control categories in the JSSSH (Tailored), and listed in Table 6.
27
AMCOMR 385-17
Table 6. Software Control Categories
Category
Category Description
AT (I)
Autonomous –
Time Critical
SW that exercises control over potentially hazardous subsystems or components
without the possibility of real time human intervention to preclude occurrence of the
hazard. SW failure directly contributes to the potential occurrence of the hazard.
AN (IIa)
Autonomous –
Not Time Critical
SW that exercises control over potentially hazardous subsystems or components, but
that allows sufficient time for human or independent safety intervention to prevent
hazard occurrence. The human or independent safety intervention is not sufficient for
safety. Corrective action(s) may be required.
IT (IIb)
Information –
Time Critical
SW that provides information display requiring an Operator(s) to take an immediate
action to prevent hazard occurrence. IT SW failure may contribute to, or fail to
prevent, a hazard.
OC (IIIa)
Operator Controlled
SW that requires human action to complete a function that commands potentially
hazardous subsystems or components.
SR (IIIb)
Information -Safety Critical
SW generates information of a safety critical nature used to make safety critical
decisions. There are several, redundant, independent safety measures for each
hazardous event.
NSC (IV)
Not Safety Critical
No safety function is controlled by the SW. Used to bound and provide rationale for
safety analyses.
A SHCM assists the program in allocating resources for the software safety verification
effort. The SHCM is established using the Hazard Categories for the columns and the
Software Control Categories for the rows. The SHCM is completed by assigning SHCI
values to each element just as Hazard Risk Index (HRI) numbers are assigned in the
hardware Hazard Risk Assessment Matrix. Unlike the hardware related HRI, a low index
number does not mean that a design is unacceptable. Rather, it indicates that greater
resources (higher level of rigor) are needed for the analysis and testing of the software
to satisfy safety verification requirements.
The SHCM shown in Table 7 is the example criteria presented in the JSSSC Handbook
to evaluate software criticality and allocate software safety verification resources. Table
7 also follows the guidance provided in MIL-STD-882C.
Table 7. Software Hazard Criticality (SHCM)
Software Control
Category
Hazard Category
Catastrophic
Critical
Marginal
Negligible
I
High
High
Moderate
Low
IIa-IIb
High
Medium
Moderate
Low
IIIa-IIIb
Medium
Moderate
Low
Low
IV
Low
Low
Low
Low
Level of Rigor
High
Medium
Moderate
Low
Acceptability Criteria – See Appendix D for further guidance
Requires significant analysis and testing resources
Requires requirements/design analyses and in-depth testing
High level analysis and testing acceptable with customer approval
Acceptable without review
The key, as discussed in the following sections, is delineation and implementation of the
verification levels specified in Table 7.
28
AMCOMR 385-17
b. Software Safety Verification Requirements
This section describes a minimum set of SwSS verification requirements. The software
developer is encouraged to exceed this minimum standard, as appropriate. New
software applications or development practices will likely require a higher level of
verification evidence for SCSFs than traditional or established software/development
practices. Additional verification requirements may be identified once the prime
contractor SD process is known. These requirements, combined with the rest of the
safety analysis evidence should satisfy expectations for verification of software safety
requirements as defined by the approved SHCM and verification Levels of Rigor.
Verification of Software safety requirements may be at any level of the SD, as
appropriate. The typical SD is broken down into software requirements and architecture,
unit code, integration (includes unit integration into component level software and
component software integration into system level software), and system level. It is not
the intent of this regulation to specify a particular SD technique. The level of rigor
required for safety verification is largely independent of SD technique. Verification may
be tailored to the SD process implemented, provided the required level of rigor for
software safety verification is performed.
Once a requirement is successfully verified, verification evidence is collected and the
requirements tracking and hazard logs are updated to reflect the verification(s). Formal
verification of safety requirements may not occur until software is “frozen” for formal
testing and delivery. However, it may be feasible to verify, via unit testing, wholly
implemented safety requirements. Evidence must be maintained to ensure that these
requirements and verification evidence have not been affected by subsequent
development and model update. In that case, regression testing is required to re-verify
the requirements.
The following software formal test coverage requirements are based upon software
safety requirements in STANAG 4404, the JSSSH, and other established references.
• Software testing shall be controlled by a formal test coverage analysis and
procedure.
• Computer based tools shall be used to ensure coverage is as complete as possible.
Software Safety testing shall include, at a minimum, the following:
A. GO-NO-GO path testing.
B. Hardware and software input failure mode testing.
C. Boundary, out-of-bounds, and boundary crossing test conditions.
D. Minimum and maximum input data rates in worst-case configurations to
determine the system’s capabilities and responses to these conditions.
E. Input values of zero, zero crossing, and approaching zero from either direction or
similar values for trigonometric functions.
F. Complete regression testing for safety critical computing system functions in
which changes have been made.
29
AMCOMR 385-17
G. Operator interface testing with the introduction of operator errors during safety
critical operations to verify safe system response to these errors.
H. Duration stress testing. The stress test time shall be continued for at least the
maximum expected operating time for the system. Testing shall be conducted
under simulated operational environments. Additional stress duration testing
should be conducted to identify potential critical functions (e.g., timing, data
senescence, resource exhaustion) that are adversely affected as a result of
operational duration. Software testing shall include throughput stress testing
(e.g., CPU, data bus, memory, input/output) under peak loading conditions.
In addition to the test requirements listed above, the following verification activities
should be performed:
A. Every predicate term tested. Verification that every statement in the safety-critical
software code has a defined behavior for equivalent classes of inputs.
B. Code interface analysis. Evaluation of internal and external interfaces of safetycritical units to ensure compatibility across the interface.
C. Every assignment to memory tested. Testing to ensure that data items are
protected from being overwritten by unauthorized operations. Can also be shown
by analysis of the design.
D. Every reference to memory tested. Analysis to ensure that all calls for data from
memory lead to the correct storage location of the variable.
E. Every statement executed once.
F. All modules executed at least once.
c. Software Independent Verification and Validation
As defined in the JSSSH, IV&V is the systematic evaluation of software products and
activities by an agency that is not responsible for developing the product or performing
the activity being evaluated. The Government PO is responsible for selecting and
funding the software IV&V agency and effort. A comprehensive software IV&V effort will
incorporate an evaluation of PO and contractor SwSS programs, tasks, implementation,
adequacy of SwSS requirements, verification of SwSS requirements, assessment of
verification evidence and ensuring regression testing is performed, as required.
It is critical that the IV&V agency have access to all of the software and safety artifacts
required to perform an adequate independent evaluation, to include access to the
source code for safety-critical software. If source code is not made available to IV&V,
then IV&V may identify and recommend additional safety verification activities to levy on
the software to verify that safety requirements are met. Appendix B provides guidelines
for Re-use, COTS, GFE, and NDI software. Safety tasks for IV&V evolve from the
flowdown of requirements for SS, SwSS, and verification from the specification
documentation and safety analyses. The IV&V findings should then be flowed back up
into the program SwSS effort and addressed, as necessary.
30
AMCOMR 385-17
7.
AMCOM SOFTWARE SYSTEM SAFETY TECHNICAL REVIEW PANEL
As stated in Section 3.2, software comprises a major subsystem of many AMC systems,
including autonomous systems, such as unmanned air and ground vehicles.
Increasingly, software is being procured, re-used, or designed and developed to control
hardware that performs safety-critical functions. This includes the emerging integration
of multiple safety-critical software systems in an over-arching command and control
structure. Net-centric operations, joint Service operations, embedded training, “SimOver-Live”, and concurrent training and operations add further safety complexity.
Additionally, there is a lack of consistency in the SwSS of these disparate systems. A
critical need exists for a formal SwSS review board to address the safety-critical
software issues.
The recently released AR 385-10 establishes the requirement for a Weapons System
Safety Review Board (WSSRB). Similarly to the Navy’s WSESRB, SSSTRP, an Army
SwSS review panel would convene to review SwSS on all programs coming before the
Army WSSRB. The AMCOM SSSTRP charter is given in Appendix F. The SSSTRP will
serve as AMCOM’s authority for the assessment of SwSS programs. The primary
mission for the SSSTRP is to ensure that high quality, consistent SD and verification
practices are applied to safety-critical software applications for AMCOM managed
systems. The SSSTRP supports both the AMCOM Safety Office and individual program
SwSS personnel in achieving its mission. Each AMCOM program that has safety-critical
software will be expected to present their SwSS program, and its progress, to the
SSSTRP for assessment, guidance, and endorsement. The number of SSSTRP
meetings and frequency should be tied to the program’s overall schedule and
milestones. SSSTRP endorsement will be critical to each program’s milestone safety
entry/exit criteria and Materiel Release process. The AMCOM SSSTRP will support the
AMCOM Safety Office SwSS PM’s development of Materiel Release Software Safety
Statements and software inputs to Safety and Health Data Sheets.
8.
SUMMARY
Software comprises a major safety-critical subsystem in modern Army programs.
Increasingly software is being advocated as a mechanism to control safety-critical
hardware and mitigate hazards. This places increased emphasis upon software
developers to provide adequate assurance that their software is safe for its intended
application. This regulation details guidelines for identification, implementation and
execution of a SwSS program that will meet AMCOM’s expectations for SwSS.
Appendix E provides general SS and software safety questions and data requests that
may be used to evaluate SwSS programs.
31
AMCOMR 385-17
Appendix A
Aviation and Missile Command (AMCOM) Safety Office
Integrated Air and Missile Defense (IAMD)
Tailored Software Safety Requirements Matrix Checklists (Draft)
32
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Configuration Control and Management
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
1
Has configuration control been established in the system development
process and maintained throughout the lifecycle of the software/system?
2
Are computer program changes occurring after an initial baseline has been
established approved by the Computer Program Configuration Control Board
prior to their implementation?
3
Is a member of the Board tasked with the responsibility for evaluation of all
software changes for their potential safety impact?
This member should be a member of the system safety engineering team.
4
Is a member of the hardware Configuration Control Board and a member of
the Software Configuration Control Board and vice versa to keep members
apprised of hardware changes and to ensure that software changes do not
conflict with or introduce potential safety hazards due to hardware
incompatibilities? This member should be a member of the system safety
engineering team.
5
Does configuration control include NDIs?
6
For Commercially Developed Items, does the system developer require
commercial vendors to alert the developer to changes in the procured item?
7
Has documentation for the computing system been developed to facilitate
maintenance of the software?
8
Is strict configuration control of the software during development and after
deployment required?
9
Critical function changes. Are changes to safety critical computing system
functions on deployed or fielded systems issued as a complete package for
the modified unit or module and patched?
33
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
10
Software change medium. When not implemented at the depot level or in
manufacturer’s facilities under appropriate quality control, are software
changes issued as a fully functional copy on the appropriate medium?
11
Modification configuration control. Are all modifications and updates subject
to strict configuration control?
The use of automated configuration management tools is encouraged.
12
Version identification. Is modified software or firmware clearly identified with
the version of the modification, including configuration control information?
Both physical (e.g., external label) and electronic (i.e., internal digital
identification) "fingerprinting" of the version shall be used.
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
34
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
1
Are patches to safety critical software prohibited throughout the development
process?
2
Are software changes coded in the source language and compiled prior to
entry into operational or test equipment?
3
Is the software analyzed throughout the design, development, and
maintenance process by system safety engineering to verify and validate
that the safety design requirements have been correctly and completely
implemented?
4
Are test results analyzed to identify potential safety anomalies that may
occur?
5
Does the system design isolate to the extent practical safety critical
functionality from NDIs unless the NDI can be analyzed and tested in
accordance with the guidelines of STANAG 4452? Isolation may include the
use of an operating system or environment to isolate computer programs
from a commercially produced microprocessor, the use of middleware to
isolate safety critical functionality from commercially developed operating
systems, and the use of high-integrity data transfer mechanisms to isolate
safety critical data from corruption by non-developmental communications
interfaces, such as Ethernet or Asynchronous Transfer Mode (ATM)
networks.
6
Does the system shall have at least one safe state identified for each logistic
and operational phase?
7
Are safety critical functions performed on a standalone computer? If not, are
safety critical functions isolated to the maximum extent practical from non-
35
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
critical functions?
8
Are the system and its software designed for ease of maintenance by future
personnel not associated with the original design team?
9
Has documentation specified for the computing system been developed to
facilitate maintenance of the software?
10
Are techniques for the decomposition of the software system for ease of
maintenance implemented?
11
Does the software return hardware subsystems under the control of software
to a designed safe state when unsafe conditions are detected?
12
Are conditions that can be safely overridden by the battle short identified and
analyses performed to verify their safe incorporation?
13
Are safety interlocks restored upon completion of tests and/or training
wherein safety interlocks are removed, disabled or by-passed? Is restoration
of those interlocks verified by the software prior to being able to resume
normal operation?
14
While safety interlocks are overridden, is a display made on the operator's or
test conductor's console of the status of the interlocks, if applicable?
15
If input/output registers and ports are used for both safety critical and noncritical functions, are the same safety design criteria applied to the noncritical functions?
16
Is the software designed to detect failures in external hardware input or
output hardware devices and revert to a safe state upon their occurrence?
17
Does the software design consider potential failure modes of the hardware
involved?
18
Is the system designed such that a failure of the safety kernel (when
implemented) will be detected and the system returned to a designed safe
state?
19
Does the system design preclude circumvention of detected unsafe
conditions, unless authorized?
20
If a "battleshort" or "safety arc" condition is required in the system, is it
designed such that it cannot be activated either inadvertently or without
authorization?
21
Is the system designed to include fallback and recovery to a designed safe
state of reduced system functional capability in the event of a failure of
system components?
22
If simulated items, simulators, and test sets are required, is the system
designed such that the identification of the devices is fail safe and that
operational hardware cannot be inadvertently identified as a simulated item,
simulator or test set?
23
Does the software make provisions for logging all system errors detected?
24
Do operators have the capability to review logged system errors?
25
Are errors in safety critical routines highlighted and shall be brought to the
36
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
operator's attention as soon as practical after their occurrence?
26
Do software controlled critical functions have feedback mechanisms that
give positive indications of the function's occurrence?
27
Is the system and software designed to ensure that design safety
requirements are not violated under peak load conditions?
28
If the system design employs middleware to isolate safety critical
functionality from Commercially Developed Item Operating Systems or
Environments or other NDIs, does the design of the middleware comply with
applicable guidelines of Appendix A?
29
Does system verification and validation include verification of the
effectiveness of the middleware in isolating the safety critical functionality
from the operating system or environment and other non-developmental
computer programs?
Power-up-System Initialization
30
Does the system and software design permit the system to power-up in a
safe state?
31
Is an initialization test incorporated in the design that verifies that the system
is in a safe state and that safety critical circuits and components are tested
to ensure their safe operation?
32
Does the initialization test also verify memory integrity and program load?
33
Is the system and computing system designed to ensure that the system is
in a safe state during power-up, intermittent faults or fluctuations in the
power that could adversely affect the system, or in the event of power loss?
34
Does the system and/or software design provide for a safe, orderly
shutdown of the system due to either a fault or power-down, such that
potentially un-safe states are not created?
35
Is the system designed such that a failure of the primary control computer
will be detected and the system returned to a safe state?
36
Are maintenance interlocks, safety interlocks, safing handles, and/or safing
pins provided to preclude hazards to personnel maintaining the computing
system and its associated equipment?
37
Where interlocks, etc. must be overridden to perform tests or maintenance,
are they designed such that they cannot be inadvertently overridden, or left
in the overridden state once the system is restored to operational use?
38
Is the override of any safety interlock(s) controlled by a computing system?
39
Is the software designed to perform a system level check at powerup to
verify that the system is safe and functioning properly prior to application of
power to safety critical functions including hardware controlled by the
software.
40
Are periodic tests performed by the software to monitor the safe state of the
system?
41
Do the software/ computer programs validate the contents of all Read-Only
37
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Memories upon power-up and verify the correct downloading of Read-Only
Memory contents into executable memory?
Self-Checking Design Requirements
42
Are watchdog timers or similar devices provided to ensure that the
microprocessor or computer is operating properly?
43
Is the timer reset designed such that the software cannot enter an inner loop
and reset the timer as part of that loop sequence?
44
Does the design of the timer ensure that failure of the primary CPU clock
cannot compromise its function?
45
Is the timer reset designed such that the system is returned to a known safe
state and the operator alerted (as applicable)?
46
Are periodic checks of memory, instruction, and data buss(es) performed?
47
Does the design of the test sequence ensure that single point or likely
multiple failures are detected?
48
Are checksum of data transfers and Program Load Verification (PLV) checks
performed at load time and periodically thereafter to ensure the integrity of
safety critical code?
49
Have fault detection and isolation programs been written for safety critical
subsystems of the computing system?
50
Is the fault detection program designed to detect potential safety critical
failures prior to execution of the related safety critical function?
51
Are fault isolation programs designed to isolate the fault to the lowest level
practical and provide this information to the operator or maintainer?
52
Are operational checks of testable safety critical system elements made
immediately prior to performance of a related safety critical operation?
Safety-critical Computing System Function Protection
53
Is the system designed such that automata and software prevent
degradation of safety by other interfacing automata and software?
54
Is the software designed to prevent unauthorized system or subsystem
interaction from initiating or sustaining a safety critical function sequence?
55
Does the system design prevent unauthorized or inadvertent access to or
modification of the software (source or assembly) and object code? This
includes preventing self-modification of the code.
56
If incorporated, are safety kernels resident in non-volatile read only memory
(ROM) or in protected memory that cannot be overwritten by the computing
system?
57
Is the safety kernel, if implemented, designed and implemented in such a
manner that it cannot be corrupted, misdirected, delayed or inhibited by any
other program in the system?
58
Does the system detect inadvertent jumps within or into Safety Critical
Computing System Functions, return the system to a safe state, and, if
38
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
practical, perform diagnostics and fault isolation to determine the cause of
the inadvertent jump?
59
Does the executive program or operating system ensure the integrity of data
or programs loaded into memory prior to their execution?
60
Does the executive program or operating system ensure the integrity of the
data and programs during operational reconfiguration?
61
Does the design of the middleware shall comply with applicable guidelines of
this requirements matrix?
62
Does system verification and validation include verification of the
effectiveness of the middleware in isolating the safety critical functionality
from the operating system or environment and other non-developmental
computer programs?
39
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Timing and Interrupt Functions
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Critical Timing and Interrupt Functions
1
Are safety critical timing functions controlled by the computer and not rely on
human input?
2
Are safety critical timing values not modifiable by the operator from system
consoles, unless specifically required by the system design? In these
instances, the computer shall determine the reasonableness of timing
values.
3
Is the software capable of discriminating between valid and in-valid (e.g.
spurious) external and/or internal interrupts?
4
Are invalid interrupts prevented from creating hazardous conditions?
5
Are valid external and internal interrupts defined in system specifications?
Internal software interrupts are not a preferred design as they reduce the
analyzability of the system.
6
Do recursive and iterative loops have a maximum documented execution
time?
7
Are reasonableness checks performed to prevent loops from exceeding the
maximum execution time?
8
Are the results of a program not dependent on the time taken to execute the
program or the time at which execution is initiated? Safety critical routines in
real-time programs shall ensure that the data used is still valid (e.g., by using
senescence checks).
40
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Design and Coding
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Software Design and Coding
1
Is software design and code modular?
2
Do modules have only one entry and one exit point?
3
Is the number of program modules containing safety critical functions
minimized where possible within the constraints of operational effectiveness,
computer resources and good software design practices?
4
Do Safety Critical Computing System Functions have one and only one
possible path leading to their execution?
5
Does the design preclude the use of halt, stop or wait instructions in code for
safety critical functions? Wait instructions may be used where necessary to
synchronize Input/ Output, etc. and when appropriate handshake signals are
not available.
6
Are files used to store safety critical data unique and shall have a single
purpose?
7
Does the design preclude scratch files, those used for temporary storage of
data during or between processes, for storing or transferring safety critical
information, data, or control functions?
8
Does the operational and support software contain only those features and
capabilities required by the system? The programs shall not contain
undocumented or unnecessary features.
9
Are indirect addressing methods used only in well-controlled applications?
10
When indirect addressing methods are used, is the address verified as being
within acceptable limits prior to execution of safety critical operations?
41
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
11
Does data written to arrays in safety critical applications have the address
boundary checked by the compiled code?
12
If interrupts are used, do sections of the code, which have been defined as
uninterruptible, have defined execution times monitored by an external
timer?
13
Are files used to store or transfer safety critical information initialized to a
known state before and after use?
14
Are data transfers and data stores audited where practical to allow
traceability of system functioning?
15
Is all processor memory not used for or by the operational program initialized
to a pattern that will cause the system to revert to a safe state if executed?
16
Is the unused memory not filled with random numbers, halt, stop, wait or nooperation instructions?
17
Are data or code from previous overlays or loads removed? (Examples: If
the processor architecture halts upon receipt of non-executable code, a
watchdog timer shall be provided with an interrupt routine to revert the
system to a safe state. If the processor flags non-executable code as an
error, an error handling routine shall be developed to revert the system to a
safe state and terminate processing.) (Note: safety-critical code should not
use overlays)
18
Is information provided to the operator to alert him to the failure or fault
observed and to inform him of the resultant safe state to which the system
was reverted?
19
Do overlays of safety critical software all occupy the same amount of
memory? (Note: safety-critical code should not use overlays)
20
Where less memory is required for a particular function, is the remainder
filled with a pattern that will cause the system to revert to a safe state if
executed?
It shall not be filled with random numbers, halt, stop, no-op or wait
instructions or data or code from previous overlays.
21
If an operating system function is provided to accomplish a specific task, do
operational programs use that function and not bypass it or implement it in
another fashion?
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Software Coding
22
Is the implementation of software compilers validated to ensure that the
compiled code is fully compatible with the target computing system and
application (may be done once for a target computing system)?
23
Are flags and variable names unique? Flags and variables shall have a
single purpose and shall be defined and initialized prior to use.
24
Do loops have one and only one entry point?
25
Does the software code preclude branches into loops? Branches out of
loops shall lead to a single exit point placed after the loop within the same
module.
42
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
#
Item
26
Is the software annotated, designed, and documented for ease of analysis,
maintenance, and testing of future changes to the software?
27
Are variables or constants used by a safety critical function
declared/initialized at the lowest possible level?
28
Do operational program loads not contain unused executable code? If so,
how are safety-critical functions isolated from unused executable code?
29
Do operational program loads not contain unreferenced or unused variables
or constants?
30
Are Safety Critical Computing System Functions and other safety critical
software items not be used in one-to-one assignment statements unless the
other variable is also designated as safety critical (e.g., shall not be
redefined as another non-safety critical variable)?
31
Do conditional statements have all possible conditions satisfied and under
full software control (i.e. there shall be no potential unresolved input to the
conditional statement)?
32
Are conditional statements analyzed to ensure that the conditions are
reasonable for the task and that all potential conditions are satisfied and not
left to a default condition?
33
Are all condition statements annotated with their purpose and expected
outcome for given conditions?
34
Do safety critical functions exhibit strong data typing? Safety critical
functions shall not employ a logic "1" and "0" to denote the safe and armed
(potentially hazardous) states.
35
Are the armed and safe states for munitions represented by at least a unique
four bit pattern?
36
Is the safe state represented by a pattern that cannot, as a result of a one,
two, or three bit error, represent the armed pattern?
37
Is the armed pattern not the inverse of the safe pattern?
38
If a pattern other than these two unique codes is detected, does the software
flag the error, revert to a safe state and notify the operator, if appropriate?
39
Are values for timers annotated in the code?
40
Do comments include a description of the timer function, its value and the
rationale or a reference to the documentation explaining the rationale for the
timer value?
41
Are these timer values shall be verified and shall be examined for
reasonableness for the intended function?
42
Are safety critical variables identified in such a manner that they can be
readily distinguished from non-safety critical variables (e.g., all safety critical
variables begin with a letter S)?
43
Are global variables not used for safety critical functions?
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
43
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Interfaces Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Interface Design
1
Does the design specification identify the interface type (Ethernet, ATM,
etc.), the data transfer mode (serial, parallel, packet, etc.), message format,
message types, contents, and any other unique aspects of the interface?
2
Are feedback loops from the system hardware designed such that the
software cannot cause a runaway condition due to the failure of a feedback
sensor?
3
Are known component failure modes considered in the design of the
software and checks designed into the software to detect failures?
4
Are Safety Critical Computing System Functions and their interfaces to
safety critical hardware controlled at all times, i.e., the interface monitored to
ensure that erroneous or spurious data does not adversely affect the
system, that interface failures are detected, and that the state of the
interface is safe during power-up, power fluctuations & interruptions, or in
the event of system errors or hardware failures?
5
Do decision statements in safety critical computing system functions not rely
on inputs of all ones or all zeros, particularly when this information is
obtained from external sensors?
6
Do inter-CPU communications successfully pass verification checks in both
CPUs prior to the transfer of safety critical data?
7
Are periodic checks performed to ensure the integrity of the interface?
8
Are detected errors logged?
9
If the interface fails several consecutive transfers, is the operator alerted and
44
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
the transfer of safety critical data terminated until diagnostic checks can be
performed? (The acceptable number of failures/retries should be defined in
the appropriate interface control documentation)
10
Are data transfer messages of a predetermined format and content?
11
Does each transfer contain a word or character string indicating the
message length (if variable), the type of data and content of the message?
12
As a minimum, are parity checks and checksums used for verification of
correct data transfer? Are Cyclic Redundancy Checks (CRCs) used where
practical?
13
Do checks ensure no information from data transfer messages is used prior
to verification of correct data transfer?
14
Does Highly Critical Data use robust data transfer protocols that ensure the
integrity of the data received is identical to the data sent? Linear checksums
and parity checks are generally inadequate to provide the desired integrity.
15
Are multiple input/output registers or buffers used to receive all of the
necessary signals for external functions requiring two or more safety critical
signals from the software (e.g., arming of an Ignition Safety Device or Arm
Fire Device and release of an air launched weapon)?
16
Are limit and reasonableness checks, including time limits, dependencies,
and reasonableness checks, performed on all analog and digital inputs and
outputs prior to safety critical functions' execution based on those values?
17
Does the design ensure that no safety critical functions are executable
based on safety critical analog or digital inputs that cannot be verified?
18
Is the software designed such that the full scale and zero representations of
the software are fully compatible with the scales of any digital-to-analog,
analog-to-digital, digital-to-synchro, and/or synchro-to-digital converters?
45
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Computing System Hardware Requirements
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Computing System Hardware Requirements
1
Do CPUs process entire instructions or data words rather than multiplex
instructions or data (e.g., an eight bit CPU is preferred to a 4bit CPU
emulating an eight bit machine)?
2
Do CPUs use separate instruction and data memories and busses rather
than using a common data/instruction buss? Alternatively, memory
protection hardware, either segment or page protection, separating pro-gram
memory and data memory is acceptable.
3
Can CPUs, microprocessors and computers be fully represented
mathematically?
4
For CPUs that do not comply with 1-3 above, or those used at the limits of
their design criteria (e.g., at or above maximum clock frequency), have
analyses and measurements been conducted to determine the minimum
number of clock cycles that must occur between functions on the buss to
ensure that invalid information is not picked up by the CPU?
5
Has analysis been performed to ensure that interfacing devices are capable
of providing valid data within the required time frame for CPU access?
6
Where Read-Only-Memories are used, are positive measures taken to
ensure that the data cannot be corrupted or destroyed?
7
Where system requirements include the ability to reprogram Read-Only
Memories, does the design of the reprogramming function ensure sufficient
checks of the integrity of the downloaded computer programs such that the
probability of an error in the downloaded program is less than 1 x 10-9.
8
Does the design of the system ensure that the system is not capable of
46
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
initiating reprogramming or erasing the Read Only Memory without special
programs that are not resident in the system?
9
Does reprogramming occur only in a maintenance state?
47
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Human Machine Interfaces Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
HMI/Operator Interface
1
Is the software designed such that the operator may cancel current
processing with a single action and have the system revert to a designed
safe state?
2
Is the system designed such that the operator may exit potentially unsafe
states with a single action?
3
Does this action revert the system to a known safe state? (e.g., the operator
shall be able to terminate missile launch processing with a single action,
which shall safe the missile.) The action may consist of pressing two keys,
buttons, or switches at the same time.
4
Where operator reaction time is not sufficient to prevent a mishap, does the
software revert the system to a known safe state, report the failure, and
report the system status to the operator?
5
Are two or more unique operator actions required to initiate any potentially
hazardous function or sequence of functions?
6
Are the actions required designed to minimize the potential for inadvertent
actuation, and shall be checked for proper sequence?
7
Are safety critical operator displays, legends and other interface functions
clear, concise and unambiguous and, where possible, duplicated using
separate display devices?
8
Is the software capable of detecting improper operator entries or sequences
of entries or operations and prevent execution of safety critical functions as a
result?
48
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
9
Does the software alert the operator to the erroneous entry or operation?
Alerts shall indicate the error and corrective action.
10
Does the software provide positive confirmation of valid data entry or actions
taken (i.e., the system shall provide visual and/or aural feedback to the
operator such that the operator knows that the system has accepted the
action and is processing it)?
11
Does the system also provide a real-time indication that it is functioning?
Processing functions requiring several seconds or longer shall provide a
status indicator to the operator during processing.
12
Are alerts designed such that routine alerts are readily distinguished from
safety critical alerts?
13
Are the operators not able to clear a safety critical alert without taking
corrective action or performing subsequent actions required to complete the
ongoing operation?
14
Are signals alerting the operator to unsafe situations directed as
straightforward as practical to the operator interface?
15
If an operator interface is provided and a potentially unsafe state has been
detected, does the system alert the operator to the anomaly detected, the
action taken, and the resulting system configuration and status?
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
49
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Analysis and Testing
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Software Analysis and Testing (Verification Requirements)
1
Is all software testing controlled by a formal test coverage analysis and
document?
2
Are computer based tools used to ensure that the coverage is as complete
as possible?
3
Does software testing include GO-NO-GO path testing?
4
Does software testing include hardware and software input failure mode
testing?
5
Does software testing shall include boundary, out-of-bounds and boundary
crossing test conditions?
6
Does software testing include minimum and maximum input data rates in
worst-case configurations to determine the system's capabilities and
responses to these conditions?
7
Does software testing include input values of zero, zero crossing and
approaching zero from either direction and similar values for trigonometric
functions?
8
Are safety critical computing system functions in which changes have been
made subjected to complete regression testing?
9
Does operator interface testing include operator errors during safety critical
operations to verify safe system response to these errors?
10
Does software testing shall include duration stress testing? The stress test
time shall be continued for at least the maximum expected operating time for
the system.
50
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
11
Is testing conducted under simulated operational environments?
12
Is additional stress duration testing conducted to identify potential critical
functions (e.g., timing, data senescence, resource exhaustion, etc.) that are
adversely affected as a result of operational duration?
13
Does software testing include throughput stress testing (e.g., CPU, data bus,
memory, input/output) under peak loading conditions?
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
51
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Maintenance
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
Verification
Method
A - Analysis
D - Demo.
I - Inspection
T - Test
Software Maintenance
1
Are changes to safety critical computing system functions on deployed or
fielded systems issued as a complete package for the modified unit or
module not patched?
2
When not implemented at the depot level or in manufacturer’s facilities under
appropriate quality control, are firmware changes issued as a fully functional
and tested circuit card?
3
Does the design of the card and the installation procedures minimize the
potential for damage to the circuits due to mishandling, electrostatic
discharge, or normal or abnormal storage environments, and shall be
accompanied with the proper installation procedure?
4
When not implemented at the depot level or in manufacturer’s facilities under
appropriate quality control, are software changes issued as a fully functional
copy on the appropriate medium?
5
Does the medium, its packaging and the procedures for loading the program
minimize the potential damage to the medium due to mishandling,
electrostatic discharge, potential magnetic fields, or normal or abnormal
storage environments, and shall be accompanied with the proper installation
procedure?
6
Are all modifications and updates subject to strict configuration control? The
use of automated configuration management tools is encouraged.
7
Is modified software or firmware clearly identified with the version of the
modification, including configuration control information? Both physical (e.g.,
external label) and electronic (i.e., internal digital identification)
52
Date: _________________
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
Examples:
CM - Configuration Management
SDD - Software Design Document/Description
SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
AMCOMR 385-17
#
Item
Compliance
Yes/No/ Not
Applicable
(Y/ N/ NA)
"fingerprinting" of the version shall be used.
53
Verification
Method
Verification Compliance Evidence or
Mechanism/ Rationale/ Comments
AMCOMR 385-17
Appendix B
AMCOM Safety Office Guidelines for the Use of Re-use, COTS, GFE
and NDI Software
54
AMCOMR 385-17
Re-Use/Commercial-Off-The-Shelf/Government Furnished Equipment/
Non-Developmental Items Safety
This Appendix discusses the topics of Re-use, COTS, GFE, and NDI software
components as they are used in the system acquisition and development process. Reuse, COTS, GFE, and NDI software pose unique technical and programmatic concerns
and problems for SS. This Appendix, derived from NAVSEA SW020-AH-SAF-010,
describes how the SSP must manage these issues for AMCOM programs. A special
safety approach must be applied in order to ensure safe overall system design when
Re-use/COTS/GFE/NDI software is incorporated in the system.
The decision to use COTS items does not reduce or eliminate the necessity to meet all
existing system safety requirements (SSRs) for the system.
A COTS item must be evaluated for safety as an integral part of the entire system.
SAFETY CONCERNS
The procurement of Re-use/COTS/GFE/NDI software, or commercial operational
support or maintenance of such an item, poses potential system safety and SwSS
problems for the PM. Problems usually result from the fact that most Reuse/COTS/GFE/NDI generally has an unknown safety pedigree. For example, Reuse/COTS/GFE/NDI may not have been built to a set of commercial standards; Reuse/COTS/GFE/NDI may not satisfy program safety requirements; and Reuse/COTS/GFE/NDI may not have data to verify safe system implementation. Also,
since the software already exists, the PM usually cannot change the design without
greatly increasing the cost or impacting the schedule. Additionally, the contractor or
entity proposing to use Re-use/COTS/GFE/NDI will often attempt to bid the software
incorporation as an as is “black box”, touting the savings of using the Reuse/COTS/GFE/NDI, without incorporating the cost or schedule implications of meeting
program safety requirements and providing safety verification for the Reuse/COTS/GFE/NDI.
In addition to Re-use/COTS/GFE/NDI software, this Appendix also discusses the safety
concerns pertaining to technology insertion and technology refresh. These aspects of a
system software update are generally viewed as COTS or NDI, because the new
component has not been developed or qualified with the original system design.
TERMINOLOGY/DEFINITIONS
NON-DEVELOPMENTAL ITEM (NDI)– Items that are used in the system development
program, but are not developed as part of the program are NDIs. They have been
previously developed for Government Federal, State, local, or foreign purposes and
exist external to the program. They were not developed under the program design
requirements and are procured as a “black box” in the system design. Sometimes very
little is known about their internal workings and pedigree. NDIs were developed for
another Government program under different design requirements that may not have
been a DoD program.
55
AMCOMR 385-17
COMMERCIAL-OFF-THE-SHELF (COTS)– Items that are commercially available from
existing inventory are considered COTS. They are generally commercially developed
items that require no unique Government modifications or maintenance over the
lifecycle of the product to meet the needs of the weapon system. COTS items are
purchased by the program for as-is use in the system, as opposed to being designed
and developed as part of the program. In some cases, COTS items are modified for use
in the system, while in other cases, COTS items cannot be modified. Examples of
COTS software include the different operating systems that can be purchased for
computer systems or mapping/display software.
GOVERNMENT FURNISHED EQUIPMENT (GFE) – Property in the possession of or
acquired directly by the government, and subsequently delivered to or otherwise made
available to the contractor. For example, when starting development on a new aircraft,
the government may require the use of the radar from an existing aircraft. In this case,
the radar is already in use, and was designed and built to the specifications and
requirements of a different aircraft system.
TECHNOLOGY REFRESH – Replacing obsolete or no longer available
hardware/software components with components having identical or similar functions
with newer technology is known as technology refresh. It is very likely that since the
original development of the component, the technology involved has changed or
improved, and new replacement parts have been developed using new processes or
materials. Therefore, when performing technology refresh, an essentially new
component that has not been developed or qualified with the original system design is
placed into the system design (which may have unknown collateral effects).
TECHNOLOGY INSERTION – Replacing existing, but not necessarily obsolete,
hardware/software components, with newer technology that enhances system
capabilities is known as technology insertion. This is a case of intentionally replacing a
component because the replacement component uses newer and better technology that
should provide a benefit to system operation. In this case as well, the new component
has not been developed or qualified with the original system design.
SOFTWARE RE-USE – Using a previously developed software module (typically COTS
or NDI) in a software application or program that is under development. Software Reuse involves using previously developed software because it is already built and it
performs a function that is required by the new system. The Re-used software could
include generic COTS software, such as a computer operating system, or a specialized
software module from another project, such as the Missile X guidance software module
being used on the new Missile Z system for missile guidance and control. Re-used
software could also be a mathematical routine from a library.
NOTE: For the remainder of this Appendix the term COTS will be used as a generic
term to include re-use, COTS, GFE, and NDI for all items and components not
specifically developed by the program managing or building the system of interest.
56
AMCOMR 385-17
GENERAL COTS CHARACTERISTICS
Each particular COTS item has its own unique set of inherent characteristics that evolve
into advantages and disadvantages for using that particular COTS item. These
characteristics are stated in terms of advantages and disadvantages as follows:
COTS Advantages (actual or perceived)
a. Cost savings (no development costs)
b. Rapid insertion of new technology
c. Proven product/process
d. Possible broad user base
e. Technical support
f. Logistics support
COTS Disadvantages
a. Unknown development history (standards, quality assurance, test, analysis,
failure history, etc.)
b. Design and test data unavailable (drawings, test results, etc.)
c. Proprietary design (prohibits information, cost to obtain design information and/or
licenses may be prohibitive)
d. Unable to modify
e. Unknown limitations (operational, environmental, stress, etc.)
f. May not be supported (configuration control, tech support, updates, etc.)
g. May include extra unnecessary capabilities
h. Unknown part obsolescence factor
i.
Safety analyses unavailable or not applicable
j.
May require increased test and analysis for safety verification
The advantages and disadvantages of COTS must be carefully weighed against the
program requirements before determining usage of COTS. Additionally, contractors
proposing to incorporate COTS into their design must address the cost and schedule
issues associated with providing the required safety assurance for COTS.
COTS CONSIDERATIONS
PMs must understand that often the use of COTS is cheaper only because standard
DoD development tasks have not been performed; when the costs to perform these
necessary tasks to fully evaluate the COTS in the system application, COTS may prove
not to be the best alternative. Specifically, hazards must be identified, risks assessed
57
AMCOMR 385-17
and the risk made acceptable regardless of how the component/function is developed.
The decision to use COTS does not negate SSRs.
ASSESSING MISHAP RISK POTENTIAL. If COTS is used in a safety critical function
(SCF), a considerable amount of design and test data on the COTS is required to assist
the system safety engineer in assessing COTS mishap risk potential. The amount of
design and test data required is based upon the results of the SwSS analyses. The
environment for which the COTS was originally designed must be known, in order to
determine if it can meet the new system operational environment. Each COTS has a
unique development history that must be thoroughly evaluated to determine its effect on
the safety of the new system. COTS is generally built to commercial standards, but the
particular standards followed can vary or be unknown. Information on all of the
standards that were used in the development and manufacture of the COTS is relevant
for system integration. System requirements (environmental, operational, performance,
reliability) may exceed those under which the COTS was initially developed. Knowing
what qualification tests were performed is also essential to determining the safety of the
overall system.
Operational capability of the COTS is a factor that must be known. The COTS may
provide more or less capability than required. The system developer must know and
include the effects of integrating the COTS into the system when it has a different set of
capabilities than required.
Most COTS are generally in use by other systems, which means they already have field
experience. The usage history of COTS will provide some clues for safety, reliability,
maintainability and support of the item. The critical variable is how much data on the
COTS is available and applicable to its use in the new system (evidence of failures,
hazards, problems, etc.).
When developing a system, the optimum situation is to have all of the design
requirements, drawings and test results available. Having the source code available for
COTS software is also highly desirable. This information is key for safe integration of
the COTS into the new system.
Vendor supportability is a significant factor for the incorporation of COTS into a new
system. Does the vendor provide manuals and training on the product? Does the
vendor provide upgrades and notify users of design changes? Does the vendor supply
warrantees with the COTS? Another key consideration is the cost of vendor support.
The ability to modify COTS is a prime consideration and involves the amount of control
the system developer has over the COTS. The first question to be answered is, does
the COTS require modification in order to meet system requirements? The second
question to be answered is, does the COTS provide the capability for modification? If it
can be modified, must the vendor do it (in order to remain COTS), or can the system
developer modify it (no longer COTS, but is re-use)? Any modification of COTS is a
serious consideration because of the costs involved (license, warranty, support).
CM involves vendor control over the COTS and user notification of changes. When the
vendor modifies COTS in any way, version control should be, but may not always be,
58
AMCOMR 385-17
maintained and provided to all of the product users. Version control is particularly
significant with COTS software.
SAFETY CONCERNS
The use of COTS presents a number of concerns and problems for system safety and
SwSS. There is an increasing trend to use COTS because of DoD acquisition guidance
and because potential financial benefits appear attractive. The proposal to use COTS
promises savings in development costs, in schedule reduction, in programmatic risk and
in supportability. Unfortunately, keeping these promises without requiring COTS to
adhere to program safety requirements may actually adversely impact safety.
LACK OF ITEM DATA. Most of the safety concerns and problems associated with
COTS are a result of the particular characteristics involved, and their impact on the new
system design and operating environment. The lack of COTS safety data is the prime
contributor to safety problems and concerns. Similarly, the lack of design, test and
qualification information, and knowledge makes the safety assessment process more
difficult.
OTHER SAFETY ISSUES. There are many aspects to COTS safety, but in general,
COTS safety issues revolve around several key questions. As these particular
questions are answered, the safety steps to be taken in a COTS safety program will
naturally evolve. These key questions are:
a. Does the COTS meet all system development requirements involving safety?
b. Does the COTS have any inherent hazards?
c. Can the COTS contribute to any system hazards when integrated into the
system?
d. Can the COTS be changed or modified without safety review?
e. Is the COTS part of a SCF?
f. Does the COTS contain unneeded (extra, or unused) functionality?
In order for the system to meet all design SSRs, it is necessary to know what
requirements the COTS was designed and built to meet. This includes requirements for
design, development testing and qualification testing. If the COTS was not designed or
tested to meet a specific system requirement of the program utilizing the COTS, then
the program has identified a safety concern that must be resolved. If none of the COTS
development requirements are known, then the safety problem is even greater.
Additionally, the uncertainties must be addressed as candidates for safety residual risks
for the system.
COMMERCIAL STANDARDS. For example, a COTS Ultra High Frequency (UHF) radio
is going to be used in a new military aircraft refueling tanker. This new tanker aircraft
has a safety requirement that all cockpit equipment be designed and tested to meet
certain levels of Electron Magnetic Interference (EMI). The SSP must determine if the
UHF radio was designed and tested for EMI and if it was tested to the specific EMI
levels required. If this requirement is unknown or not met, then the program must make
59
AMCOMR 385-17
some critical decisions, such as: use a different UHF radio, perform extra tests on the
radio, waive the requirement, or accept the mishap risk. Knowledge of the commercial
standards to which the COTS was built is a key element needed to adequately assess
system safety risks for the system.
INHERENT HAZARDS. It is necessary to determine if the COTS has any inherent
hazards. This involves obtaining and reviewing previous safety studies performed on
the COTS. It would also involve evaluating historical usage experience data on the
COTS to determine what types of problems have already been experienced. If the
existing inherent safety of the COTS is unknown, then system safety must be
conservative and assume the worst (i.e. assessment of residual risk). Perhaps the
product will require special safety testing, or reverse engineering, to evaluate inherent
safety. The most critical question that must be answered is, will the COTS contribute to
any system hazards when integrated into the new system? The COTS must be an
integral part of all hazard analyses performed on the system to determine if it can
contribute to causing any significant hazards. Additionally, those system hazard
analyses must accurately scope/bound the system in which the COTS is implemented.
This means that design information, reliability information, and previous hazard
analyses data must be available. If this information is not available to the safety analyst,
then a comprehensive hazard analysis of the system cannot be performed, and total
system mishap risk is not fully known.
CONFIGURATION CONTROL. Another important safety aspect of COTS is the
assurance that the SSP reviews all changes to the COTS by the COTS supplier, and
that the PM accepts the changes. Programs must know that when replacement COTS
are provided, they do not contain any internal changes since the last safety analysis and
acceptance of the item. The capability of the COTS vendor to maintain accurate CM
and provide update and version control information is a key aspect to COTS safety. This
would be a good example of technology refresh without safety visibility.
Many COTS safety concerns are functions of the level of vendor support. Good vendor
support can make the COTS safety integration and verification process much simpler.
Types of vendor support that are beneficial include providing design information,
reliability data, problem reports, design changes, obsolescence information,
maintenance data, and manuals.
SAFETY CRITICALITY. A key safety aspect of COTS is whether or not it is used in a
safety-critical (SC) system function. If COTS is part of a SC function, then it becomes a
key system player and all of its design, operation and test attributes must be known. If a
COTS item is part of a SR function, then its safety sensitivity is a little lower (than an SC
function). In addition, if COTS is part of a non-safety related (NSR) function, then there
will likely be very little safety concern about the item, however, this does not waive the
need for COTS safety analysis.
FUNCTIONALITY. Another COTS safety concern is unneeded (extra or unused)
functionality. If the COTS item has more functionality than is needed by the new system,
it is possible that this functionality may be the source of safety problems or hazards in
the new system design. This is an aspect that must be ruled out by safety analysis
and/or testing.
60
AMCOMR 385-17
RECOMMENDED SAFETY APPROACH
In an ideal situation, COTS would be included in the standard SSP as just another
subsystem. The problem is that the safety engineer may not have enough data on the
COTS to fully understand it. In addition, the PM has little or no control in affecting
changes in the COTS to enhance its safety level. Therefore, the SSP is unable to
address the COTS portion of the total system with the same degree of safety rigor that
was applied to the rest of the system.
The recommended approach for system safety when dealing with COTS in the system
consists of the following tasks:
a. Establish program safety precepts/principles for COTS.
b. Incorporate COTS into the SSP/SSPP/SwSSPP.
c. Incorporate COTS into the system safety hazard analyses.
d. Evaluate COTS within the SwSS program. Classify the COTS with Software
Hazard Risk Index (SHRI) values as defined in the SSPP/SwSSPP.
e. Ensure COTS design requirements meet all SSRs. Based on letters a–d above,
establish the safety verification requirements for COTS.
f. Assess the residual risk of COTS, based upon available data, code, history, etc.
g. Build a SAR or safety case for the COTS.
Note that these are generic steps for developing a COTS safety case. Sub-tasks within
these steps may vary for different COTS depending upon the amount of data and
information that is available to support the safety tasks. Regardless, COTS is subject to
the same SSRs as developmental software. A flow diagram for this COTS safety
approach is shown in Figure B-1.
A. ESTABLISH PROGRAM SAFETY PRECEPTS/PRINCIPLES FOR COTS ITEMS.
When establishing the SSP and preparing the SSPP/SwSSPP, consideration should be
given as how to handle COTS in the SSP. Safety principles and precepts can initially be
established to provide design and safety guidance. The following are some example
COTS safety precepts provided for consideration:
a. Do not allow COTS in SCFs.
b. COTS allowed in SCFs only upon verification of compliance with SSRs, or
determination and acceptance of residual risk of the COTS by the appropriate
approval authority, as defined in the SSMP.
c. Do not allow COTS to initiate control of SCFs.
d. COTS allowed to initiate SCFs only upon verification of compliance with SSRs, or
determination and acceptance of residual risk of the COTS by the appropriate
approval authority, as defined in the SSMP.
e. COTS allowed in SCFs or allowed to initiate SCFs, provided adequate additional
independent safety controls are implemented and verified to mitigate COTS
safety failures.
61
AMCOMR 385-17
Establish COTS
Precepts &
Principles
Develop COTS
Plan
Perform System
PHA
Is COTS in
SC Function?
Y
N
Perform COTS
SSHA
COTS Cat
I/II Hazard?
Is COTS in
SR Function?
Y
Correlate COTS
SSRs
Y
N
Y
Are all
SSRs met?
N
N
COTS III/IV
Hazard?
N
Y
Classify COTS
as NSR
Classify COTS
as SR
Classify COTS
as SC
Identify Safety
Tests
Perform
Detailed
Analysis
Perform Safety
Tests
Risk
Assessment
Safety Case
CA6a-03303
Figure B-1. Flow Diagram of COTS Safety Process
(from NAVSEA SW020-AH-SAF-010)
B. INCORPORATE COTS INTO THE SSP/SSPP/SWSSPP. This step involves
incorporating COTS into the SSP via the SSPP/SwSSPP to ensure safety of the system
using COTS. It can be a subsection of the SSPP/SwSSPP and is especially important
for program upgrades (technology refresh, technology insertion, software Re-use) using
COTS. Incorporating COTS should address what steps are needed to ensure safety
while considering various situations of data availability. Safety strategy should
especially focus on analysis and testing. For example, if qualification testing of the
COTS is unknown, then the SSP should state the special qualification testing that must
62
AMCOMR 385-17
be performed on the COTS. For technology refresh and technology insertion items, it is
important to include in the plan a methodology for:
a. Ensuring all new items are evaluated for safety impact
b. Safety is aware of design updates, revisions and version control
C. INCORPORATE COTS INTO THE SYSTEM SAFETY HAZARD ANALYSES. This
step involves including COTS in the program’s system safety hazard analyses. Various
hazard analyses are standard tasks in the SSP regardless of whether COTS are used.
This task is identified here in order to ensure that the SSP and safety analyses place
proper emphasis on COTS and their safety significance in the system design. It is
important to identify the SC functions in the system, and to determine if the COTS are
part of the SC functions.
a. Identify hazards involving COTS
b. Identify SCFs involving COTS
D. EVALUATE COTS WITHIN THE SWSS PROGRAM. CLASSIFY THE COTS ITEM
WITH SHRI VALUES AS DEFINED IN THE SSPP/SWSSPP.
As a result of the system safety hazard analyses, a determination should be made as to
whether the COTS is involved in a SCF. COTS should be evaluated and rated as
belonging in one of the following categories (unless another categorization is in the
approved SSPP/SwSSPP):
a. Safety Critical (SC) – involved in the path set of a SC function (tied to a hazard)
b. Safety Related (SR) – involved in the path set of a SR function (associated with a
hazard, but not SC)
c. Non-Safety Related (NSR) – not part of any SC or SR functions
This step involves performing a detailed SwSS assessment of the COTS functionality
within the system design. The purpose is to determine the safety criticality of the COTS
relative to inherent hazards, identified system level hazards and if the COTS can
contribute system hazards. The COTS will be assessed in accordance with the SSP,
SSPP, and/or SwSSPP. The assessment must be performed in-depth to identify and
evaluate COTS verification requirements (level of rigor). If the necessary design, safety,
reliability, performance, maintainability, and test data is available, this task may be
straightforward. If the needed data is not available, then additional COTS verification
may be required to gain confidence in the final safety assessment. Otherwise, additional
safety controls must be implemented, or the COTS contribution to residual risk must be
assessed and accepted by the appropriate management authority.
E. ENSURE COTS DESIGN REQUIREMENTS MEET ALL SSRS. This step involves
reviewing the design and test requirements that the COTS was originally developed to
meet, and comparing these requirements with the design requirements of the system
incorporating the COTS. This step also involves ensuring that the COTS meet all
required component qualification tests. If the COTS fails to meet all system
requirements, then some critical decisions must be made, as follows:
a. Perform the necessary system tests with the COTS
63
AMCOMR 385-17
b. Use different COTS that does meet the requirements
c. Waive the requirement(s)
d. Accept the mishap risk associated with doing nothing
If there is insufficient information to determine the exact design and test requirements to
which the COTS was developed to satisfy, then additional critical decisions must be
made as follows:
a. Expand COTS testing
b. Limit the usage of the COTS
c. Design to protect against malfunction of the COTS item
d. Design to account for potential undesirable worst case attributes of the COTS
F. ASSESS THE RESIDUAL RISK OF COTS. This step involves assessing the overall
safety residual risk of the COTS. It is based upon several factors, such as:
a. The COTS functional criticality rating: SC, SR or NSR
b. The COTS mishap severity category rating (I, II, III or IV) for COTS related
hazards
c. How well the COTS satisfies design SSRs
d. How well the COTS satisfies qualification test requirements
Based on the assessed COTS residual risk and the criteria established in the SSMP
and SSPP, specific SSRs may have to be levied on the COTS in order to mitigate the
residual risk to a Government approved level. Some possible COTS related SSRs might
include:
e. COTS prohibited in SC functions
f. Special COTS qualification testing required
g. System regression testing required
h. Special COTS safety testing required
i. Fault injection tests with COTS required
j.
COTS prohibited from initiation control of a SC function
k. System design (additional software functionality developed, such as middleware,
or incorporation of hardware safety devices) that monitors COTS and takes
corrective action if a problem occurs
l. Applicable SSRs are verified as being met prior to use
Some generic SSRs than can be levied against COTS based on their functional safety
rating are:
a. SC COTS – Require extensive analysis and test (as defined by the SHRI value
and SHCM)
64
AMCOMR 385-17
b. SR COTS – Require less extensive analysis and test (as defined by the SHRI
value and SHCM)
c. NSR COTS – Require safety analysis showing no safety impact of COTS (as
defined by the SHRI value and SHCM)
G. BUILD A SAR OR SAFETY CASE FOR THE COTS. The final step is to build a
document and a safety case for (or against) the COTS. This step involves assessing the
overall safety mishap risk of the COTS and providing recommended action to accept,
reject, further evaluate (test or analysis) or modify. It is based upon several factors,
such as:
a. The COTS functional criticality rating: SC, SR or NSR
b. The amount and quality of the design and test data available
c. The COTS contribution to system hazards
d. How well the COTS satisfies design SSRs
e. How well the COTS satisfies qualification test requirements
The amount of detailed safety analysis and testing of the COTS is based on its
functional criticality rating and verification requirements defined in the SSMP and
SSPP/SwSSPP. For SC items, more stringent testing and analysis are necessary in
order to provide confidence in the safety of the system with the COTS integrated into
the system.
65
AMCOMR 385-17
SUMMARY – COTS SAFETY PRINCIPLES
NOTE: The term COTS is still being used as a generic term to include re-use, COTS,
NDI and GFE for all items and components not specifically developed by the program
managing or building the system of interest.
This Appendix discussed the basic concept of COTS Safety. The following are basic
principles that help describe this concept and summarize the discussion in this
Appendix:
a. COTS are “already developed” items that are incorporated into a new or existing
system. Generally, nothing can be done to modify or enhance the safety of
COTS itself.
b. Each COTS has it own unique history and characteristics.
c. The particular characteristics of a COTS and how it is used generally establish
the safety concerns and problems for integration of a COTS into a system.
d. COTS safety concerns include:
(1) Lack of data for adequate hazard analyses
(2) Inability to determine if safety requirements of the system are met
(3) Determination of the resolution of SSRs that are not met
(4) Lack of knowledge of the configuration
(5) Lack of vendor support
e. The recommended SSP approach for COTS consists of the following steps:
(1) Establish program safety precepts/principles for COTS items.
(2) Incorporate COTS items into the SSP/SSPP.
(3) Incorporate COTS items into the system safety hazard analyses.
(4) Evaluate COTS within the SwSS program. Classify the COTS with SHCI
values as defined in Section 6.1 and the SSPP/SwSSPP.
(5) Ensure COTS design requirements meet all SSRs. Establish, based upon
the a-d above, the safety verification requirements for COTS.
(6) Assess the residual risk of COTS.
(7) Build a SAR or safety case for the COTS.
f. The decision to use COTS items does not reduce or eliminate the necessity to
meet all existing SSRs for the system.
g. A COTS item must be evaluated for safety as an integral part of the entire
system.
66
AMCOMR 385-17
Appendix C
Example Safety-Critical Software Functions (SCSFs)
67
AMCOMR 385-17
LIKELY SCSFS
• Any function which controls or directly influences the pre-arming, arming, enabling,
release, launch, firing, or detonation of a weapon system, including target
identification, selection and designation.
• Any function that determines, controls, or directly influences the flight path of a
weapon system.
• Any function that controls or directly influences the movement of gun mounts,
launchers, and other equipment, especially with respect to the pointing and firing
safety of that equipment.
• Any function that controls or directly influences the movement of munitions and/or
hazardous materials.
• Any function that monitors the state of the system for purposes of ensuring its safety.
• Any function that senses hazards and/or displays information concerning the
protection of the system.
• Any function that controls or regulates energy sources in the system.
• Fault detection priority. The priority structure of fault detection and restoration of
safety or correcting logic shall be considered safety-critical. Software units or
modules handling or responding to these faults.
• Interrupt processing software. Interrupt processing software, interrupt priority
schemes and routines that disable or enable interrupts.
• Autonomous control. Software components that have autonomous control over
safety-critical hardware.
• Software controlled movement. Software that generates signals which have been
shown through analysis to directly influence or control the movement of potentially
hazardous hardware components or initiate safety-critical actions.
• Safety-critical displays. Software that generates outputs that displays the status of
safety-critical hardware systems. Where possible, these outputs shall be duplicated
by non-software generated output.
• Critical data computation. Software used to compute safety-critical data. This
includes applications software that may not be connected to or directly control a
safety-critical hardware system (e.g., stress analysis programs).
68
AMCOMR 385-17
Appendix D
Software Safety Requirements Verification Guidelines
69
AMCOMR 385-17
This appendix provides guidance on the detailed verification activities required to
provide sufficient verification evidence for identified software safety requirements, based
upon the SHRI assigned to the requirement and its location on the SHCM. Tailoring,
based upon established contractor SD and SwSS practices and requirements, is
permitted provided that the tailored verification activities and requirements are approved
by the PO and AMCOM SwSS. The verification requirements apply developmental, nondevelopmental, COTS, GFE, and Re-use software.
Verification Activities
Software Hazard Criticality Matrix (SHCM) Category Based Upon
Software Hazard Criticality Index (SHCI)
R – Denotes Activity is Required
Low
Moderate
Medium
High
Analysis that Software Safety Requirements have been
identified, captured in the specifications and trace to
specifications, hazard analyses, design and code
implementation
R
R
R
R
Analysis of requirements to determine safety criticality and
verification requirements based upon software functionality and
hazard analyses
R
R
R
R
R
R
R
R
R
R
R
R
Hardware and software input failure mode testing. Error case
testing performed to test the software handling of unexpected
values. Includes supporting analysis that determines plausible
errors to be considered for tests.
R
R
Boundary, out-of-bounds, and boundary crossing test
conditions. Black box testing to verify data is properly handled at
the boundaries of valid input ranges.
R
R
Analysis of safety threads of software to ensure that all paths
lead to the desired outcome, that there are no unused code
paths or unused/undesired entry/exit points into/out of the
software threads
a. Every predicate term tested. Verification that every statement
in the safety-critical software code has a defined behavior for
equivalent classes of inputs.
b. Code interface analysis. Evaluation of internal and external
interfaces of safety-critical units to ensure compatibility across
the interface.
c. Every assignment to memory tested. Testing to ensure that
data items are protected from being overwritten by unauthorized
operations. Can also be shown by analysis of the design.
d. Every reference to memory tested. Analysis to ensure that all
calls for data from memory lead to the correct storage location
of the variable.
e. Every statement executed once.
f. All modules in safety critical code executed at least once.
Test Verification Activities
Software testing shall be controlled by a formal test coverage
analysis and procedure. Computer based tools shall be used to
ensure coverage is as complete as possible.
R
GO-NO-GO path testing. Verification of anticipated behavior for
a credible set of nominal and off-nominal inputs. For example, if
only “Real” data is permitted, then testing should include a mix
of Real and Non-Real (Test, Simulation, Exercise, etc.)
message data, or if a path requires a numeric input greater than
some value, then testing that includes a number of logical data
values greater than, less than and equal to the GO value
Input values of zero, zero crossing, and approaching zero from
either direction or similar values for trigonometric functions.
R
Operator interface testing with the introduction of operator errors
during safety critical operations to verify safe system response
to these errors.
R
70
R
R
AMCOMR 385-17
Throughput stress testing. Minimum and maximum input data
rates in worst-case configurations to determine the system's
capabilities and responses to these conditions.
R
R
Duration stress testing. The stress test time shall be continued
for at least the maximum expected operating time for the
system. Testing shall be conducted under simulated operational
environments. Additional stress duration testing should be
conducted to identify potential critical functions (e.g., timing,
data senescence, resource exhaustion) that are adversely
affected as a result of operational duration. Software testing
shall include throughput stress testing (e.g., CPU, data bus,
memory, input/output) under peak loading conditions.
R
R
R
R
Complete regression testing for safety critical computing system
functions in which changes have been made.
R
71
R
AMCOMR 385-17
Appendix E
Evaluation of Software System Safety Programs
72
AMCOMR 385-17
INTRODUCTION
Safety is the responsibility of the system and software developer(s). The Government
program office and AMCOM Safety Office have management oversight responsibilities
for ensuring software is safe, or that the risks associated with the software have been
identified and accepted. This appendix is representative of items for Government
program offices and AMCOM Safety to request as amplifying evidence that the program
under evaluation is implementing a formal, structured System Safety and SwSS
Program, and in particular, that SwSS is addressed from the onset of SD and integrated
within the various program SD and verification processes. Assurance of the adequacy
of safety processes, their implementation, verification and oversight is required to
mitigate system level hazards that may be contributed to by software and assure that
there is no inherent residual risks associated with safety critical software.
SwSS requires an understanding of the larger system, its mission, capabilities and
development processes. SwSS must be considered in the context of the system’s
associated hardware, environment, and operators. The SwSS Program needs to
address interfaces with these elements. The safety premise driving the analyses is that
uncontrolled software hazard contributors can be propagated, via the interfaces, onto
supported systems, and that those systems may be placed into a hazardous condition
as a result.
Performing detailed software safety analyses and verification activities are means to
provide evidence that safety risks associated with the use of safety-critical software
have been mitigated. SwSS assurance requires evidence of strong management
support for the program safety effort. Evidence of empowerment of Safety to accomplish
its task and the program’s providing the necessary resources (authority, personnel,
schedule and budget) to accomplish the safety mission is required.
SwSS is optimally accomplished as an integral aspect of the system and SD processes.
Not only is this the optimum method for identification and control of software
contributions to system level hazards, it is also the optimum means to minimize impact
to the overall SD cost and schedule. The SwSS process must be applied to all software,
including COTS, GFE, Re-used code, and NDIs. Throughout this appendix, the term
COTS encompasses all of these items.
1.1
Program Office and AMCOM Safety Office Requests/Questions
1.1.1 Provide an overview of the overall SSP and process, to include how the program
addresses software safety and appropriate references to safety documentations and
command media.
1.1.2 Does the SSP detail how SwSS requirements and activities are addressed in?
• SD
• CM
• SQA
73
AMCOMR 385-17
• Software V&V
• System Safety
(Provide evidence or references to program documentation containing evidence)
1.1.3 Do program system safety processes and requirements flow down to the
contractor and all sub-contractors, including developers of off-the-shelf and nondevelopmental software?
• How does the program assess and verify the safety of COTS, GFE, Re-use and NDI
software?
1.1.4 How many system safety personnel are allocated to the program?
• What levels of SwSS experience are there within the System Safety Team?
1.1.5 How and where are industry standard (STANAG 4404, JSSSH) software safety
guidelines incorporated into the SD and safety processes as requirements?
• How are they verified (ex. checklists, process documents, SQA audits and records,
incorporation into System and software design documents, test plans, processes,
and execution, etc.)?
• If guidelines are not implemented as requirements, or tailored out, how does the
program provide safety assurance at an equivalent level to the non-implemented
requirements?
• Via added analysis and/or testing?
1.1.6 Does the program have a SSWG or equivalent?
• If not, how is that critical function performed on the program?
• How are SwSS issues addressed within the SSWG (or safety group forum)?
1.1.7 How is software’s contribution to system level hazards assessed within a
structured, disciplined system safety program?
• Are software hazard contributions to system level hazards tracked independently or
simply as “software failure” within system hazard tracking logs?
1.1.8 Does the system safety program include the following and where is the evidence
captured?
• System hazards identified through a systematic analysis approach?
• SCSFs identified and associated with the system capabilities and system hazards?
• Software contributions to system level hazards identified and traced to their system
level requirements, hazards and code implementation?
• Assessment of the severity of the hazards and identification of software hazard risk?
74
AMCOMR 385-17
• Program’s process/plan for tying safety verification requirements/level of rigor to
software hazard risk. Definitions of the specific verification levels of rigor for each
level of software hazard risk?
• Identification of system hazard and software hazard contributor mitigation
techniques?
• Software hazard controls specified via requirements when the system level hazard(s)
can be traced to software?
• Those requirements traceable to both the hazard analyses and the software design
and implementation?
• System safety and SwSS requirements tracked in a configuration controlled
database?
• V&V of the software requirements implemented to mitigate software hazard
contributors to system level hazards?
• Safety reviews all test plans, test execution, test results and test incident reports that
impact verification of safety requirements?
• Verification includes required regression testing for software changes?
• Safety is part of the Change Control process and reviews/approves all changes that
have potential safety impacts?
• Software contributions to system level residual risk assessed and reported to the
System Safety Manager and subsequently to the appropriate management decision
authority for disposition?
• How is residual risk assessed, processed and accepted within the program and
Government(s) Management structure?
• How will program residual risks be reported to end users, such as the U.S. Army?
1.1.9 Are hazard mitigation measures (controls) identified and incorporated into the
design at the earliest stage practical, which results in the least impact to cost and
schedule?
1.1.10 Are detailed safety analyses (FTA, FMEA, sneak circuit analysis, code analysis,
etc.) performed for catastrophic and critical system level hazards?
• Is the software included in these analyses?
• If not, how is the program planning to demonstrate compliance with MIL-STD-882 for
risk mitigation and verification that an acceptable number of independent safety
features are in place?
1.1.11 How and where are program hazards tracked?
• What is the hazard tracking review process?
• Who approves that hazards are adequately identified and characterized in the hazard
tracking systems?
• What is the process for closing hazards?
75
AMCOMR 385-17
1.1.12 Which of the “standard” safety analyses are performed by System Safety and
where is the evidence documented?
•
•
•
•
•
•
•
•
Which of the following documents are included as or within Contract Deliverables?
PHA
Safety Requirements/Criteria Analysis
Subsystem Hazard Analysis
System Hazard Analysis
SAR
Operating and Support Hazard Analysis Report
Health Hazard Assessment Report
1.1.13 Does the system design rely solely on software features to mitigate catastrophic
and critical system level hazards? Generally, software design and controls are not an
acceptable substitute for hardware safety features.
1.1.14 How is system design going to provide sufficient numbers of independent safety
features to preclude hazards during Embedded Training, Test/Training/Exercise, SimOver-Live, and Concurrent Test, Training and Operations?
• Are all of the proposed safety features/controls software incorporated?
• If so, how does the program plan to demonstrate independence and adequacy of the
features/controls?
1.1.15 How is the program assuring Safety participation in Joint, Net-centric System of
Systems architectures?
1.1.16 How is Safety incorporated into the program milestone review process?
1.1.17 What is the program’s formal process for final safety acceptance of the system
and software prior to testing, procurement decision, and fielding?
1.1.18 Is Safety a member of all program IPTs?
1.1.19 Who has the Government PO selected to perform IV&V (hardware and software)
for the program?
• Has the IV&V organization been provided full access to program data, including
source codes?
1.2
Software Development Program Phase Safety Requirements – Are the Following
Accomplished?
The software developer, in coordination with Safety, should develop safety entry/exit
criteria for each program phase of the SD (for example: concept development,
requirements, architecture design, detailed design, coding, integration, test, verification,
76
AMCOMR 385-17
etc.). The safety entry/exit criteria should be documented in the appropriate sources.
Safety and SQA share responsibility for verifying compliance with criteria and providing
the necessary evidence of compliance to the appropriate management authority for
acceptance and approval.
1.2.1 Are Safety entry/exit criteria and evidence provided to the appropriate
Government Safety Offices within an approved period of time prior to milestone reviews
or IAW the delivery dates on the Safety Program Schedule?
1.2.2 Are the following generic software contributors to a hazard (causes) included in
the hazard analyses and considered in the development of subsequent software safety
requirements?
•
•
•
•
•
•
•
Not performing a function required
Performing a function not required
Performing a function out of sequence
Failure to recognize existing hazardous conditions
Inadequate response to contingencies
Wrong decision on problem solution
Poor timing – operation/command performed too soon or too late
1.3
Software Safety Analysis
The responsibility for assuring that software is adequately analyzed and tested is
shared between the SD team (Software Systems Engineering, Development and Test)
and SwSS. Each is responsible for meeting the software safety analyses and
verification requirements for the SD.
1.3.1 How is software safety analysis conducted and accomplished on the program?
The objective of SwSS is to ensure that the software will be analyzed, designed, and
tested to verify that identified software contributions to system level hazards are either
eliminated or controlled sufficiently. Success of the SwSS effort will form the basis for
closure of software causes (or separately identified software hazard contributor
(hazards)) within hazard tracking logs which support system level hazard mitigation
efforts.
1.3.2 How is this objective accomplished on the program?
1.3.3 Does SwSS perform the following activities in support of the overall safety effort?
• Review safety critical software, which could contribute to an undesired event, to
determine compliance with software safety requirements and guidelines?
• Identify SCSFs. SCSFs include safety-critical software functionality and identified
software requirements (controls) to mitigate failures of SCSFs?
77
AMCOMR 385-17
• Review and provide input to test plans and software problem reports, Engineering
Change activities and Requests for Deviations/Waivers, for adverse safety impacts.
• Verify corrective actions address safety concerns adequately?
• Develop fault trees and/or other detailed safety analyses using the results of the
preliminary hazards analysis and software requirements analysis? Software fault
trees are a logical model of a path to an undesired event, (for example, inadvertent
sensor tasking that may result in RF emissions) showing possible hardware failures,
software anomalies, and human inputs that could contribute to the undesired event.
The detailed safety analyses shall be sufficient to enable the Government Customer
to make a determination of final hazard risk and potential residual risk.
• Use the results of detailed safety analyses, updates the hazard analyses, and
support software and test case development?
• Monitor tests that verify safety requirements and review test reports and results?
• Ensures regression testing is performed, as necessary?
SOFTWARE SAFETY VERIFICATION
1.3.4 How does the program implement software safety verification requirements?
1.3.5 How does the program delineate and implement verification levels of rigor for
each SHCI?
• What are the specific verification requirements for each level of rigor defined by the
program?
1.4
Software Safety Verification Requirements
Software safety requirements may be verified at any level of the SD, as appropriate.
The typical SD is broken down into: Software requirements and architecture, unit code,
integration (includes unit integration into component level software and component
software integration into system level software), and system level. The level of rigor
required for safety verification is largely independent of SD technique. Verification may
be tailored to the SD process implemented, provided the required level of software
safety verification is performed.
1.4.1 Does the program’s safety verification meet the following minimum software
formal test coverage requirements?
• Software testing controlled by a formal test coverage analysis and procedure?
• Computer based tools used to ensure coverage is as complete as possible?
1.4.2 Software Safety testing include, at a minimum, the following?
a. GO-NO-GO path testing.
b. hardware and software input failure mode testing.
c. Boundary, out-of-bounds, and boundary crossing test conditions.
78
AMCOMR 385-17
d. Minimum and maximum input data rates in worst-case configurations to
determine the system's capabilities and responses to these conditions.
e. Input values of zero, zero crossing, and approaching zero from either direction or
similar values for trigonometric functions.
f. Complete regression testing for safety critical computing system functions in
which changes have been made.
g. Operator interface testing with the introduction of operator errors during safety
critical operations to verify safe system response to these errors.
h. Duration stress testing. The stress test time shall be continued for at least the
maximum expected operating time for the system. Testing shall be conducted
under simulated operational environments. Additional stress duration testing
should be conducted to identify potential critical functions (e.g., timing, data
senescence, resource exhaustion) that are adversely affected as a result of
operational duration. Software testing shall include throughput stress testing
(e.g., CPU, data bus, memory, input/output) under peak loading conditions
(System).
1.4.3 In addition to the test requirements listed above, are the following verification
activities performed for safety-critical software?
a. Every predicate term tested. Verification that every statement in the safety-critical
software code has a defined behavior for equivalent classes of inputs.
b. Code interface analysis. Evaluation of internal and external interfaces of safetycritical units to ensure compatibility across the interface.
c. Every assignment to memory tested. Testing to ensure that data items are
protected from being overwritten by unauthorized operations. Can also be shown
by analysis of the design.
d. Every reference to memory tested. Analysis to ensure that all calls for data from
memory lead to the correct storage location of the variable.
e. Every statement executed once.
f. All modules executed at least once.
79
AMCOMR 385-17
Appendix F
AMCOM Software System Safety Technical Review Panel
(SSSTRP) Charter
80
AMCOMR 385-17
AMCOM Software System Safety Technical Review Panel (SSSTRP) Charter
1.0 PURPOSE. Support AMCOM LCMC and AMCOM Safety Office on SwSS issues.
The SSSTRP will ensure that high quality, consistent SwSS practices are implemented
on all AMCOM programs that include safety-critical software.
2.0 AUTHORITY. The SSSTRP is constituted under the authority of the Commander,
LCMC.
3.0 OVERVIEW. The SSSTRP monitors and advises AMCOM managed SwSS
programs and provides guidance and suggested approaches to contractors on SwSS
issues and compliance with the overarching AMCOM SwSS Policy including:
a. Identification of SwSS program requirements.
b. Analysis and evaluation of the SwSS programs.
c. V&V of SCSF.
d. Elimination or control of software contributions to system level hazards.
e. Contribution to hazard residual risk of software.
4.0
ROLES AND RESPONSIBILITIES
a. Chief, AMCOM Safety Office. The Chief, AMCOM Safety Office, will support
the SSSTRP in the following areas:
(1) Charter the SSSTRP.
(2) Coordinate with Commander, LCMC and AMCOM PMs in support of the
SSSTRP.
(3) Appoint a representative, the AMCOM Safety Office SwSS PM, to Chair
the SSSTRP.
(4) Communicate SSSTRP SwSS hazards and concerns that may exist
between AMCOM programs.
(5) Elevate and forward risks that require acceptance above the PMs level to
the proper level of authority.
(6) Ensure adequate manpower and resources have been provided to both
manage and execute the SwSS program.
b. SSSTRP. The SSSTRP will be responsible to the Chief, AMCOM Safety and
individual AMCOM PMs for the following:
(1) Coordinate with the AMCOM PM’s Safety Managers on all SwSS issues.
(2) Assemble a board of technical Subject Matter Experts (SMEs) to provide
thorough reviews of SwSS programs and products.
(3) Review and make recommendations regarding the technical approach on
SwSS programs.
81
AMCOMR 385-17
(4) Respond to requests from the AMCOM PMs, AMCOM Safety Office
personnel, and contractors for recommendations on SwSS program
matters potentially influencing system safety.
(5) Provide consistent formal review of compliance of AMCOM SwSS
programs with the requirements of AMCOM SwSS Policy. Make written
findings and recommendations for corrective action to the PM, as
appropriate.
(6) Evaluate and monitor contractor SSPP and SwSS Program Plans, and
their implementation for compliance with AMCOM SwSS Policy and report
on areas of potential residual risk and risk to Materiel Release.
(7) Collect and evaluate lessons learned that pertain to SwSS programs.
(8) Provide endorsements to the AMCOM Safety Office SwSS PM to support
Materiel Release Review Board (MRRB) Software Safety Statements,
Safety and Health Data Sheet SwSS inputs, and Safety Certificates.
5.0
MAJOR PRODUCTS TO BE REVIEWED
The program under review shall coordinate with the SSSTRP Chairman on items to
include in the technical data package. The technical data package shall be submitted to
the SSSTRP Chairman no later than three weeks prior to the SSSTRP meeting. Items
that may be included in the technical data package include, but are not necessarily
limited to:
• The SSMP
• The SSPP
• The SwSSPP
• System description, system level and software safety-critical functions
• Requirements Database List of System and Software Safety Requirements
• SwSS Analyses
• Software Requirements Verification & Validation Plans
• Summary of Software Safety Requirements V&V Results
• Software Problem Reports, corrective actions, and regression test plans/results with
safety implications
• Software ECPs that impact safety
• SwSS Compliance Checklists
• PHA report
• Subsystem and System Hazard Analysis Report
• SAR
• Hazard Tracking System Reports
• Range Safety Data Package & SAR
• Operating and Support Hazard Analysis Report
• SSRAs
• Materiel Release Data
82
AMCOMR 385-17
6.0
SSSTRP MEMBERSHIP
a. Principal Members:
Organization
AMCOM Safety Office SwSS PM – SSSTRP Chair
AMCOM Safety Office System Safety PM
AMRDEC Software IV&V Representative
Applicable Program User/Warfighter Safety Representative
AMCOM Aviation Safety Division Representative (as applicable)
AMCOM Missiles Safety Division Representative (as applicable)
AMCOM Ground Systems Safety Division Representative (as applicable)
Other Government Agency (OGA) SwSS Representatives (as appropriate)
Navy Weapons System Safety Explosives Review Board Representative
Air Force Non-Nuclear Munitions Board Representative
(1) The SSSTRP Chair will be the AMCOM Safety Office SwSS PM.
(2) Voting members are the SSSTRP Chair, AMCOM Safety Office System
Safety PM, User/Warfighter Safety, AMRDEC Software IV&V, and the
OGA SwSS Representative(s), as appropriate. The SSSTRP Chair shall
be the final vote in the event of any tie. The Navy and Air Force
representatives are voting members on Programs with Joint Services
applications.
(3) Other members to be identified (Government and Industry) as required
with the objective of obtaining as much SwSS subject matter expertise as
feasible.
(4) The U.S. Army Safety Center will be invited to monitor the proceedings of
the SSSTRP.
7.0
GENERAL PROCEDURES
a. The SSSTRP shall meet quarterly, at a minimum, and at other times as
determined necessary by the SSSTRP Chair and the PMs. The SSSTRP shall
make every attempt to coordinate meetings to align with existing program
SSWGs or milestone reviews to minimize travel.
b. The SSSTRP Chair will establish the agenda not later than two (2) weeks prior
to the scheduled meeting, based upon the program(s) to be reviewed. Any
member of the SSSTRP may submit agenda items.
c. A summary of findings, recommendations, action items, action agencies, and
suspense dates will be prepared for each meeting. Formal minutes of each
meeting will be prepared and distributed by the SSSTRP Chair.
d. The SSSTRP does not have the authority to accept risks associated with
identified system hazards. All potential safety issues associated with program
software, identified by any source, will be considered by the SSSTRP. If the
SSSTRP determines that there is credible hazard risk associated with
software, the SSSTRP will recommend it be entered in the hazard tracking
83
AMCOMR 385-17
system and recommendations for elimination or mitigation will be provided to
the appropriate management level.
e. SSSTRP endorsements will include presenter’s and minority opinions, as
applicable.
f. Lessons learned on similar systems and previous presentations will be
reviewed to identify trends and to monitor and evaluate the corrective action(s)
taken.
g. This charter will be reviewed and updated as necessary.
h. The SSSTRP will function until disbanded by the Chief, AMCOM Safety Office.
84