A New Concept in Defence Safety Standards: The Revised UK Defence Standard Viv Hamilton

Transcription

1 A New Concept in Defence Safety Standards: The Revised UK Defence Standard Viv Hamilton Viv Hamilton Associates Ltd New Parkside, Braintree Rd, Wethersfield, Essex CM7 4AD United Kingdom Abstract In January 2005 the UK Ministry of Defence released Issue 3 of Defence Standard (MOD 2004). This standard provides a comprehensive structure for safety management and for engineering safety into defence equipment and services. The standard moves away from mandating specific processes and instead takes a goalbased approach that requires suppliers to justify their systems by means of safety cases containing explicit arguments based on compelling evidence. This approach provides greater flexibility, especially for systems using COTS components. It is likely that the introduction of the new standard will pose challenges, as both suppliers and procurers develop new skills in developing and justifying safety claims. In this paper, the background to the revision is explained, including the challenge in producing a goal-based software standard. The structure of the standard is described and contrasting examples of potentially compliant approaches are provided. The consultation that has taken place with industry and the key challenges for both suppliers and procurers are explained.. Keywords: Defence Standards, goal-based. 1 Introduction Defence Standard Issue 3 (MOD 2004) provides a comprehensive structure for safety management and for engineering safety into defence equipment and services. The standard moves away from mandating specific processes and instead takes a goal based approach that requires suppliers to justify their systems by means of safety cases containing explicit arguments based on compelling evidence. This paper explains the background to the revision and the structure of the standard and provides contrasting examples of potentially compliant approaches. Finally, the consultation that has taken place with industry is discussed and the key challenges for both suppliers and procurers explained. Copyright 2005, Australian Computer Society, Inc. This paper appeared at the ACS Workshop on Tools and Standards Sydney. Conferences in Research and Practice in Information Technology, Vol. No, 55, Tony Cant Ed. Reproduction for academic, not-for profit purposes permitted provided this text is included. 2 The Rationale for Defence Standards in the UK In the UK, the Ministry of Defence (MOD) is, in most cases, its own safety regulator and it achieves this by setting safety policies and establishing safety offices and safety management systems that are independent of individual project structures. The responsibilities of the MoD project managers who manage defence contracts (MoD Duty Holders) are defined by Joint Service Publications (JSPs), and there are JSPs for the safety of each of Land, Sea and Air, as well as for Health and Safety in general. Defence Standards are published where it is perceived (by MoD) that its needs are not met by other (civilian) standards. Defence Standards apply to suppliers rather than to the MoD Duty Holder, although in some cases, responsibilities that would otherwise be carried out by defence contractors are brought in-house to MoD, in which case compliance with the relevant Defence Standards would be expected. Clearly there are many areas of Defence Standards where there are no civilian standards (such as for weapons systems). Defence Standards can also be required where applications for defence use are more onerous than equivalent civilian uses. In the safety arena, MoD as a system procurer has to be seen to discharge its responsibilities for safety, by ensuring that the systems it procures and operates are sufficiently safe. There is, of course, a cost for the MoD in publishing and maintaining standards, so there is an incentive to have only as many standards as are strictly necessary. In recent years, MoD s procurement philosophy has moved towards adopting existing solutions from civil applications, where these fulfil the needs of military applications. This is often summarised in the phrase: as civil as possible, as military as necessary This principle is used when considering the Defence Standards to ensure that obsolete and unnecessary standards are withdrawn. 3 A Brief History of the 00-5x Defence Standards In the early 1980s, government, academia and industry experts were concerned that software was beginning to be used in safety critical applications. This was of particular concern for the MoD, because the need for equipment that could outperform that of potential enemies meant that systems particularly weapons systems and fighting

