ADMP-01 guidance for developing dependability requirements

What it is

ADMP-01, an Allied Dependability Management Publication, is NATO guidance for the person writing or reviewing the dependability section of a defence acquisition specification. It hands over no template: the document says plainly: "It is not intended that this document will provide a template from which all new requirements can simply be selected, nor can it give a step by step guide to cover every eventuality." Instead it works through the concepts a requirement-writer needs first, then the seven characteristics that make up dependability: availability, reliability, maintainability, testability, maintenance, safety and software.

Nations record their recommendation to use ADMP-01 through STANREC 4174, a recommendation rather than a ratified commitment, so no nation is treaty-bound to apply it. The current edition, Edition C, Version 1, was promulgated in June 2025 and superseded Edition B, Version 1. The document defines "item" broadly, "systems, equipment, be it hardware or software based, and services", so it is not written for one product type.

It addresses the customer side of a programme: "It should be used by all members of projects and in service organisations including the various NATO agencies who are responsible for dependability." It does not speak to suppliers directly, but a supplier ends up carrying the obligation it produces: once a requirement is set: "The supplier will need to provide evidence to substantiate that the requirement has been met, or where it cannot be met, evidence in support of the request for a relaxation."

The concepts before the numbers

Before any dependability figure is set, ADMP-01 asks for several things to be worked out first. A Life Profile: how long the item must be operational, on standby, or switched off, how often a mission repeats, and what maintenance it will need and where. A Boundary: what counts as part of the item versus an external stimulus, power, data, other equipment, assumed to be present, since a poorly-drawn boundary leads to disputes over whether a failure is attributable to the item, particularly where payment depends on the answer. Environmental limits for temperature, humidity, salinity and dust, for normal operation and for survival. And a definition of failure agreed before reliability is specified at all, because "Setting clear and agreed definitions of failure is an important step that is often overlooked." Early on, failure is defined functionally (a mission essential function list, typically Move, Fight, Communicate, Protect); as the design firms up, it is refined to the responsible hardware or software component.

The document is also explicit about the difference between a requirement, essential, evidenced, or formally relaxed only with agreement from all stakeholders, and a target or goal, which is nice to have and gets traded away first when costs rise. Overspecifying is treated as a real risk, not a safety margin: "Setting requirements for 98% reliability or 99% probability of surviving a 48-hour mission is likely to drive up costs significantly" for a level of assurance that may add little real operational value.

Proving a dependability requirement has been met

Dependability is rarely provable with one test, and ADMP-01 shows why with real numbers. Run an item for 1,000 hours with 10 relevant failures, and the chi-squared method shows "a Mean Time Between Failures (MTBF) of 94 hours has been achieved to a 50% level of confidence, an MTBF of 80 hours has been achieved to a 70% level of confidence and an MTBF of 65 hours to a 90% level of confidence." A sharper example: 99% reliability at 80% confidence on 50 single-use items needs 161 failure-free tests to prove, over three times the batch being bought, and the document calls the requirement itself "unacceptable", not the test method. The evidence assembled is normally an assurance case, not a folder of test reports: "a vehicle to allow reasoned and auditable claims and arguments to be made about the dependability of the item."

The seven dependability characteristics

Availability is uptime over total time, but the document splits inherent availability (ideal conditions, the figure most contracts use) from operational availability (real logistic delay included, "more difficult to measure and thus gain a figure that is agreeable to everyone"). A single annual percentage is not enough: a 99% target still permits 87.6 hours of downtime a year, and one 48-hour outage meets that figure very differently to 1.5 hours a week.

Reliability distinguishes Mission Reliability, failures that stop the mission, from Basic Reliability, every failure. Usually specified as a mean (MTBF/MTTF) or a probability of success, and a mean is not a floor: specifying "a 200-hour MTBF to support an operating requirement of 200 hours will result in failure" for a meaningful share of the fleet.

Maintainability separates Active Repair Time (the physical fix) from Time To Repair (which adds the logistic delay of getting parts, tools and a trained person to the job), and normally combines a mean (MTTR/MART) with a percentage point, commonly that 90% or 95% of repairs finish inside a stated time.

Testability covers how well an item reports its own failures through Built-In-Test, via metrics such as test coverage (weighted by failure rate), fault detection rate, fault isolation rate and false alarm rate, illustrated with figures such as "92% of all possible fault conditions shall be identified by the built in test routines. Additionally 100% of the fault conditions that could cause safety and mission critical failures shall be identified."

Maintenance splits into corrective, which a specification has little control over since it happens whenever a fault occurs, and preventive, whose frequency and duration can be bounded directly, for example "Preventive maintenance shall not exceed 2 hours per week."

Safety and dependability can pull against each other: monitoring or recording equipment added for safety can itself reduce reliability, and up-armouring a vehicle to protect its crew "taken the all up mass of the vehicles over the original design intent which has had adverse effects on reliability of the under carriage, suspension, braking systems and power output."

Software fails with little advance warning but recovers faster, often with a reboot. ADMP-01 recommends setting requirements at the item level, hardware and software together, provided failure definitions capture software-induced failures specifically.

What it leans on, and what it does not decide

ADMP-01 does not assume a management system like ISO 9001 already exists. It does lean on a companion document for the mechanics of defining failure: the functional analysis and failure classification process it needs "are described in a dedicated ADMP (ADMP-03)." Its normative references also point to ADMP-02 for managing dependability once an item is in service, ADMP-04 for what the customer's own dependability expert does with the resulting requirements, AAP-20 and AAP-48 for the surrounding NATO life-cycle framework, and the IEC 60300 dependability-management series, IEC 60706, IEC 61124 and ISO/IEC 25000/25010 for the underlying engineering methods.

What it does not do is decide a figure for you, tell a supplier which requirements apply to their programme, or describe any way to be certified against it. There is no accreditation body, no NATO scheme, and no organisation that can be "ADMP-01 certified": the document is guidance for a specification, and it says so of itself: "The purpose of this document is to provide guidance on developing dependability requirements."

Standards it references

• ADMP-03Background
• ADMP-02Background
• ADMP-04Background
• AAP-20Background
• AAP-48Background