DEF-STAN

Although many standards exist for cleaning treatments for metal surfaces, for example Defence Standard DEF STAN 03-2/1, these are often fairly general guides which in some cases may be regarded as somewhat outdated due to recent advances in treatment technology and changes in industrial practice. 

Acid pickles Some of the acid pickles used to clean and etch aluminium alloy surfaces and remove oxide and anodic films, such as the chromic/ sulphuric acid pickle (method O of DEF STAN 03-2) and other chromic-acid bearing pickles (App. Foi DEF-151) probably leave on the surface traces of absorbed or combined chromate which will give at least some protection against mild atmospheres. 

Pastes can be made with the same carrier liquids by simply increasing the concentration of powder to achieve a paste-like semi-solid consistency. More stable pastes are obtained by using a carrier which is inherently semi-solid, such as a grease, petrolatum (soft petroleum wax) or a semi-fluid polymer. The concentration of powder in a paste or a dispersion may be anything between 35 and 75%, depending on the application. The British military specification Def Stan 80-81/1 requires not less than 50% of molybdenum disulphide in a mineral oil grease for an anti-seize and anti-scuffing compound for use up to 250 C. This is probably a fairly typical level for anti-seize use. 

The most widely used turbine lubricants, by far, are the 5 cSt grades covered by US Navy specification MIL-PRF-23699 [11] and UK MoD specification Def Stan 91-101 [12]. The lubricants approved to the Def Stan happen to be a subset of those approved to the MIL specification that have passed the additional requirements for operation in the UK military engines. 

The standard of the British Defense Ministry DEF STAN 91-91/ Editions 2 (DERD 2494) from May, 1996... 

The accident- or risk-based approach (Krilzinger (2006), Chapter 4) found in standards such as MlL-STD-882 or Def Stan 00-56, or... 

The risk/accident-based criteria (e.g. from Def Stan 00-56 or MIL-STD-882) considers the severity of various types of accidents and cannot directly allocate a severity to a failure mode which, for instance, leads to a significant increase in crew workload or conditions that impair crew efficiency . For more information, see Kritzinger (2006), Chapters 4 and 5. 

Sourced from Draft lEC 300-3-8 (Dependability Management), DEF STAN 00-56 Iss 2 Part 2 Table 4 and ACJ25.1309. This guidance was subsequently removed in DEF STAN 00-56 Iss3 and AMC25.1309. Examples obtained from Qemens, P.L. Human Factors and Operator Errors, J.E. Jacobs presentation second edition, Feb 2002. Human error probabilities are also contained in WASH-1400 (NUREG-75/014) Reactor Safety Study—An Assessment of Accident Risks in U.S. Commercial Nuclear Power Plants, 1975. 

Matters are therefore complicated when the two regulatory regimes are mixed, which is the case in military standards such as MIL-STD 882 and DEF-STAN-0056 (it can be argued that the perspective from which these standards were initiated was influenced by the military being both the operator and the regulator). 

The British Def-Stan 00-56 Safety Management Requirements for Defence Systems... 

The British Def-Stan 00-55 Requirements for Safety Related Software in Defence Equipment... 

Static Code Analysis (SCA) has a proven track record as a powerful software verification technique providing the necessary rigour for safety-related software. A number of mature tools supporting SCA are available. However, static analysis also has a reputation as being costly and labour-intensive. This paper looks at recent advances in identifying objectives and processes for SCA and assesses the potential for such analyses to provide, in conjunction with new software safety standards such as the CAA s SWOl and Ministry of Defence s DEF STAN 00-56 Issue 3, a cost-effective and focussed method of gathering evidence that software performs safely. 

SHOLIS (Chapman, 2000) is a software-based system that advises ship s crew on the safety of helicopter operations under various scenarios. The software was developed in accordance with DEF STAN 00-55 (Issue 2). A software hazard analysis was performed and on this basis certain parts of the software were designated as safety-critical. Safety critical software was formally specified using Z, developed in Spark Ada, and a partial correctness performed of the code against the specification. Information Flow analysis was used to demonstrate functional separation of critical and non-critical software. Freedom from run-time exceptions was demonstrated for all code. Static analysis of I/O usage, memory and timing was used to show separation of non-functional properties. Finally, proof that the system s top-level safety properties were maintained by the software was carried out. 

The tables given in EEC 61508 and the SIL Tailoring tables given in DEF STAN 00-55 link certain software techniques to SIL levels. However, there is little or no plausible evidence that the techniques mandated or recommended produce software of the reliability required by the SIL failure rate. 