2 platforms such as aircraft - needed the flexibility and intelligence of software. It was agreed that a defence standard was needed for the development of safety critical software, which would eventually be published as Defence Standard However, it was also realised that a standard for the development of software would not solve the problem on its own. A standard was also needed to control the process of hazard identification and risk reduction that would determine when Defence Standard would apply. Thus Defence Standard was born. The two standards have been revised in parallel ever since. Draft versions of the two standards were issued in 1986, but both were controversial and it was not until 1989 that they were eventually issued as Interim standards. In Interim Defence Standard the hazard log formed the key repository for managing and communicating safety related risks, and there was a complicated Safety Integrity Level scheme, based on consequence, probability and mitigation that dictated whether the software needed to be of the highest integrity level (SIL 4) and hence whether or not Defence Standard applied. Interim Defence Standard drew on the experiences of a handful of safety critical projects, where formal methods, including mathematical proof of correctness had been used to develop software that was as near error free as human effort could achieve. However, the standard went beyond the practical experience of the industrial projects, where a formal specification had been produced, but code had generally been constructed by conventional approaches and then proved to be conformant with the specification by static analysis. There was an expectation at the time that formal methods would soon be in widespread use for software development, with inevitable improvements in tool support, so the interim standard drew on academic experiences and mandated full formal refinement. From the first therefore, Interim Defence Standard was controversial and there were few, if any projects, that could claim full compliance with every clause. Work began on revising the two standards in The key philosophical change was that both standards required the production of a safety case, which brought together the documentation generated from compliance with the standard. Defence Standard still defined Safety Integrity Levels and used a hazard log as the repository of information about hazard identification, assessment and mitigation. The scope of Issue 2 of Defence Standard (MOD 1997) was broadened to all safety related software, with an annex giving guidance on how to tailor the standard for different integrity levels. For the highest integrity levels Defence Standard still mandated formal methods, but more pragmatically in that it allowed for static analysis or retrospective proof of correctness of software that had been developed using more conventional approaches. In addition, it was influenced by other software standards, so that it had a more balanced approach in mandating (and giving guidance on) other aspects of software development, including software management and testing. In recognition of the fact that the material in the two standards was now felt to be relatively mature, both standards were published as full defence standards which meant that all contracts to which they were relevant, should be compliant. There were, however, still problems in their application. Some projects sought to avoid the (perceived) burden of complying with Defence Standard issue 2, by implementing the functionality in custom hardware instead of programmable software. Interim Defence Standard 00-54, dealing with the development of safety related hardware, was published in 1999 to fill this gap. In general Issue 2 of Defence Standard and were successfully used, provided they were being applied to new developments. The practical reality, however, is that few projects begin technology development from scratch. Defence Standard particularly was seen as impossible to apply to Commercial Off-The Shelf (COTS) elements and there were widespread concerns that the standards were a barrier to UK suppliers of defence equipment, because the UK MoD sometimes purchased existing products that were in service with the armed forces of other nations and that were not compliant with these standards. The mandate given in 2002 for the authors of Issue 3 of Defence Standard was that the revised standard had to provide an over-arching approach to the design of safe systems, so that safety was considered at the beginning of the project and influenced all stages of system development. It had also been decided that a goal-based approach would provide a realistic means of defining a standard that could apply regardless of development route, and which would also be more technology independent. There are few standards dealing with software that take this approach and therefore there is little experience of drafting, or of complying with goalbased software standards. A recent example of a goalbased software standard is SW01: Regulatory Objectives for Software Safety Assurance in ATS Equipment (CAA 2002). This standard was developed by the UK s Civil Aviation Authority and is concerned with Air Traffic Systems (ATS). Its introduction was controversial because of disagreements between the regulator and the operators and suppliers of ATS equipment about the impact of the standard. Since its introduction, there has been a significant learning-curve for all parties on how to achieve, and how to interpret, compliance with SW01. Issue 3 of Defence Standard was able to learn from the experience of introducing and interpreting SW01. Issue 3 of Defence Standard was released in January Its release meant that Defence Standard was withdrawn and Defence Standard became obsolescent (although it is still available on the Defence Standards website and may be used as guidance for developing high integrity software). 4 Defence Standard Issue 3 Scope and Applicability The problem with writing defence standards is the sheer breadth of applicability. Issue 2 of Defence Standard applied to electronic systems. The scope of Issue 3

