MIL-STD-882

This Military Standard, especially MIL-STD-882C, has been a guiding light in system safety within not only the defense sector but also in the areas of:

• avionics,
• rail transportation, and
• medical devices.

Despite its widespread and extensive use, much confusion remains.

There are many people who are confused about the differences between accidents and hazards, between PHL and PHA, etc.

Very poor safety products are still being produced such as SSPP, O&SHA, SSHA, etc.

Occasionally, one person has become the definitive source of information on system safety within an company but their approach has been flawed.

This has been made evident to us during our consulting and training efforts.

By the way, if you are interested in acquiring excellent system safety DID's click here.

MIL-STD-882 evolved as follows:

• AF BSD Exhibit 62-41
• MIL-S-38130
• MIL-S-381308A
• MIL-STD-882A
• MIL-STD-882B
• MIL-STD-882B Notice 1
• MIL-STD-882C
• MIL-STD-882C Notice 1
• MIL-STD-882D (we call it "D"uh)
• MIL-STD-882E (last draft produced December 2005)

A particularly useful combination is MIL-STD-882C Notice 1 sandwiched to the 300 series software tasks from MIL-STD-882B Notice 1.

The MIL-STD-882B 300 series tasks include:

• Task 301 - Software Requirements Hazard Analysis
• Task 302 - Top-Level Design Hazard Analysis
• Task 303 - Detailed Design Hazard Analysis
• Task 304 - Code-Level Software Hazard Analysis
• Task 305 - Software Safety Testing
• Task 306 - Software/User Interface Analysis
• Task 307 - Software Change Hazard Analysis

MIL-STD-882C defines Software Control Categories as follows:

• I - Software exercises autonomous control over potentially hazardous hardware systems, subsystems or components without the possibility of intervention to preclude the occurrence of the hazard. Failure of the software or a failure to prevent an event leads directly to a hazard's occurrence.
• IIa - Software exercises control over potentially hazardous hardware systems, subsystems or components allowing time for intervention by independent safety systems to mitigate the hazard. However, these systems by themselves are not considered adequate.
• IIb - Software item displays information requiring immediate operator action to mitigate a hazard. Software failures will allow or fail to prevent the hazard's occurrence.
• IIIa - Software item issues commands over potentially hazardous hardware systems, subsystems or components requiring human action to complete the control function. There are several, redundant, independent safety measures for each hazardous event.
• IIIb - Software generates information of a safety-critical nature used to make safety-critical decisions. There are several, redundant, independent safety measures for each hazardous event.
• IV - Software does not control safety-critical hardware systems, subsystems or components and does not provide safety-critical information.

These Software Control Categories are similar in concept, although not equivalent to:

• Software Development Assurance Levels (defined by SAE ARP4761 and utilized by RTCA DO-178B), and
• Software Integrity Levels (defined by IEC 15026 and utilized by IEC 61508).

So, once you have introduced Software Control Categories, what software guidelines do you follow? Are you sure?