Both lEC 61508 and DEF STAN 00-55 mandate software development processes, with the implication that following the prescribed development process is essential to developing software of the required integrity. The use of Commercial off-the-shelf (COTS) software is increasingly prevalent in safety-related systems. However, the approaches prescribed by lEC 61508 and DEF STAN 00-55 cannot be used for COTS software, for which the system developer has little or no control over the development processes adopted. Furthermore, source code may not be available for COTS software, and hence many of the verification techniques recommended cannot be used. 

Much of the thinking behind lEC 61508 and DEF STAN 00-55 seems to be targeted at real-time, embedded software. Modem safety-related software can be an application mnning on a standard desktop operating system, it can be previously developed software re-used in a new application, it can be part of a complex system-of-systems Demonstrating the safety of these types of system introduces new issues, which 61508 and 00-55 do not address. 

RTCA D0178-B/EUR0CAE ED12-B, and Def Stan 00-55, when used in conjunction with this document may provide an effective way to produce timely and technically valid evidence to satisfy these assurance objectives. ... 

In addition to SWOl, the new draft of DEF STAN 00-56 uses an evidential approach. The software part of this standard is planned to be issued in 2004. 

With such a project, the safety concerns are obvious, and therefore a convincing and thorough Safety Case is paramount. Def Stan 00-56 (Ministry of Defence 1996) Part 2 encourages the concept of an evolving Safety Case in order to [initiate the Safety Case] at the earliest possible stage...so that hazards are... 

Figure 10 - Satisfaction of SMS requirements from Def Stan 00-56 chapter 5...

A Def Stan 00-56 safety ease is therefore eonstruetive, starting from safety requirements, proceeding via argument and evidence and culminating in the conclusion that the system is safe (for the applieation, ete.). 

This view of a safety ease does not refleet the seientifie approaeh of hypothesis and ehallenge with the system is safe always being open to ehallenge. It tends to support a view in whieh safety is proven onee and for all. Nevertheless, there is a hint of the seientifie approach in the guidanee to Def Stan 00-56 (MoD... 

Another fiction relating to SoS safety cases is that the adoption of Def Stan 00-56 Issue 4 will make it difficult to construct a safety case because the onus is on the designers to argue that the right evidence has been produced in support of the safety case. However, the fact is that Def Stan 00-56 Issue 4, being a goal-based rather than a prescriptive standard, allows potentially greater flexibility in the types of evidence that can be presented in order to support the safety case and demonstrate that the system of systems is acceptably safe. Therefore the outputs of novel safety analysis techniques can be used as evidence to support the SoS safety case. 

In general today s established system safety standards tend to be focused on development activities, or maintenanee of particular products or specific items. Typical safety standards in widespread use such as lEC 61508 (lEC 2010), Def Stan 00-56 (MoD 2007a) and DO-178B (RTCA 1992) generally cover service only in terms of maintenance or evolution of a system originally developed to the standard. 

The latest MoD Def Stan 00-56 issue 4 does mention service aspects including change control, analysis of failures and maintenance of the safety case (and balancing of operational imperatives against safety risk), but not in the context of running a large seale, ongoing mixed IT service. 

MoD (2007a) DEF STAN 00-56 Safety management requirements for defence systems, issue 4. Ministry of Defence... 

Hazard analysis aetivities have been performed for some time by the Trust. The added value of reeent improvements has been to provide a formal framework and associated methods into which they fit as a major component. The analyses were founded on traditional risk management techniques. These have been reviewed and developed, resulting in a similar format for the records produced. Improvements have been made by using a team rather than an individual for carrying out the analysis. The use of a set of guide words has helped to enable a consistent approach to the examination of design representations of the system under review. The technique was heavily based on the HAZOP method advocated in Def Stan 00-58 (MoD 1986) in this, it evolved into a similar form to that promoted as SHARD (Pumfrey 1999). 

ISB (2009a) DSCN 14/2009 Application of patient safety risk management to the manufacture of health software. Information Standards Board for Health and Social Care ISB (2009b) DSCN 18/2009 Application of patient safety risk management to the deployment and use of health software. Information Standards Board for Health and Social Care MoD (1986) Def Stan 00-58 HAZOP studies on systems containing programmable electronics (withdrawn). Ministry of Defence... 

There has been much discussion on the apphcation of HAZOPs to computer-controlled systems (computer HAZOPs or CHAZOPs) 43 particular, defence standard DEF STAN 00-56 calls for HAZOPs in relation to both systems and sub-systems, but the only guide it was able to refer to originally was that for chemical process plant. This omission has now been remedied by the formulation and pubhcation of interim defence standard DEF STAN 00-58 Hazop studies on systems containing programmable electronics. ... 

---