3 was broadened to include all defence systems. The application can be on any scale from sub-system to systems of systems and in any domain, including combinations of land, sea and air and including the additional risks of weapons and nuclear applications. From the equipment carried in the field by an individual soldier, to a fighting platform, such as ship or aircraft, Defence Standard has to be applied. The scope of previous issues of the standard had been limited to equipment purchased by MoD, but with more diverse contracting models now being favoured by the UK government, the scope of the standard was widened to include systems used to deliver safety related services to MoD. In order to encompass this broad scope, the standard focuses on the principles of safety management and safety engineering and the normative clauses (Part 1) are technology independent. 4.1 The Goal Based Approach Defence Standard adopts a goal-based approach. The intention is that the standard mandates only what must be achieved for a demonstrably safe system: how this is achieved, in terms of technology, documentation and development approach is unconstrained. Previous issues of Defence Standard (and especially of Defence Standard and 00-55) were prescriptive of development approach. Freedom from such constraints is achieved firstly by mandating a comprehensive safety management approach and secondly by mandating that the safety case contain an explicit safety argument, supported by compelling evidence that the system is safe to deploy. The benefits of removing prescription will be readily evident. It leaves the supplier free to choose the most appropriate solution and potentially enables suitable COTS systems or systems developed to other standards, to be considered. The intention is to ensure that solutions that are safe are not ruled out simply because of the need to comply with a standard, and that the supplier is not forced to waste effort on compliance, where this effort does not contribute to safety. The goal-based approach means that one way of complying with the standard (for electronic systems) would be to use the approach previously mandated by Issue 2 of Defence Standard and by Defence Standard for software. On the negative side, prescriptive standards remove ambiguity from the development planning stages. A goal-based standard requires the supplier to have a comprehensive understanding of potential solutions and the ability to evaluate the possible arguments and evidence available to support each option, and the strength and acceptability of these arguments. To a certain extent therefore, a goal-based standard can create a barrier to new entrants to the defence market, in favour of suppliers with experience and mature approaches to safety assurance. 4.2 Interim Status Issue 3 has been published as an Interim Standard. The Interim status reflects the fact that MoD recognises that there is a significant broadening of scope between issue 2 and issue 3 and that the goal based approach is philosophically different from the more prescriptive approach of issue 2. By publishing the standard as an Interim issue, it signals the expectation that the standard may well need to be revised in three to five years, and indicates that feedback on its application will be welcome. Had it been published as a full defence standard, it would automatically have applied, with its wider scope, to contracts where issue 2 was in force for electronic systems. As an interim standard, there is scope for MoD procurement to decide that there are contracts for which, for some reason, it should not be applied. Suppliers who are already applying issue 2 also have the choice to continue with issue 2. However, where it is called up in a contract is placed after publication of issue 3, it is expected that the supplier will comply in full. 5 The Structure of the Standard The standard consists of two parts: Part One is normative and Part Two provides guidance. Part Two has two sections. The first section provides a clause-by-clause expansion of Part One. The second section provides guidance specifically for complex electronic elements (i.e. for software and electronic hardware). 5.1 Part One The good news for those required to comply with the standard is that there are only nine pages of clauses in Part One that require compliance. As previously indicated in this paper, these clauses focus on the principles of safety management and safety engineering. Clause 6 deals with general requirements, including the need to identify all relevant legislation and regulation and to select appropriate standards, and then ensure that the system meets these requirements. Clause 7 addresses key roles and responsibilities including the project manager, project safety engineer and project safety committee. It expects that there will be evidence that key personnel are competent for the roles they undertake. The Safety Management approach in clause 8 is based around the establishment of a safety management system and in planning for safety by means of a safety management plan. The use of a Safety Case to provide a compelling, comprehensive and valid case that a system is safe for a given application in a given environment is mandated in clause 9. A Safety Case Report is defined as a deliverable summary of the safety case at key stages of the project. Clause 10 essentially summarises the principles of the hazard identification and analysis and risk reduction approach that was mandated by issue 2. The approach is based on the ALARP (as low as reasonable practicable) principle. The steps required are: hazard identification,

