Escolar Documentos
Profissional Documentos
Cultura Documentos
Regulation 385-17
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.
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
ii
AMCOMR 385-17
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
LIST OF TABLES
iii
AMCOMR 385-17
iv
AMCOMR 385-17
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
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
Armys 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 Armys 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.
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 systems 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 systems lifecycle; and for all configuration and mission variations, and for all
design and procedure changes.
3
AMCOMR 385-17
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.
4
AMCOMR 385-17
compliance with this regulation. The Government Program Safety Manager is the PMs
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
programs SSWG and is responsible for ensuring implementation and execution of the
SSWGs 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 contractors SSP and its
compliance with contractual requirements.
CONTRACTOR SYSTEM SAFETY MANAGER The Contractor SS Manager is the
Contractor PMs agent charged with the responsibility of ensuring the SSP defined in
the programs System Safety Program Plan (SSPP) is implemented. The Contractor SS
Manager is responsible for ensuring the programs compliance with the SSPP, SOW,
RFP, specifications and sub-contractors 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 programs 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
5
AMCOMR 385-17
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 safety-
critical 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
(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
9
AMCOMR 385-17
hazard mitigation measures (controls) into the design as early as practical. This pro-
activeness 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-to-
end traceability (from system assessment and hazard identification through verification
of safety controls) to satisfy software safety assurance requirements. The programs
implementation of the requirements in this regulation, to include evidence of traceability,
should be specified in the SSMP, the contractors 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
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
Figure 3 is provides a graphical depiction of the SwSS processes detailed in this Section.
1 System Concept 3 Software Design, Code and Implementation Phase
Refinement Phase -
Identify Execute the SwSS Program. Mitigate SW Hazard Causes
Perform detailed SS and SwSS analyses
Program Initiation/Safety Refine SCSFs.
Planning/System Assessment
Identify detailed hazard control measures
Assess the user needs, system
capabilities, etc. Specify safety requirements in SW requirements documentation
Develop safety management Determine verification methods for safety requirements (A, I, D, T)
documentation Track integration of SW control measures into the system level hazard
Assess system and SW analyses, system and SW requirements, and design documentation,
development structure and including requirements Tag and Hazard Links
processes. Determine Safety-criticality of SW and SW reqts.
ID resources reqd, SOW & RFP Assess Level of Rigor and verification requirements for Safety-critical SW
inputs Assess SW hazard controls as hazard risk reduction measures
Tailor the SS and SwSS programs
Integrate SwSS processes within the
SW development (SDP, SDD, SEP)
4 Software Test, Verification and Validation Phase
Initiate hazard analysis activities Iteration and
Monitor Test, Verification, and Validation
Feedback Ensure unit, system and integration test plans address SW safety Level of
Rigor.
2 Software Requirements Support development of safety specific test cases
and Architecture Monitor test and verification activities
Development Phase Review results of test and verification activities
Identify & Assess Ensure test failures related to safety are documented, corrective actions
identified and implemented, and regression testing performed
Identify System Hazards and SCSFs Update requirements tracking database and hazard tracking logs to reflect
Identify and track system level verified requirements
hazards
Identify SCSFs
Identify SW contributions to 5 Software Release Phase
identified system hazards
Identify, Tag in requirements Support Software Release/Assess Hazard Risk /Track Risks to
database, and Link to Hazards Acceptance
System Level Safety Requirements Monitor software release process
(HW & SW) Review system level hazards, controls and verifications
Identify, Tag and Link to Hazards Assess adequacy and independence of hazard controls
System Level Software Development Determination of formal final and/or residual risk
Safety Requirements Support development of SSRAs for residual risks
Support Configuration Control Monitor software issues and resolutions after fielding
Process
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.
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.
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 contractors 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
programs approved SSMP.
13
AMCOMR 385-17
14
AMCOMR 385-17
15
AMCOMR 385-17
16
AMCOMR 385-17
17
AMCOMR 385-17
(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.
SS and SwSS activities and artifacts during Software Requirements and Architecture
Development shall include the items identified in Table 2.
19
AMCOMR 385-17
20
AMCOMR 385-17
SS and SwSS activities and artifacts during Software Design, Coding, and
Implementation shall include the items identified in Table 3.
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.
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.
SS and SwSS activities and artifacts during Software V&V shall include the items
identified in Table 4.
23
AMCOMR 385-17
(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.
24
AMCOMR 385-17
SS and SwSS activities and artifacts in support of Software Release shall include the
items identified in Table 5.
25
AMCOMR 385-17
developers responsible for software post-software release shall ensure compliance with
the applicable requirements of this regulation.
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. Software-
induced 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.
27
AMCOMR 385-17
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.
The key, as discussed in the following sections, is delineation and implementation of the
verification levels specified in Table 7.
28
AMCOMR 385-17
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 systems 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 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 executed at least once.
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
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, Sim-
Over-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 Navys 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 AMCOMs 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 programs overall schedule and
milestones. SSSTRP endorsement will be critical to each programs milestone safety
entry/exit criteria and Materiel Release process. The AMCOM SSSTRP will support the
AMCOM Safety Office SwSS PMs development of Materiel Release Software Safety
Statements and software inputs to Safety and Health Data Sheets.
8. SUMMARY
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: ____________________________________________________ Date: _________________
Compliance
Verification
Yes/No/ Not Verification Compliance Evidence or
# Item Method
Applicable Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Verification
Yes/No/ Not Verification Compliance Evidence or
# Item Method
Applicable Mechanism/ Rationale/ Comments
(Y/ N/ NA)
10 Software change medium. When not implemented at the depot level or in
manufacturers 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.
34
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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 non-
critical functions, are the same safety design criteria applied to the non-
critical 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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Timing and Interrupt Functions
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Design and Coding
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
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 no-
operation 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?
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
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?
43
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Interfaces Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Computing System Hardware Requirements
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(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
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Human Machine Interfaces Software Design
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
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?
49
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Analysis and Testing
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
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?
51
AMCOMR 385-17
APPENDIX A
Software Development Requirements for System Safety
Safety-critical Software Maintenance
Software Item: ____________________________________________________
Program Phase: __________________________________________________
Completed by: ____________________________________________________ Date: _________________
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
A - Analysis Examples:
D - Demo. CM - Configuration Management
I - Inspection SDD - Software Design Document/Description
T - Test SDP - Software Development Plan
SQA - Software Quality Assurance
SRS - Software Requirements Specification
CCB Charter
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 manufacturers 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 manufacturers 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
AMCOMR 385-17
Compliance
Yes/No/ Not Verification Verification Compliance Evidence or
# Item
Applicable Method Mechanism/ Rationale/ Comments
(Y/ N/ NA)
"fingerprinting" of the version shall be used.
53
AMCOMR 385-17
Appendix B
AMCOM Safety Office Guidelines for the Use of Re-use, COTS, GFE
and NDI Software
54
AMCOMR 385-17
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. Re-
use, 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
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
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
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 Disadvantages
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
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 ad 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 Y
SC Function?
N
Perform COTS Correlate COTS
SSHA SSRs
Is COTS in Y
SR Function?
N N
COTS III/IV Y
Hazard?
Risk
Assessment
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 programs 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
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
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
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 R R R R
identified, captured in the specifications and trace to
specifications, hazard analyses, design and code
implementation
Analysis of requirements to determine safety criticality and R R R R
verification requirements based upon software functionality and
hazard analyses
Analysis of safety threads of software to ensure that all paths R R
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 R R R R
analysis and procedure. Computer based tools shall be used to
ensure coverage is as complete as possible.
GO-NO-GO path testing. Verification of anticipated behavior for R R R
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
Hardware and software input failure mode testing. Error case R R
testing performed to test the software handling of unexpected
values. Includes supporting analysis that determines plausible
errors to be considered for tests.
Boundary, out-of-bounds, and boundary crossing test R R
conditions. Black box testing to verify data is properly handled at
the boundaries of valid input ranges.
Input values of zero, zero crossing, and approaching zero from R
either direction or similar values for trigonometric functions.
Operator interface testing with the introduction of operator errors R R R
during safety critical operations to verify safe system response
to these errors.
70
AMCOMR 385-17
71
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 systems
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 programs 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.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 non-
developmental 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.8 Does the system safety program include the following and where is the evidence
captured?
74
AMCOMR 385-17
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?
75
AMCOMR 385-17
1.1.12 Which of the standard safety analyses are performed by System Safety and
where is the evidence documented?
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, Sim-
Over-Live, and Concurrent Test, Training and Operations?
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 programs formal process for final safety acceptance of the system
and software prior to testing, procurement decision, and fielding?
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?
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.3 Does SwSS perform the following activities in support of the overall safety effort?
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?
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?
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 programs safety verification meet the following minimum software
formal test coverage requirements?
78
AMCOMR 385-17
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 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 executed at least once.
79
AMCOMR 385-17
Appendix F
AMCOM Software System Safety Technical Review Panel
(SSSTRP) Charter
80
AMCOMR 385-17
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 PMs 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
(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
84