AOP-52 software safety design and assessment for munitions

What it is

AOP-52 is the NATO Allied Publication that guides the software safety design and assessment of munition-related computing systems: software that performs a safety-related function in an ammunition or weapon system. It runs a Software Systems Safety process from program planning through to the Safety Assessment Report that supports a system's introduction into service, and primary responsibility for running it "lies with the system safety manager/ engineer in both the supplier and acquirer's organizations", with the Program Manager expected to "support the integrated safety process between systems engineering, software engineering, and safety engineering in the design, development, test, and operation of the system software." AOP-52 is explicit about its own standing: it "is a guideline and is not intended to supersede any National Government or Agency policy, standard, or guidance pertaining to system safety (e.g., US MIL-STD-882 series, UK Def-Stan 00-56)." This is Edition B, Version 1, dated November 2016, superseding AOP-52 Edition 1.

Planning, and the people involved

The document assumes a safety planning capability is already, or is being, put in place: a Software Safety Program Plan that fixes program interfaces, contract deliverables and responsibilities before the hazard analyses begin, reviewed under configuration control once a baseline is set. The Software Configuration Control Board that approves later changes must include a system safety engineering member, and suppliers whose software carries safety-related functions should run a Software Quality Assurance program under an approved plan. AOP-52's own Generic Software Safety Requirements are tailored to a specific system as a joint Acquirer/Supplier activity, documented and signed by both parties' management, and verified by Inspection, Analysis, Demonstration or Test. The document works alongside AOP-15's own System Safety process rather than replacing it: "it is not the intent of these charts to supplant the content of AOP-15: the system-level process both provides the basis for the Software Systems Safety Process and shows the inherent cohesiveness of the Software Systems Safety Process with the System Safety Process."

The hazard analyses that build the evidence

A Preliminary Hazard List identifies candidate hazards before software-specific causal factors can be pinned down. A Preliminary Hazard Analysis follows, feeding early design trade-off studies, and preliminary and detailed Software Design/Subsystem Hazard Analysis track the design as it matures from concept through code. A System Hazard Analysis begins once the Preliminary Hazard Analysis is approved and requirements are allocated to software functions, and is updated at "each software milestone review (Software Requirements Review, Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review, Initial Operating Commencement (IOC), Low Rate of Production Decision, and Initial Operating Capability)", staying open until the final software version is delivered. The document is specific about the one deadline that matters most for design work: "the safety design requirements (hardware, software, and human interfaces) must be complete prior to the milestone at which Software Engineering freezes the requirements (e.g., Critical Design Review)."

Scaling the effort to the risk

A Software Control Category describes how much autonomous control the software has over a hazard. At the most severe end, "software exercises autonomous control over potentially hazardous hardware systems, subsystems, or components without the possibility of intervention to preclude the occurrence of a hazard." That category, crossed against the severity of the mishap the software could cause, sets a Software Safety Criticality Index, which in turn drives a Level of Rigor matrix for design, code, test and integration work: the highest tier calls for safety verification through requirements analysis, design analysis, code analysis and dedicated safety testing, with progressively lighter tiers below it down to high-level safety testing alone. The same index sets how much independent verification and validation a given system needs.

Generic software safety design requirements

Chapter 4 is the document's longest section: itemised "shall" rules addressed to the system and software designer, covering system design, the computing environment, self-check design, safety-related events and functions, interface and human-interface design, critical timing and interrupts, choice of language, coding standards, software maintenance, and software analysis and testing. Two rules recur as the document's clearest examples: "at least two people shall be thoroughly familiar with the design, code, testing, and operation of each software module in the system", and "the use of patches to 'fix' a problem may be acceptable in general software development, but must not be tolerated in the development of safety related software." Annex D works through the same ground clause by clause: a coding standard "should define rules that lead to clear, unambiguous source code that is easy to review, test and maintain, amenable to static analysis", and "to be effective, a coding standard must be enforced", ideally by a tool. High-level languages are expected except for very small units of logic, and "for higher integrity systems (e.g. safety critical software), specific object code verification will be necessary" alongside compiler assurance methods such as validation, "an internationally agreed black box method of testing compilers, designed to demonstrate that a compiler conforms to the appropriate international language standard" - though the document is clear that a validation certificate alone does not guarantee a compiler will always produce a correct result. Choosing any tool used to support this work is the developer's own responsibility, in a stated order of preference: a tool of the required assurance level first, a combination of tools next, then a tool combined with manual activity, and only when no suitable tool exists, the process performed entirely by hand.

Previously developed, COTS and reused software gets its own chapter, because reuse does not carry its assurance with it: strategy, safety analysis, in-service history, version control, process visibility, upgrades, wrappers and middleware, reverse engineering, additional verification and validation, and eliminating operating-system functionality the application does not need.

Testing and the Safety Assessment Report

Development-phase testing runs at unit, subsystem/CSCI and system level, each performed by someone other than the writer of that code, and culminates in Functional Qualification Testing and Independent Verification and Validation, "a requirements-based test program run by a group independent of the organization that developed the software", together with formal Test Coverage Analysis of both requirements and code structure.

A Safety Assessment Report, or Safety Case, is the document's central evidentiary artefact: "a structured argument, supported by a body of evidence, that provides a compelling, comprehensive and validated assessment that a system is safe for a given application in a given environment." Its contents are expected to demonstrate compliance with applicable legislation, regulation, standards and policy; an effective safety management system; competent staff; valid and traceable safety requirements; satisfied or adequately mitigated requirements; tolerable residual failures; and that "safety claims, safety arguments and evidence have been subjected to independent scrutiny." A Requirements Traceability Matrix traces every software safety requirement from specification through design to its test result, and the whole process is laid out in Annex F as a named sequence of phases, from System Definition and Safety Planning through Certification and into Sustained Engineering once the system is fielded.

How you are evaluated

AOP-52 creates no certification an organisation can hold, and says so about the obvious alternatives directly: "having third party certification (e.g. CMM, CMMI, DO-178B, ISO 9001) alone does not guarantee that safety concerns will be properly addressed." What it describes instead is closer to government surveillance of a specific programme than to accreditation of a company: a Safety Review Authority and certification authorities weigh the evidence in the Safety Assessment Report, concur with the software design at Critical Design Review, and later concur, or assign action items, on a recommendation before the system's software is introduced into service. That is a decision about the software item in front of them, not a scheme a supplier's organisation is assessed against once and carries forward, and passing an AOP-52 review does not make a supplier "AOP-52 certified."

Standards it references

• STANAG 4452 - the Standardization Agreement recording NATO nations' agreement to use AOP-52; the cover that gives it force.
• AOP-15 - the companion Allied Publication on the assessment of safety and suitability for service of non-nuclear munitions, whose Software Hazards Analysis step AOP-52 exists to satisfy.
• ISO 9001 - named as an example of third-party process certification that, on its own, does not guarantee that safety concerns are addressed.
• IEC 61508 - Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, listed in the document's own bibliography rather than invoked as a binding requirement.

NATO's Standardization Document Database is the authoritative source for AOP-52. NATO's documents are free of charge; we credit NATO for the catalogue and neither sell nor host a copy ourselves.

Standards it references

• AOP-15Background
• ISO 9001Background
• IEC 61508Background