4 hazard analysis, risk estimation, risk and ALARP evaluation, risk reduction and finally, (provided that the risk arising from the system is either broadly acceptable or ALARP and at least tolerable) risk acceptance. Clause 11 deals with Safety Requirements and Evidence. It is in satisfying this clause for software and electronic hardware that the guidance in Part Two Section Two is particularly directed. The Interfaces between systems both between technical systems and between the organisational systems that manage safety are dealt with in clause 12. Clause 13 addresses the responsibility to manage change and feedback, particularly once systems are in service. In Part Two, counter-evidence is defined as evidence that has the potential to refute specific safety claims. The goal-based philosophy of Defence Standard means that the supplier has freedom of choice in selecting evidence with which to make a safety case. To ensure that this approach is not too selective and ignores evidence with the potential to undermine or refute the safety claims, the standard imposes a responsibility to search for, record and analyse all the evidence for the safety of the system and to take action to reduce the risk in accordance with the ALARP principle if the evidence shows that there are problems with the safety of the system. Finally, in clause 14, the standard places a responsibility on the supplier to plan for and record safety audits. The MoD reserve the right to appoint an independent safety auditor (ISA) and this section defines the rights and obligations of the supplier in respect of this appointment. 5.2 Part Two Section One of Part Two provides guidance on a clauseby-clause basis for Part 1. Some of the material, especially in clause 10 dealing with hazard identification and analysis, and risk assessment and reduction has been carried forward from Issue 2. However, Defence Standard no longer imposes, or even defines, a risk tolerability or a safety integrity level scheme. The reason for this is that it is infeasible for a single scheme to span the breadth of application (and risk tolerabilities) that are covered by this standard. Generally therefore, the standard talks about the responsibility to set tolerability criteria and define safety integrity requirements, and it allows the supplier, by agreement with the MoD Duty Holder, to utilise a suitable scheme from another standard (particularly useful in the case of an existing system) or to define specific criteria for the particular application. Section Two is concerned with complex electronic elements of safety related systems. Complex electronic elements means software and hardware, for which the significant failure modes are systematic rather than random. Section Two deals with defining safety requirements (as a result of the hazard analysis and risk management activities explored in Section One) and then with provision of evidence. The emphasis is on arguments based on direct evidence for the safety related behaviour of the electronic element, with process evidence providing only a supportive, backing argument. Direct evidence can consist of: analysis evidence (from formal methods, static analysis, failure modes effects analysis etc), demonstration evidence (from testing or inservice experience), quantitative evidence (from statistical analysis of demonstration evidence), review evidence (of the correctness and completeness of the implementation) and qualitative evidence (including good practice and expert judgment). As the term implies, direct evidence is concerned with the properties of the system (or element of a system) rather than the means by which those properties were developed. Test evidence, for example, should show that the element being tested exhibits the behaviour that is required of it. People who are familiar with process based standards (especially software standards) may have difficulties at first in expressing safety arguments based on direct evidence. For example, many software standards dictate that all source code statements or all decisions in source code must be executed. A metric showing 100% compliance with such a goal is process evidence but is not direct evidence for the safety of the system. However, if such a metric has been achieved, then there should be (test) evidence to show that all source code statements (or decisions) operate in accordance with the (safety related) requirements. The guidance in Part Two provides recommendations to ensure that for each type of evidence, the evidence is well-founded and hence able to support a compelling safety argument. Evidence should always be traceable to some safety argument (i.e. to a safety requirement or to a hazard). Evidence should be recorded. For example, if previous experience is being used as evidence, there needs to be some documentary evidence of the experience. This could be in the form of system logs, or it could be some form of witness report, such as a statement by users of the system regarding their experience of it. Evidence should be appropriate to the safety argument, for example if test evidence is used, there needs to be justification that the testing is representative of the final system and required behaviour. Justification is also needed for the extent, coverage and rigour of the evidence. For example, if review evidence is used, consideration should be given to how the evidence can show that the review was sufficiently thorough and complete. Although only providing a backing argument, process evidence (such as evidence that defined processes were followed in generating the assurance evidence or evidence that a particular standard was complied with in developing software) is important in providing confidence in the integrity of the direct evidence. In general, the direct evidence required by the safety arguments is a post-condition for the behaviour of the developed system. Direct evidence (e.g. test evidence) alone would necessarily not distinguish between poorly written software requiring extensive debugging before it eventually passed system tests and well-written software which passed all system tests on its first attempt. Consideration of process evidence (e.g. quality of software development processes), as well as counterevidence (e.g. initial failures of system tests), would

