Guidance for Def(Aust) 5679 Issue 2 Luke Wildman 1 Tony Cant 2 Chris Edwards 3 Alena Griﬃths 1 Brendan Mahony 2 BJ Martin 4 Andrew Rae 1 1 System Safety and Quality Engineering Pty Ltd 11 Doris St West End, Brisbane, Qld 4101 Email: alenag@ssqe.com.au 2 High Assurance Systems Cell Defence Sciences and Technology Organisation PO Box 1500, Edinburgh, SA 5111 Email: {Tony.Cant,Brendan.Mahony}@dsto.defence.gov.au 3 AMW Professional Services Email: cbhe@ozemail.com.au 4 Nova Defence PO Box 3308, Belconnen, ACT 2617 Email: Brett.Martin@NovaGroup.com.au Abstract The Australian Standard for safety-critical systems devel- opment, Def(Aust) 5679, was ﬁrst released in 1998. As part of the release of Issue 2 (Department of Defence 2008) of the Standard, guidance material has been pre- pared to assist those who need to apply the Standard. The guidance is made up of three main parts: a case study that demonstrates how the Standard can be applied to an ex- ample safety critical system, Issues Guidance Papers that further explain key concepts or requirements of the Stan- dard, and Data Item Descriptions (DIDs) that, for each of the documents required by the Standard, describe how the document is to be structured. This paper describes the guidance material that was prepared for Issue 2 of the Standard. Keywords: Safety Critical, Standard, Guidance 1 Introduction Def(Aust) 5679 Issue 2 “Safety Engineering for Defence Systems” (Department of Defence 2008) (following on from Issue 1 (Department of Defence 1998)) is a standard that presents requirements and guidance for safety engi- neering during the acquisition and sustainment of systems for the Australian Government Department of Defence. As part of the release of Issue 2 (Department of De- fence 2008) of the Standard, guidance material has been prepared to assist those who need to apply the Standard. The guidance is made up of three main parts. 1. A Case Study that demonstrates how the Standard can be applied to an example safety critical system, 2. Issues Guidance Papers (IGPs) that further explain key concepts or requirements of the Standard, and 3. Data Item Descriptions (DIDs) that, for each of the documents required by the Standard, describe how the document is to be structured. This paper describes the content of the guidance mate- rial. In Section 2 we explain the background to issue 2 and Copyright c 2008, Commonwealth of Australia. This paper appeared at the 13th Australian Workshop on Safety-Related Programmable Systems, Canberra 2008. Conferences in Research and Practice in Information Technology, Vol. 100, Tony Cant, Ed. Reproduction for academic, not- for proﬁt purposes permitted provided this text is included. the guidance material and give a description of the DIDs. In Section 3 we describe the case study. In Section 4 we describe the issues guidance papers. In Section 5 we make some concluding remarks. 2 Background 2.1 Overview of Def(Aust) 5679 issue 2 Issue 2 of the Standard represents an evolution of Issue 1 (Department of Defence 1998). The revision process has been informed by research performed during the DefSafe project (Atchison & Cant 1999, Lindsay 2001, Lindsay & Smith 2000, Atchinson & Lindsay 1999), by actual project experiences, and by input from other sources internal and external to the Australian Department of Defence. Def (Aust) 5679 provides detailed requirements and guidance on the structure of the Safety Case, focusing on the assurance evidence that the system meets its safety re- quirements. The key stages of the Safety Case will now be described. Hazard Analysis The aim of Hazard Analysis is to de- scribe the System, its Operational Context and identify all possible Accident Scenarios (and their associated Dan- ger Levels) that may be caused by a combination of the states of the System, environmental conditions and exter- nal events. An Accident is an external event that could directly lead to death or injury. The Severity of an Accident is a measure of the degree of its seriousness in terms of the extent of injury or death resulting from the accident. The possible severities are Catastrophic, Fatal, Severe and Mi- nor. System Hazards are top-level states or events of the system from which an Accident, arising from a further chain of events external to the System, could conceivably result. Accident Scenarios describe a causally related col- lection of System Hazards and Coeﬀectors that lead to a deﬁned Accident. To each Accident Scenario a Danger Level is assigned based on the Accident Severity and the strength of any External Mitigations. Safety Architecture. The aim of the Safety Architecture phase is to describe the System Architecture in terms of Components; to describe Safety Features present in the ar- chitecture; to detail System Safety Requirements (SSRs) and how these requirements ﬂow down to Component