5 however allow greater confidence to be placed in the well-written software. The goal-based approach generally, and the guidance in section two particularly, is intended to allow the fullest practicable range of solutions, including COTS and existing systems. However, the guidance warns that depending on the integrity requirements, the absence of process evidence, or of access to the structure and design of the electronic element may mean that a COTS solution is not feasible. 5.3 Annexes Annex A in both Part One and Part Two provides definitions of the terms used in the standard. In Part Two, there two further annexes that expand on some of the concepts in the standard. Annex B provides guidance on the ALARP principle, on defining tolerability criteria and on applying the ALARP principle to complex electronic elements. Annex B explains that when ALARP is applied to complex electronic elements, the assessment should consider use of best practice and cost-benefit and effectiveness of additional engineering methods and techniques where these can be costed. It also points out that additional engineering effort often does not change the properties of the element but only improves confidence that requirements have been met. In applying the ALARP principle to complex electronic elements the confidence should be proportionate to the risk. This is why Part Two, Section One, in dealing with the system as a whole frequently refers to ALARP, but Section Two, in dealing with complex electronic elements refers to arguments and evidence needing to be commensurate with the risk managed by the associated safety requirements. Annex C provides more information on safety integrity requirements, on the concept of confidence in evidence and on safety integrity requirements (and safety integrity levels) for complex electronic elements. A safety requirement is defined as a requirement that, once met, contributes to the safety of the system or the evidence of the safety of the system. Safety integrity requirements are a subset of the safety requirements. Safety integrity requirements are defined as safety requirements relating to properties of the system that contribute to resistance to dangerous failure including (but not limited to) reliability, availability, robustness, timeliness and use of resources, as well as the degree of confidence in these properties. Annex C explains that safety integrity requirements may be expressed quantitatively or qualitatively. Quantitative requirements could include numeric reliability and availability targets (e.g. mean time between failure and mean time to restore) as well as statistical confidence in achieved reliability testing. Qualitative targets are typically be expressed as safety integrity levels that may impose a required reliability band (such as 10-5 to 10-6 failures per demand) and specify confidence by requiring certain activities to be carried out (such as testing in which all source code statements are executed). 6 Examples of Application 6.1 New development The standard is intended to ensure that safety is considered throughout system design and development. Selection of sub-systems and components should be made on the basis that there will be satisfactory evidence that the sub-system or component is sufficiently safe for its intended role. The hazard identification, analysis, risk estimation, risk and ALARP evaluation and risk reduction approach of clause 10 should be applied progressively and if necessary iteratively, throughout the development lifecycle. Defence Standard also recommends (in clause of Part 2) that: The requirements of any relevant civil regulatory regime should be considered, even if these are not mandatory, as compliance may reduce overall cost of ownership This guidance encourages and facilitates dual use (civil and military) solutions and supports the guidance later in Part 2 (in Annex C, clause C.2.3) that: The Duty Holder and Contractor may agree to adopt a safety integrity level scheme in order to define safety integrity requirements, if there is a suitable scheme, preferably defined in an international standard appropriate to the domain and application of the system Safety is a system issue and the safety of components and sub-systems needs to be assessed in the context of the overall system and environment. As a result, Defence Standard 00-56, in its entirety, is applicable only to the overall system supplier. It is the responsibility of the system supplier to determine the overall approach to safety and to flow down appropriate clauses to the subsystem and component suppliers. 6.2 Existing Systems If an existing system is offered as part of a system solution, the goal based approach means that existing safety documentation, including evidence of hazard identification, risk reduction and compliance with safety requirements can be used within the new safety argument. The safety argument could be primarily based on satisfactory use in service if there has been sufficient, relevant experience and if, during this experience, there has been a suitable regime of problem reporting and analysis. While existing safety evidence can be reused, there is still a responsibility to carry out hazard identification and analysis and to ensure that the risks are ALARP for the proposed application and environment. An existing system that is satisfactory in one application, may not be suitable for another application where there are new or increased risks, unless additional risk reduction measures are applied.

6 7 Issues Surrounding the Release of Issue 3 The release of Issue 3 was not without controversy. A draft of Part 1 was made available for comment in 2003 and Part 2 was issued for comment in early However discussions between MoD and industry organisations were still continuing in the Autumn of Legal implications of compliance One area of concern for defence contractors was the legal and contractual implications of the standard. Ironically, some of the wording that was unacceptable to legal experts from industry had been transferred directly from Issue 2. For example, Issue 2 required the supplier to provide free and unfettered access for the ISA. Other concerns were that Part Two might be, de facto, mandatory in that it could be considered to define the meaning of compliance by the MoD project managers or by a court (for example after an accident). The wording has been carefully scrutinised to ensure that the intent, that Part Two is guidance and other approaches can be acceptable, is preserved. 7.2 ALARP and Legal Requirements Industry organisations had concerns that in some cases their legal responsibilities could be more onerous than ALARP and yet MoD, as the customer, might not be willing to pay for the additional costs (for example to comply with prescriptive legislation such as CE marking). The intent of issue 3 was that the contractor s needs had been addressed in clause 6, which requires all legal requirements to be identified and complied with. However, while some industry representatives needed clause 6 to be strengthened, others felt that reference in clause 6 to legal requirements that are the contractor s responsibility was inappropriate in a Defence Standard. 7.3 MoD responsibilities A number of the comments from industry organisations concerned the fact that the standard, either as a whole or in specific clauses, did not define the responsibilities of the MoD Project Manager. This comment perhaps arises from a misunderstanding about the different roles of Defence Standards and JSPs a misunderstanding that has been aggravated in the past, by JSPs being called up in contracts. The legal concerns about the potential interpretations of the standard may have been aggravated by the fact that the standard defines the responsibilities of one party in the contract (the supplier), while the responsibilities of the other party (the MoD) are defined elsewhere. 7.4 Safety Audit and ISA While issue 2 of Defence Standard and had defined explicitly the role and responsibilities of the ISA, these are no longer defined in issue 3. The assumption at the time of issue 2 was that the system design authority would appoint the ISA and hence the role needed to be defined in the standard. This is no longer assumed and clause 14 places the appointment of an ISA at the discretion of the MoD and allows for the ISA to be employed by the MoD or the contractor. Mention of an ISA in the standard provoked concern from industry partly because of specific commercial issues such as access (see section 7.1 of this paper) and confidentiality. Late editorial changes were made to address these concerns. However, many commentators have concerns about the use of ISAs because of situations where access can not be agreed or because of perceived biases or conflicts of interest in the ISA role. Clause 14 also requires safety auditing in accordance with a safety audit plan by the contractor. Many commentators interpreted this as requiring double auditing 8 Key Challenges 8.1 Learning Curve and Judging Compliance The goal-based approach requires an intelligent dialogue by both customer and supplier. The standard does not state what safety arguments are acceptable and sufficient. Nor does it state how much evidence is needed. These are questions that must be decided on a case be case basis, but guidance could be developed for specific domains, and precedents will inevitably be developed from experience of application of the standard. The various MoD safety offices are developing domain specific guidance, but it will take time and experience to develop exemplars of acceptable approaches for each domain. The contractor needs to state the approach to compliance as part of the tendering process, but the MoD customer also has to participate in this and provide information about the environment and access to end users for the safety analysis. The contractor needs to justify why the approach and system are sufficiently safe but this is currently unfamiliar to both parties and will require assessment and interpretation by experts. 8.2 Aspects in scope, but with little guidance Systems of systems and equipment used for services (as opposed to procured by MoD) are intended to be in scope for the standard, but in practice there is almost no guidance. In both cases, questions arise such as: who is the duty holder and are conventional safety analyses appropriate? 8.3 Counter-evidence and Feedback Accurate assessment of safety risk requires good information from in-service use. Historically, suppliers have had difficulties in accessing information about the actual use and experience with their systems. The obligations in clause 13 of the standard means that MoD will need to establish new management systems for collecting data and communicating with suppliers. The requirement to search for and record counterevidence is challenging and will require changes in safety culture in MoD and its contractors. Ultimately, the requirement should aid in promoting an open safety culture and hence improve safety management but in the harsh reality of competitive contracting there is little

7 current incentive to expose the vulnerabilities of any proposed solution, or to potentially, increase the risk of a system not being accepted into service, by exposing commercially sensitive aspects of early test failures, problems with similar systems and rework. 8.4 Application to Software While Defence Standard has always attracted controversy, chiefly because of its emphasis on the use of formal methods, it also has its supporters. Since Defence Standard is now obsolescent, the explicit mandate for formal methods has been removed. In addition, there are no longer prescriptive requirements for how to manage and develop safety related software. Part Two, Section Two (clause ) recommends that primary arguments for the most critical elements should be based upon rigorous, analytical evidence for the absence of dangerous faults (i.e. upon for formal methods for software), but this material is only guidance. Where there are applications where the MoD duty holder (or Safety Management Office) believe that the use of formal methods are essential, their use will need to be mandated in the specific contract. Previous issues of Defence Standard defined safety integrity levels. The use of safety integrity levels is no longer mandated and there is no safety integrity level scheme defined in the standard. The expectation of the standard is that safety arguments will be made based on safety integrity requirements (as explained in Annex C of Part Two ) and that these may be quantitative or qualitative. Where qualitative safety integrity requirements are specified, the standard permits the MoD duty holder and contractor to agree to use a safety integrity level scheme from another (appropriate) standard. Reference to other standards would be relevant where the contractor wishes to supply existing software that has been developed in accordance with another standard or the contractors development processes are already compliant with another standard or compliance with an appropriate software development standard is used as process evidence to provide confidence in the integrity of the software. However it is generally easier to judge whether or not a software element is compliant with a software standard if that standard specifies methods and techniques in accordance with a safety integrity level scheme. The MoD recognises that software presents particular challenges in development and assurance. It is intended that the MoD's acquisition management system ( will eventually provide extensive guidance on all aspects of software safety assurance but to date the format and content of this guidance has not been agreed. can only benefit the cost-effective procurement and operation of safe systems. For many systems, the transition from Issue 2 can be eased by using the issue 2 approach as a route to compliance. For those systems where compliance with issue 2 was impracticable or unduly expensive, including equipment developed to other standards, the emphasis on producing a compelling argument for safety, rather than a tick-box compliance approach is a victory for common sense. 10 Acknowledgements Defence Standard Issue 3 was authorised by the MoD Safety Standards Review Committee (SSRC), managed by the Ship Safety Management Office and developed by a small team of MoD personnel and others. The material contained in Issue 3 and described in this paper draws upon a number of sources including Issue 2 of Defence Standard and The material in this paper is the personal opinion of the author and does not purport to represent the policy or view of MoD. 11 References MOD 2004: Interim Defence Standard 00-56/3 Safety Management Requirements for Defence Systems December MOD 1997: Defence Standard 00-55/2 Requirements for Safety Related Software in Defence Equipment 1997 (obsolescent December 2004, but still available) CAA 2002: Part of CAP 670 ATS Safety Requirements Part B SW01 Regulatory Objectives for software safety assurance in ATS Equipment. 9 Conclusion Defence Standard Issue 3 is part of a new generation of goal-based standards. Its introduction will require a learning curve for all parties, but the potential benefits easily outweigh the short-term costs. The positioning of the standard as an over-arching approach to safety management and safety engineering