Content uploaded by Andrew J Rae
Author content
All content in this area was uploaded by Andrew J Rae
Content may be subject to copyright.
Guidance for Def(Aust) 5679 Issue 2
Luke Wildman
1
Tony Cant
2
Chris Edwards
3
Alena Griffiths
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 first 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 profit 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 Coeffectors that lead to a
defined 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 flow down to Component
Safety Requirements (CSRs); and to provide arguments (at
an appropriate level of formality) that satisfaction of the
CSRs entails satisfaction of the SSRs. Corresponding to
each System Hazard is a System Safety Requirement de-
manding that the hazard does not occur. The SSRs must
be specified to a level of formality that depends on the
System Danger Level.
The System Architecture must be expressed in terms
of Components that combine to carry out the system func-
tions: a block diagram showing interfaces between Com-
ponents, as well as inflows from (kinetic energy, thermal
energy, radiation, chemical, data, etc.) and outflows to the
environment, is the most suitable for this purpose.
The Architecture will be informed by safety consider-
ations, exhibiting specific Safety Features: these are either
• Protective Measures, i.e. Components introduced
into the Architecture with a specific safety purpose;
or
• Partitioning the design to isolate – both function-
ally and physically – Components that have safety
requirements
We then derive a collection of Component Safety Re-
quirements (CSRs), expressed in terms of Component in-
terfaces. The CSRs must be expressed to a prescribed
level of formality.
Design Assurance. The Design Assurance phase pro-
vides arguments that System Components have been built
in such a way that provides assurance of safety. Vari-
ous processes are prescribed: some are generic and ap-
ply whatever technology is used to implement the Com-
ponent; others are technology-specific
2.2 Comments on Issue 2
Document Focused The Standard is now document-
focused, detailing the evidence required for the Safety
Case. Many of the process requirements of the previ-
ous version that were difficult to achieve or not applica-
ble to non-development items (NDIs) have been removed.
For example the old Section 6.2 on System Development
Plans has been removed; it is now straightforward to apply
the Standard to an NDI provided the evidence exists.
However, Def (Aust) 5679 Issue 2 has not followed
overseas trends (Department of Defence 2000), (UK Min-
istry of Defence 2004, Issue 3) and become purely goal-
based. Goal-based standards focus on broad principles
and requirements to be placed on developers, and are not
prescriptive about the processes, methods and tools that
should be used during system development.
The Standard allows no tailoring. This is because it is
safety case focussed and not process focused. Complete
documented evidence for safety architecture analyses and
design assurance are required but the processes used for
safety analysis may vary.
Qualitative Assessment The Standard now only re-
quires qualitative assessment of external mitigations when
considering accident sequences, which makes it easier to
reduce the danger levels (DLs) (old Levels of Trust) than
before. As before, probabilities may not be assigned to the
likelihood of a System Hazard, but conditional probabil-
ities may be assigned to co-effectors in Hazard Analysis.
Also reliability measures such a Minimum Time to Failure
may be used in the design assurance of simple hardware
components.
No Hazard Log The Standard has no requirement for a
Hazard Log. This is at odds with many other standards and
Technical Regulatory frameworks. The reason for this is
to drive safety in the direction of maintaining a complete
and precise set of system requirements.
System Focus The Standard has an increased system fo-
cus. A requirement has been added that the SSRs are
collectively satisfied by the CSRs. This must be demon-
strated formally for SSRs at higher danger levels (> D
3
).
At the time of the first issue of the standard, the use
of formal methods was widely considered to be onerous
and expensive. Very few organisations had the capabil-
ity/skills to take on projects involving formal methods.
Formal methods tools were difficult to use and it was not
clear how to formalize architecture. In addition, the ben-
efits of formal modelling to the early identification of de-
sign flaws was unrecognised as was the ability to use for-
mal models in other processes such as testing . At time
of publication of this paper, research into formal methods
has matured and there now exist commercial-grade tools
to support the application of formal methods. Without di-
rect experience from Australian defence suppliers, it is dif-
ficult to say at this point whether this will still represent the
same hurdle it represented in 1998. Part of the goal of this
project is to provide guidance to direct the judicious use
of formal methods (i.e. limit the use of such methods to
those areas where safety criticality demands added atten-
tion). In Issue 2 of the standard, this is addressed in two
ways.
First, the benefits of formalization and suggestions of
possible further application of formal models (such as in
automated testing) are made clear.
Secondly, detailed descriptions are given of the ways in
which external mitigations may be used to decrease dan-
ger levels (by up to two levels), and safety features may
be used to reduce safety assurance levels (by up to two
levels).
For example, a system with potentially catastrophic
hazards, for which there are sufficient external mitigations
to justify reducing its danger level by two, is classified as
a D
4
system. Such a system will require formal modelling
of the System Safety requirements, a formal architecture
model, formalisation of the Component Safety Require-
ments, and a formal proof that the Component Safety Re-
quirements taken together satisfy the System Safety Re-
quirements. However, if designs can be found with suffi-
cient safety features to justify reducing the danger levels
of (some of) the components by a further two levels to S
2
,
the assurance of such components will only require semi-
formal specification and informal analysis. This acts to
put the emphasis on getting the system safety right in the
first place and to eliminate unnecessary formalisation of
components.
Virtual Machine The Standard introduces the concept
of Virtual Machines and Virtual Interfaces. This describes
how to encapsulate the behaviour of design components
and in particular is used to encapsulate NDIs.
Typically, access to design and implementation docu-
mentation for NDIs is limited. Therefore it is very difficult
to build a safety argument for an NDI where the argument
relies on evidence from the development process, or about
intrinsic properties of the NDI.
The Standard makes it possible to include quite sophis-
ticated NDI equipment as part of a Virtual Machine with-
out analysis. Thus NDIs are catered for more explicitly
throughout the Standard.
Terminology changes The Standard removes some bar-
riers to use with other standards. In some situations,
projects may be required to satisfy several safety stan-
dards. This may bring about the requirement to build sev-
eral safety cases for the differing standards. In Issue 2,
effort has been made to generalise the standard and to use
generic terms so that a single safety case may be used for
multiple standards and so that terminology is not confused
between various application domains. For example, the
following terminology has been used for two of the agents
involved in the safety assurance activities.
• The Acquirer is the organisation within the DoD that
is responsible for the acquisistion of the system.
• The Supplier has primary responsibility in producing
the safety case.
However, the transfer to Def(Aust) 5679 of safety ar-
guments compiled for other standards may be difficult be-
cause of different assurance requirements; the Standard
generally imposes more onerous requirements at corre-
sponding safety integrity levels, and also imposes require-
ments not present in some other standards. In addition,
the design assurance section has been updated to reflect
modern testing practices.
2.3 Guidance Material
The preparation of the guidance material was contracted
to Nova Defence by the Defence Materiel Organisation
(DMO). The general nature of the guidance material and
the schedule of the guidance material project was pre-
defined by the DMO. The schedule consisted of the fol-
lowing key elements.
1. A structured Workshop involving selected Defence
projects to elucidate issues with the application of
Def (Aust) 5679 Issue 2.
2. Planning and Regular project management reviews.
3. Preparation of a detailed Case Study illustrating the
fully worked out application of Def (Aust) 5679 to
a specific system incorporating Non-Development
Equipment.
4. Detailed Guidance Material for Def (Aust) 5679, in-
cluding advice on tools and techniques and Data Item
Descriptions for Def (Aust) 5679 deliverables.
The case study and the detailed guidance material is
discussed further in Sections 3 and 4. In the remainder of
this section we describe the workshop and the DIDS.
2.3.1 Structured Workshop
The purpose of the workshop was to seek direction from
stakeholders on those parts of Def (Aust) 5679 Issue 2
where guidance material would be most helpful. The
workshop participants represented project offices and in-
dustrial organisations that had had prior experience with
Def(Aust) 5679 Issue 1. Such projects include:
1. NULKA Anti-Missile Decoy
2. The Mine Warfare Command support system
3. The Navigational Display System
4. The Battlefield Command Support System
Participants were requested to review Def(Aust)5679 Is-
sue 2, and consider, based on their experiences with Is-
sue 1 and given what they now know about Issue 2, areas
where application guidance would be helpful. In addition,
certain persons with detailed knowledge of past projects
were asked separately to prepare a short presentation shar-
ing their experiences on those projects.
The outcomes of the workshop were as follows:
1. The following Issues Guidance Papers were sug-
gested.
(a) Guidance Notes for Project Offices (POs) on
Applying Def(Aust) 5679
(b) Using NDIs in conjunction with Def(Aust)
5679
(c) Methods for Architecture Assurance
(d) Methods for Design Assurance
2. A case study inspired by the Anti-Ship Missile De-
fence (ASMD) frigate upgrade was presented. The
proposal received approval and some further sugges-
tions for content were adopted.
2.3.2 Data Item Descriptions
DIDs for the following Def(Aust)5679 Issue 2 documents
were produced.
• Safety Management documents
1 Safety Management Plan,
2 Safety Case Summary,
3 Safety Review Report,
• Safety Case documents
4 Hazard Analysis Report (including require-
ments for documenting danger assessment),
5 Safety Architecture Report (including require-
ments for documenting the Criticality Assess-
ment and the Architecture Test Plan),
6 Design Assurance Report (including require-
ments for documenting the Design Testing
Plan),
• Safety Evaluation Documents
7 Safety Evaluation Plan,
8 Safety Evaluation Report.
The DIDs were produced in ASDEFCON format for
publication at the DMO website. Each DID is accompa-
nied by a traceability table which lists each clause in the
Standard that mentions the subject document, and a state-
ment as to how and where in the DID the clause is ad-
dressed.
3 Case study
The case study demonstrates the application of the Stan-
dard to an example system. The example system is a fic-
tional upgrade of a class of Navy frigates with the instal-
lation of a self defensive capability. The upgrade involves
an electronically-scanned phased array radar (PAR), a sys-
tem for detecting, discriminating and selecting airborne
threats, and a laser designator for high speed self-defence
missile target illumination. The fictional system is called
the PARTI system (from PAR and Target Illumination).
Note that the missile and missile launch system is a sepa-
rate project, outside the scope of the PARTI project.
The Phased Array Radar (PAR) and Illuminator (and
their control systems) are non-development items (NDI).
The Target Discriminator and Selector (TDS) system is a
software plugin to the existing combat management sys-
tem (CMS). The TDS takes its input from the PAR and
directs the Illuminator. Targeting information is also com-
municated to the missile launch system.
3.1 Possible Hazard sources
The following aspects of the PARTI system are sources of
potential hazard.
1. The laser Illuminator and the PAR are high intensity
radiation sources. This may pose a risk to personnel,
ordnance and other equipment: the laser is hazardous
to the eye at up to 100km and skin burn is also an
issue; heating caused by the PAR or the laser may
cause ordnance to explode or equipment to be dam-
aged;the PAR has the ability to rapidly change the
RADAR direction without it being known to external
observers.
2. Because of the interaction with the missile system,
targets selected by the PARTI system have the po-
tential to be targeted by a missile. Therefore, the in-
tegrity of the target designation, characterisation and
location data produced by the PARTI system is safety
critical. Furthermore, the maintenance of the Illumi-
nator target fix for the employment of offensive strike
weapons is safety critical.
Threats
Prohibited
Areas
Phased Array
Radar Beams
Laser Targeting
Beams
Ownship
Missile
Figure 1: PARTI Operational Context
3. Target selection and illumination are automated.
Information about the target must be communi-
cated to the missile launch system, prior to mis-
sile flight. Unwanted interactions between target de-
tection/selection system and missile launch system,
such as unwanted launch, need to be controlled.
All documents required by the Standard for Safety
Management, the Safety Case, and Safety Evaluation were
produced as part of the case study (see the list of DIDs
above). In the following sections we briefly describe how
each one was prepared for the PARTI system.
3.2 Safety Management Plan
The SMP is a living document describing the safety man-
agement plans and processes. An initial SMP was pro-
duced prior to safety case development for the PARTI sys-
tem. The SMP was revised during the course of the fic-
tional development.
The first version described the safety management
structure, personnel and their competencies, plans for con-
figuration management, document control, lifecycle plans,
etc., and the plan for hazard analysis.
The SMP was updated after the hazard analysis to
record what was actually done in hazard analysis and to
document plans for the architecture analysis. The SMP
was revised again after architecture analysis and design
assurance.
3.3 Hazard Analysis Report
The Hazard Analysis Report is compiled by the Supplier
and must include a description of the Operational Con-
text for the System, a description of the System, a list of
potential Accidents and their severities, a list of System
Hazards, a list of possible Accident Scenarios with corre-
sponding Danger Levels, and an assignment of a System
Danger Level.
The Operational Context of the PARTI system is il-
lustrated in Figure 1. In summary, it contains (but is not
limited to):
• the frigate’s Missile System which uses the illumi-
nation for a target fix for the Evolved Sea Sparrow
Missiles (ESSM),
• other frigate-based systems including other ord-
nance, the ship helicopter, the combat manage-
ment system (CMS) and associated systems (such as
radars), the frigate itself and the frigate support sys-
tems, the frigate’s personnel, and
• the external context, including non-targets (friendly
aircraft, civil aircraft, non-hostile surface vessel,
High-value Unit (HVU) such as oil tanker under es-
cort), shore facilities, and other personnel and objects
nearby.
Hazard Analysis was initially performed in the form of
a Functional Failure Analysis workshop. This technique
involved the following steps.
1. Identify the functions that the system performs
2. Using a set of guide-words, generate a list of func-
tional failure modes, for each system function.
3. For each functional failure mode, consider the impli-
cations of that mode in the broader context, identi-
fying those functional failure modes that might con-
ceivably, possibly in combination with other events,
lead to an accident.
Initially a list of 15 functions was identified. However, in
the process of conducting the workshop it was determined
that the level of detail was too low because it included
functions performed internally to the system. After some
discussion the following list of 5 functions was identified.
1. Initially, the system shall not be scanning, no threats
shall be identified, the system shall not be illuminat-
ing anything, and no messages shall have been com-
municated to the missile system.
2. When commanded, the System shall scan for tracks.
3. When a track is detected the system shall discrimi-
nate whether it is a threat.
4. While a target is identified, the system shall illumi-
nate the target.
5. While a target is illuminated, the system shall pass
information to the Missile Control System.
Note that there are several design considerations that
were not examined in the project because the focus was
on providing exemplar demonstrations of how to interpret
and apply the Standard. For example, it is usual that Oc-
cupational Health and Safety Hazards are also addressed.
These may occur during the construction, installation or
maintenance of the PARTI system. In light of the fact this
exercise was for a fictional case study and that OH&S is-
sues, while being within the scope of the Standard, were
not the focus of most of the development activities, it was
decided to rule OH&S issues out of scope. However it
was noted that there were significant OH&S related haz-
ards that were not being addressed.
The FFA conducted on the functions above identified
the hazards given in Table 1.
Accident Scenario AS A 1 External mitigations
IE Scanning commanded Assumed procedures for deactivating the PARTI scanning during
ordnance handling. However, these procedures may depend on
the likelihood of imminent threat.
HAZ A Radiate Prohibited Areas
CE1 Inadvertent firing of chaff, Nulka, 5
inch gun, harpoon, torpedos, ESSM
EMC/EMI HERO, resilience of ordnance to some (assumed
high) level of radiation.
A1 Damaged caused by above to non-
target
The likelihood of non-target being hit is dependent on the trajec-
tory of the missile and the density of traffic. It is assumed to be
a Medium strength external mitigation
Table 2: An example Accident Scenario.
Id. System Hazard
HAZ A Radiate prohibited areas.
HAZ B Illuminate non-target.
HAZ C Communication error to missile system.
HAZ D Fail to maintain illumination.
Table 1: System Hazards
During the formalisation of the System Safety Re-
quirements (SSRs) it was discovered that a consistent set
of SSRs could not be produced. This is because it is pos-
sible that the target of illumination may be obscured by
another object that comes into the line of illumination.
It therefore becomes impossible to maintain illumination
while preventing the illumination of a non-target. In or-
der to handle this case, the PARTI system is expected to
predict the paths, relative to the ship, of all known objects,
and to anticipate whether the target may become obscured
prior to selecting it as a target. Therefore, it can be as-
sumed that if a target has been selected, and a message
conveying that fact has been sent to the missile system,
then no known objects will come between the laser and
the target and therefore become accidentally illuminated.
Of course, there is the case that an entirely new object (un-
seen by the PARTI system) arrives and that its path may
obscure the target. The PARTI system handles this case by
sending a message to the missile system informing it that it
needs to cease illumination. In addition it was determined
during later evaluation that a lock-down mode should be
added. Additional functions were added to address these
issues.
6. When the system predicts that a target will pass be-
hind a non-target, the system shall cease illumina-
tion, and pass information to that effect to the missile
system.
7. When commanded, the system shall revert to a “safe
lock down mode”’ in which it is not scanning, not
discriminating threats, not illuminating anything, and
not transmitting messages to the missile system.
Severities are assigned to the various accidents in the
manner described by the Standard: Catastrophic equals
loss of multiple lives, Fatal equal loss of a single life, Se-
vere equals severe injury, Minor equal minor injury. De-
fault danger levels of D
6
down to D
3
are assigned to the
above accident severities. An example of such an acci-
dent is the following: “A missile or other ordnance causes
damage to a non-target.”. Such an accident would have
potentially Catastrophic consequences and so would have
a default danger level of D
6
.
Following the workshop, detailed accident scenarios
were produced by a single analyst. An example accident
scenario is presented in Table 2. It consists of an initiat-
ing event (IE), the occurrence of the Hazard (HAZ
A), a
coeffector (CE1), and the accident (A1).
External mitigations are then taken into account to as-
sign danger levels to each accident scenario. The strength
of external mitigations may be assessed as Low, Medium
or High. Justification of these strength assignments must
be provided (i.e. statistical evidence). Probabilities are
not assigned to the chance that the system hazard itself
is realised. For example, the danger level assigned to the
accident scenario above is D
5
. In all, 9 accident scenar-
ios were analysed. The highest resulting danger level was
D
5
. Thus it was determined (at this stage) that the System
Danger Level was D
5
.
During the Evaluation of the Hazard Analysis Report
it was determined that:
1. the strength assigned to one of the identified external
mitigations was not credible,
2. laser damage to the eye of a pilot has potential catas-
trophic consequences,
3. and that the set of hazards identified was incomplete
because the possibility of very high levels of radi-
ation from PAR and Illuminator had not been ad-
dressed.
It was then determined that two new hazards should be
added.
Id. System Hazard
HAZ E Scan with excessive intensity.
HAZ F Illuminate with excessive intensity.
This then resulted in 5 new accident scenarios.
3.4 Safety Architecture Report
The Supplier must develop and analyse the Safety Archi-
tecture and submit a Safety Architecture Report. The out-
comes of this phase are the specifications of the System
Safety Requirements (SSRs), a description of the archi-
tecture and the components and their interfaces, the speci-
fications of the Component Safety Requirements, verifica-
tion of the SSRs from the CSRs, an architecture test plan
and the results of such testing, and finally, the Criticality
Assessment (assigning SALs to CSRs).
3.4.1 SSRs
When the System Danger Level is D
3
or higher, the Sys-
tem Safety Requirements are expressed in a Formal spec-
ification language. As the System Danger Level of the
PARTI system is D
5
the System Safety Requirements will
be expressed formally. The formal modelling and ex-
pression of the System Safety Requirements is done in
the Event-B language, a subset of the B language (Abrial
1996) which is a close relative of Z. Event-B is based on
Action Systems (Kurki-Suonio 2005).
The Event-B model of the PARTI system and the Sys-
tem Safety Requirements was prepared using the Rodin
tool. The Rodin tool is a free formal development tool
available at rodin-b-sharp.sourceforge.net.
The PARTI system is a reactive real-time system. That
is, the system must react to environmental stimuli with
real-time bounds. The approach follows that of Butler and
Falampin (Butler & Falampin 2002) and Abadi and Lam-
port (Abadi & Lamport 1994).
Figure 2: PARTI Architecture
The approach used is to model the entire system as
a state machine where events may occur freely if their
guards (enabling conditions) are satisfied.
Many of the requirements involve the current time vari-
able τ. The model of real-time used in this specification is
that at every time step, all of the requirements must hold.
External events may occur, that, if not reacted to by the
PARTI system, will force the system into a state where the
requirements are not satisfied. The system must therefore
be forced to react to the external events in order to make
the requirements true.
Analysis of SSRs Before formalisation of the SSRs can
begin, considerable analysis must be performed in order to
develop mathematical models of the inputs and outputs of
the PARTI system. In addition, considerable thought must
be put into the interpretation of the somewhat vague de-
scription of the Hazards. In the following paragraphs we
explain how one SSR was interpreted and give an example
of how the PARTI system variables were formalised.
SSR
A Prohibited areas are assumed to arise from time
to time as a normal consequence of the operation of the
frigate. This may be because of maintenance, the han-
dling of ordnance or fuel, or the arrival or departure of
the ship’s helicopter. We assume that such events are usu-
ally scheduled well in advance of the use of the area. We
also assume that prohibited areas may change dynamically
while the PARTI system is in operation. Therefore, there
will be some time lag from the time that a prohibited area
is allocated and the time that the scanning of the PAR is
adjusted. While this lag will be small, it must be taken
into consideration when using the prohibited area so that
the prohibited area is allocated in advance of the time that
the area will be used.
In English, the System Safety Requirement is stated as
follows.
Following a delay of PAd milliseconds after the
setting of prohibited areas, the system shall not
radiate in the prohibited areas.
This may be expressed formally as the following predicate
labelled ProhibPAR.
ProhibPAR :
τ ≥ PAtm + PApd ⇒
(∀rb·rb ∈ dom(radiates) ⇒
rb ∩ prohibitedareas = ∅)
In the formalisation, τ models the current time, PAtm
is the time that the prohibited areas were most recently
changed, and PApd is the maximum delay allowed be-
fore the PAR must respect the updated prohibited areas.
The function variable radiates maps the set of “beams”
emitted by the PAR to their radiation intensities. The
domain (dom) of the function is just the beams. The
beams are modelled by “beam-shaped” sets of points. The
prohibitedareas are also modelled by a set of points (not
necessarily connected). Each radiation beam (rb) must
not intersect a prohibited area, that is, the intersection
(∩) of each beam rb and the prohibitedareas is equal to
the empty set (∅). The predicate may be paraphrased as:
when the current time is PApd time units after the time
that the prohibited areas were set, all of the beams radiated
by the PAR must not intersect the prohibited area. Predici-
ate ProhibPAR comprises the System Safety Requirement
S S R A.
The other SSRs are formalised similarly.
3.4.2 Safety Architecture
Within the Safety Architecture section we present a de-
scription of how the components work together to achieve
the system functionality. We describe each Component
and its Component Interfaces, Implementation Technol-
ogy, Customisation Data, and Maintenance.
The components, including safety features and NDI
components, are organised into the architecture described
in Figure 2. Information and control flow is indicated
by the directed arcs. Points in the boundary are external
sources or sinks. As the Operator Interface is distributed
over the several components we have not identified a sin-
gle Operator Interface component but instead have dis-
tributed its functionality throughout the other components.
The Components of the architecture are the following.
Operator The operator interfaces with the PAR control,
the target discrimination and selection software, the laser
control and the laser interlock.
The operator is responsible for acting upon the com-
mands arriving from the ship commander to start opera-
tion or to stop operation of the PARTI system. The oper-
ator is also responsible for becoming aware of prohibited
areas and setting the scan area appropriately. The opera-
tor is also responsible for selecting targets for illumination
based upon information displayed by the target discrimi-
nator and selector (TDS) component and other situational
awareness. Finally the operator is responsible for watch-
ing the laser control display which displays the current
and predicted tracks for laser illumination. In the case that
the operator believes that a non-target may become illumi-
nated, the operator shall disable the offending laser using
the laser interlock.
Operator Interface The operator interface is the mech-
anism used by the Operator to control the rest of the
PARTI components. In this Case study, the operator in-
terface is distributed over a number of other components.
PAR Control The PAR control provides an interface be-
tween the operator and the PAR for switching the PAR on
and off, and for setting the scan area of the PAR in accor-
dance with prohibited areas. The PAR control displays the
current setting of the PAR to the operator and provides a
way for changing the settings. In addition the PAR control
controls the PAR filter. Upon the receipt of new scan area
settings from the operator, the PAR control sends the scan
area settings to the PAR filter so that it may use them to
filter requests to the PAR from the Target Discriminator.
PAR The PAR component acts on request from the PAR
control component to scan certain areas. The PAR au-
tonomously uses radar beams (of the correct intensity) to
scan for objects within the scan area. Track data consist-
ing of object parameters and trajectory is sent from the
PAR to the TDS component and the Laser Control com-
ponent (to increase the quality of fire control). The PAR
also acts on requests from the TDS component (via the
filter) to radiate constantly on certain areas in order to get
better quality track data. The PAR checks that the requests
are within the allocated scan area before acting on the re-
quests. The PAR may be switched on or off by the PAR
control.
Target Discriminator and Selector (TDS) The target
discrimination and selector component displays track in-
formation derived from the PAR and other sources to the
operator. In addition it discriminates whether the track de-
notes a threat and alerts the operator. The operator may
select targets for illumination using the TDS interface.
When a target is selected, the TDS software sends mes-
sages to the missile system about the selected target. In
addition, it calculates which laser to use for illumination.
It then sends an illumination request to the laser control
that specifies that a laser should illuminate a certain track.
It also sends messages to the PAR requesting that it main-
tain continuous radiation on the path of the predicted in-
tercept.
PAR Filter The PAR filter component checks that the
requests from the TDS to the PAR to radiate on certain
areas are consistent with the scan area set by the PAR con-
trol. It continuously accepts requests from the TDS com-
ponents, checks them, and forwards correct requests to the
PAR. It ignores requests that are not within the scan area.
Laser Control The Laser Control component acts on re-
quests from the TDS component to illuminate tracks with
a given laser. Track trajectory data is received directly
from the PAR. The laser tracks are displayed to the user
with the other predictive track trajectory data in a graphi-
cal display so that the user may use it to check if the laser
is being commanded correctly, or if it may illuminate a
non-target. The Laser control directs the lasers to illumi-
nate given locations.
Laser Illuminator The Laser Illuminator component
(involving 2 lasers) is driven by the Laser Control com-
ponent to illuminate a given location with a specific laser.
The illumination location is continuously updated.
Laser Interlock The lasers may be switched on or off
by the Laser Interlock component.
3.4.3 Safety Features
The Safety Architecture Report must describe and justify
all Safety Features. Evidence must be provided that sig-
nificant design alternatives have been considered, and that
a safety-based assessment was made. There are several
safety features built into the PARTI system. Three of them
are discussed below. We also give as an example a frag-
ment of a discussion of options for the PAR.
Partitioning Partitioning is used to control the number
of unanticipated interactions that may arise during normal
or faulty behaviour. Partitioning is used within the PARTI
system to isolate components from each other. For exam-
ple, the PAR subsystem is independent of laser illumina-
tion subsystem.
Redundant checking of PAR beam requests PAR
beams are emitted from the PAR either autonomously
under direction from the Operator or under direct con-
trol from the TDS component. Beams requested by the
TDS component are constantly focussed on the one area
and are therefore of high risk of raising Hazard A. PAR
beam requests originating from the TDS component are
checked by the PAR filter and the PAR itself. In addi-
tion, the TDS component will not request beams in pro-
hibited areas because it only selects targets that do not
require beams in prohibited areas for the entire intercept
path. An alternative design may be to make the TDS com-
ponent drive the PAR completely, placing the burden for
selecting PAR beams within the TDS component rather
than the PAR. This alternative was impractical (in the fic-
titious case study) due to commercial constraints, and also,
the addition of prohibited area checking within the PAR,
despite being difficult to assure because the PAR is a Non-
Development Component, was seen to contribute to the
safety overall.
Interlocking of the laser illuminator A simple hard-
ware interlock is attached to the laser Illuminator compo-
nent in order to prevent unwanted illumination. This inter-
lock provides an additional way to prevent unwanted illu-
mination over and above that provided by the cancellation
of targets using the Operator interface to the TDS compo-
nent, the prediction performed in the TDS and laser con-
trol components, and the shutdown provided by the system
command function.
3.4.4 CSRs
The set of CSRs must specify the safe behaviours of the
Component Interfaces to the level of formality, depend-
ing on the System Danger Level, given in Table 9.1 of
the Standard (Department of Defence 2008). As the Sys-
tem Danger Level of the PARTI system is D
5
, a formal
presentation of the CSRs is required. The 72 CSRs were
expressed in Event-B.
3.4.5 Verification
The Safety Architecture Report must present an argument
as to the safety of the Architecture, proving that the Sys-
tem Safety Requirements are satisfied by the Component
Safety Requirements and to the level of formality, depend-
ing on the System Danger Level, given by Table 9.1. of
the Standard (Department of Defence 2008). Given that
the System Danger Level is D
5
, the verification must be
done formally.
The verification that the PARTI Component Safety Re-
quirements satisfy the System Safety Requirements was
achieved using formal refinement in Event-B.
The development was achieved with the aid of the
Rodin tool. The Rodin tool generates the proof obliga-
tions that need to be discharged in order to show that:
1. the machine is consistent, and
2. one machine is a refinement of another.
In the process of refinement, particular proof obliga-
tion were generated that show the entailment of the CSRs
by the SSRs. However, these obligations are not easily
understood in the framework of the Event-B specification
because they are buried within the proof obligations of cer-
tain events. The Standard requires that such entailments
be made explicit. Therefore the entailment of the SSRs
was extracted from the proof obligations and explained in
the Safety Architecture Report.
Note: The Proof of the PARTI system was partially
completed in order to develop the models. This was
achieved using the automatic proof checking tools of
Rodin and a small amount of interactive proving. How-
ever, within the time frame for the case study, not all proof
obligations have been discharged.
Outline of Development The system specifications in-
volving the System Safety Requirements are refined down
to the Component Safety Requirements using two steps.
The goal of the first step is to develop intermediate CSRs
without any redundancy. The second step of the develop-
ment is to introduce redundancy by duplicating functions
introduced in the intermediate step and assigning them to
the final components.
An example of an intermediate entailment showing
how the intermediate predicates entail the SSR predicates
and safety features is the following.
S S R A :
ProhibPARr1 ∧ ProhibPARr2 ∧
ProhibPARr3 ∧ ProhibPARr4
⇒ ProhibPAR
The second refinement introduces the components and
safety features presented earlier in Figure 2. In many
cases the predicates regarding functions introduced in the
first refinement are allocated to single components. How-
ever, in some cases, functions from several components
are used to implement an intermediate function.
For example, the following combinations of CSRs on
the PAR, PAR Control (PC), and Operator (OP), entail the
predicate ProhibPAR1 which relates to SSR A.
ProhibPAR :
csrPAR1 ∧ csrPAR11 ∧
csrPC2 ∧ csrOP2 ∧
csrPAR13 ∧ csrPAR14 ⇒
ProhibPARr1
Proof of Second Refinement The proof of the second
refinement has several proofs concerned with the timing
properties. That is, that information is conveyed through
the components in such a way as to meet the time con-
straints specified in the high-level specification. Such
proofs are relatively easy. For instance one may need to
show that the PAR is turned off within a C MPd maximum
delay of it being commanded to stop. The intermediate
delays are the following:
• the operator receives the command within CMS Cd
time units,
• the operator sets the PAR Control appropriately
within OPS Cd time units,
• the PAR Control sends a message to the PAR within
S Cmd time units, and
• the PAR receives the message within PCMsd time
units (which it acts on immediately)
This requires that the following inequality holds.
CMS Cd + OPS Cd + S Cmd + PC Msd ≤ C MPd
This inequality is established as an axiom to the specifi-
cation. Obviously these constants need to be instantiated
with the real time-constraints of the system and tested.
3.4.6 Architecture Testing
The Safety Architecture Report must propose and justify
a Safety Architecture Test Plan that demonstrates the cor-
rectness of the System against the System Safety Require-
ments and also the correct behaviour of the Architecture
(Department of Defence 2008, clause 9.10.5). The presen-
tation of test results should follow normal approaches to
system testing. As the system has not been implemented
the testing itself was not done.
The Safety Architecture Test Plan must exercise the
System in accordance with its expected Operational Con-
text (Department of Defence 2008, clause 9.10.6). The
testing of the PARTI system may be performed with the
aid of automated test case generation tools. Several au-
tomated testing tools are now available. An automated
testing tool suitable for Event-B is available from Leirios
Technologies www.leirios.com. However, it was not avail-
able for use in this case study. It is able to generate test
cases from B specifications. Event-B may be translated
into B by the Rodin tool.
3.4.7 Criticality Assessment
The Safety Architecture Report must assign and justify
a Safety Assurance Level (SAL) to each Component
Safety Requirement (Department of Defence 2008, clause
9.11.2). The SAL of a Component Safety Requirement
must be no less than two levels lower than the Danger
Level of the System Safety Requirement from which it
was derived. In the case of Operator Components, the as-
signment of SALs greater than S3 must be highlighted in
the Safety Case Summary and explicitly justified.
SALs were assigned to all of the PARTI CSRs in the
manner described above.
3.5 Design Assurance reports
Design assurance involves analysis of the component de-
signs to show that the CSRs are met. This contains,
for each component, a description of the Implementation
Technology, Component Safety Specifications (CSSs), a
Design Model, Design Verification, a Design Testing Plan,
results of such testing, and a Maintenance Design. The
CSSs re-express the CSRs in terms of the implementation
technology. The design model describes how the imple-
mentation technology is controlled to implement the de-
sired component functions. The design model must be
shown to satisfy the CSSs using the design verification.
Further demonstration is provided by the design testing.
Reliability issues are dealt with in the maintenance design.
In the PARTI case study, Design Assurance Reports
were produced for each type of Implementation Technol-
ogy used in the Standard. The following issues were ad-
dressed.
NDIs Components are usually implemented with non-
development equipment. Such equipment may include
commercial components bought off-the-shelf, specialised
hardware (FPGAs etc.), or in the the case of software, op-
erating systems, third-party libraries, programming lan-
guages, compilers, etc (or in the case of Operators, hu-
mans). The implementation technology section must con-
tain a description of a virtual machine that captures the
way that the equipment is used to implement the compo-
nent. In addition, a virtual interface must be provided
that specifies the interface provided by the virtual ma-
chine/equipment (i.e., registers, procedure calls, human
behaviour) that corresponds to the component interface
used in the safety architecture. The Component Safety
Requirements (CSRs) inherited from the Safety Architec-
ture are then re-expressed in terms of the virtual interface
to produce the Component Safety Specifications (CSSs).
The SALs of the CSRs are assigned to the corresponding
CSSs.
Virtual Machine The virtual machine concept allows
the designer to explain why the Design Model is a suit-
able representation of the component for demonstrating
that the component satisfies the CSRs. It also allows the
representation of the CSRs to be transformed to a form
suitable for verification of the design model. The virtual
machine is described informally but must be described in
sufficient detail to demonstrate to the evaluator that the
use of the implementation technology has wide industry
acceptance and reflects industry best practice. The vir-
tual machine concept allows any mismatches between the
equipment and the component function to be dealt with in-
formally. This is particularly useful in the case where the
non-development equipment may have unused functional-
ity, or to explain how the design works around particular
failings of the equipment (in an operating system for ex-
ample). It also allows changes to non-development equip-
ment (brought about by vendor changes not under the con-
trol of the designer) to be dealt with informally without
having to adjust the (potentially formal) design model and
the verification.
Testing The Design Assurance Report must describe a
design testing plan. The level of testing is determined by
the SALs of the component safety requirements. At the
lowest SAL functional/black-box testing against the CSRs
is required. At the highest SAL, structural testing against
the design model and verification arguments is also re-
quired. The results of the testing also form part of the
Design Assurance Report. As the PARTI system was not
implemented, and in many cases the design models were
only sketched, no actual testing could be performed. How-
ever, suggestions were given for the testing techniques that
could be applied and the types of test cases that would be
suitable.
Maintenance Design Finally, the Design Assurance Re-
port must include a Maintenance Design. The Mainte-
nance Design must detail and justify on safety grounds
a maintenance and monitoring schedule for each piece of
physical equipment. This is based upon a sound estima-
tion of the reliability properties of all physical equipment
under the environmental conditions and demands of the
operational context. Once again, without actual reliabil-
ity data of physical equipment of the PARTI system, it
was difficult to complete this section in full. However,
where possible, general Maintenance Design strategies
were given for the particular implementation technologies.
3.5.1 Reports produced
The guidance material provides examples of Design As-
surance Reports for the following types of implementation
technologies.
Operator The implementation technology of an opera-
tor component is the human body. The virtual machine
should describe what the human behaviours are that are
used to carry out the required operator functions. The vir-
tual interface is a list of the behaviours and the CSSs are
the CSRs interpreted in terms of those behaviours. The de-
sign model describes how the behaviours are controlled in
order to implement the operator functions and is embodied
by the Operating Manual. In addition to the verification of
the design model, human factors and task analysis must be
carried out.
The human behaviours of the PARTI operator in-
cluded:
• listening to and responding to vocal commands from
the ship commander,
• maintaining a detailed awareness of ships operations,
schedules, and environment,
• selecting appropriate scan areas from the PAR con-
trol user interface, etc.
The SAL of Operator component was assumed to be S
3
.
Therefore, formal CSSs and semi-formal design mod-
elling and design verification were required. This was
achieved by reinterpreting the CSRs in terms of a model
of the human behaviours described in the virtual interface
and by using dataflow and state-machine diagrams de-
scribing the required human activities as a design model.
Complex Hardware The PAR Filter was used as the ex-
ample of design assurance of complex hardware. The vir-
tual machine is the high-level design of the circuit repre-
sented in the Very High Speed Integrated Circuit (VHSIC)
Hardware Description Language, i.e., VHDL. The virtual
interface consists of the registers and memory used in the
VHDL design. As the PAR Filter was assumed to have
a SAL of S
4
, formal CSSs, a formal design model, and
semi-formal verification was required. This was achieved
by reinterpreting the CSRs in terms of the virtual inter-
face and using a state-machine to model the behaviour
described by the VHDL. In this case it was then possi-
ble to perform formal verification of the relatively simple
state-machine against the CSSs because it could be proved
almost completely automatically using the Rodin tool for
Event-B.
Simple Hardware The Laser Interlock was used as the
example of simple hardware. It is assumed to have been
implemented by a pair of circuit breakers. The virtual ma-
chine described how this equipment was used to imple-
ment the protective measure and the virtual interfaces was
the same as the component interface occurring in the ar-
chitecture (meaning that the CSRs were the same as the
CSSs). The SAL was assumed to be S
4
. Therefore a
formal design model and a semi-formal verification is re-
quired. This may be achieved by a mathematical model of
the physical properties of an interlock (i.e, current carry-
ing property, insulting property and current breaking prop-
erty). This approach uses standard mathematical mod-
elling tools available commercially.
Software The TDS component was used as the example
of software. The component was assumed to have been
implemented in Ada and was a plugin component to the
combat management system (CMS). The TDS component
also contains some of the Operator Interface. The Oper-
ator Interface is treated separately to the other functions
(target discrimination etc.) performed by the TDS com-
ponent because it requires a separate set of skills to ex-
amine the associated human factors issues. The Operator
Interface was implemented as a graphical display overlaid
on the CMS display. It was determined that this raised
new hazards that should be addressed in the hazard analy-
sis and which would ultimately arise in new CSRs for the
Operator Interface. As the SAL of the TDS component
was assumed to S2, a semi-formal language such as UML
is appropriate for the design model. Verification was pro-
vided in the form of an informal argument expressed in
English.
Non-Development Component The Laser Illuminator
was used as the example of the Non-development compo-
nent. It was assumed that the Laser Illuminator has previ-
ously been certified under UK DefStan 00-56 (Dec, 1996)
and that the associated safety certificate and report have
been supplied. The design assurance report describes an
approach to showing that the non-development component
satisfies the allocated CSRs using the external evidence.
3.6 Safety Case Summaries
The purpose of the safety case summary report is to pro-
vide a structured, clear and concise, high-level argument
that the System is safe to deploy, operate, maintain and re-
tire. Safety case summary reports were produced for the
PARTI system following each of the three phases of safety
case development: hazard analysis, architecture analysis,
and design assurance. Each report contains a descriptions
of the system, a justification of the safety management and
analysis practises, a report of the safety evaluation sta-
tus, and an executive level safety argument that provides a
structured, clear, and concise high-level argument for why
the system is safe. In addition, it justifies any assignments
of SALs exceeding S
4
to any component, or in the case of
operator components, exceeding S
3
.
3.7 Evaluation Reports
System Safety Evaluation aims to increase the assurance
of safety by providing a thorough, independent and objec-
tive review of the technical correctness of the Safety Man-
agement process and the Safety Case. The Evaluator is
responsible for producing a Safety Evaluation Report and
a Safety Evaluation Plan. Safety evaluation of the docu-
ments produced for the PARTI case study was performed
by an independent evaluator. Importantly, the Evaluator
discovered the omission of an operator reaction time in
the operation of a manual interlock switch. The recom-
mendations resulting from the evaluations were addressed
in successive versions of the safety case. The recommen-
dations included the following:
• To provide greater detail on assumptions made in the
identification of the accident scenarios in the hazard
analysis report;
• To provide greater detail on the use of protective
measures in the safety architecture report;
• To provide further information on the limitations and
assumptions of the mathematical modelling of the
PARTI system described in the safety architecture re-
port;
• To improve the readability of the formal modelling
used in the safety architecture report; and
• To provide more detailed evidence of the adequacy
of the tools used for design assurance.
4 Issues guidance papers
Issues guidance papers (IGPs) were produced to provide
assistance to Suppliers, Acquirers and other agents in the
application of issue 2 of the Standard. The IGPs are dis-
cussed in the following sections.
4.1 Guidance Notes for POs
The guidance note for project officers on applying
Def(Aust) 5679 included detailed notes on the following
issues.
Applicability of the Standard It is noted that in cases
where there is doubt about whether a system is safety crit-
ical, the hazard analysis phase must be performed in order
to make a determination. In the case that there is no con-
ceivable way in which an accident may result from the
failure of the system, then the system may be be deter-
mined not to be safety critical and further application is
not required. Otherwise a full application of the Standard
is required.
Definition of the system boundary The decision as to
the placement of the system boundary will dramatically
affect the subsequent Safety Case Development, because
it affects what we consider to be the hazards of the sys-
tem. It also separates those matters to be considered to be
part of the Operational Context, and those matters which
are part of the architecture. The Standard encourages the
Supplier to reduce the overall safety risk both by the use
of a External Mitigations or Damage Limitation factors
(reduction outside the System Boundary); and by the in-
troduction of Safety Features (reduction inside the System
itself). Each of these may be called a risk-limiting factor
(RLF). To ensure that both approaches are addressed, the
standard imposes limits, at the Hazard Analysis phase and
the Safety Architecture phase, on the extent to which the
danger assessment or criticality assessment, respectively,
can downgrade the final assurance requirements. The limit
of reduction at each phase is two levels. The maximum re-
duction will only be obtained where there are RLFs both
external and internal to the system.
Systems of Systems It is noted that in the case of sys-
tems of systems there is some difficulty in determining the
appropriate places to draw the system boundaries. The
difficulties arise from issues such as project scope, and
the need to control the impact on the safety cases of the
multiple systems as new systems are added. This is be-
cause the addition of a new system may require revision
to the hazard analysis, safety architecture, and design as-
surance phases for other systems. Such difficulties may
only be addressed by detailed planning prior to the com-
mencement of such projects. Towards this, DMO has
guidance in place to conduct safety workshops during of-
fer definition activities to fully scope safety engineering
activities, including defining system boundaries, with the
preferred tenderer and other Commonwealth safety stake-
holders, prior to contract award.
Multi-party and In-house projects It is noted that
projects usually involve several parties and it is often the
case that a single supplier must be appointed as integrator.
The “integrator” is usually the best case for nomination as
the Supplier for the purposes of the Standard. However, it
maybe the case that, due to contractual difficulties arising
from misalignment of scope of supply and preparation of
the safety case, that the project office itself will become
the Supplier (i.e. an in-house project).
Timing of safety case development The timing of the
development of the safety case is discussed. It is noted
that successful acceptance of the safety case of a system
is more likely if the safety case is developed concurrently
with the development of the system. However, sometimes
a retrospective development, where the safety case is pro-
duced after the system has been built, is required. Such
situations occur when the system is being acquired com-
pletely from elsewhere or a legacy system is being up-
dated. Such situations are very difficult to deal with be-
cause it is frequently the case that insufficient evidence is
available to develop a safety case.
Another challenging situation is evolutionary develop-
ment of the system requirements during development and
sustainment. Such situations occur when the system is be-
ing developed as a series of prototypes. The threat here is
that the safety case may be vulnerable to sudden changes
in assurance requirements if the operational context or
safety features are changed in such a way as to affect the
criticality of one or more Components or even of the entire
Architecture.
Risk Assessment Framework In a traditional risk-
based approach, the risk associated with a system is a
function of:
1. The frequency at which unwanted events, caused in
part or whole by the system, might occur; and,
2. The severity of those unwanted events.
The Standard does not use this approach for the follow-
ing reasons. Firstly, the notion of frequency of unwanted
system events arising (say) from software issues is a du-
bious notion; secondly, the use of frequencies can lead to
sloppy thinking, picturing safety in terms of synthesizing
arguments based on Component failure rates (and hence
reliability considerations). These are important in safety
engineering but divert attention from the importance of
architecture and design assurance. It is well-known that
a System can be unsafe — even when no Component has
“failed” in the usual sense — simply because the way that
the System is designed violates overall System Safety Re-
quirements. The use of the Standard will result in a deep
understanding of the System’s safety architecture and de-
sign when it behaves as intended and ensure that confi-
dence in this understanding is commensurate with the dan-
gers posed by the System.
Budgeting for safety The use of both bottom-up bud-
geting strategies and statistics from previous projects was
discussed.
4.2 Using NDIs in conjunction with Def(Aust) 5679
This report summarises the main issues in the use of Non-
development Items (NDIs) and gives a detailed account
of how the Standard addresses these issues. The report
notes that the use of NDIs is almost essential in any safety
critical system of modest scale. The reason being that at
some level, particularly at the lower levels of design, NDIs
(or equipment) will be purchased off-the-shelf rather than
developed as bespoke items. However, while the use of
NDIs is entirely normal, there are several NDI-specific
factors that their use introduces. These factors need to
be considered because of the risks that they may intro-
duce for the assurance of safety critical systems with the
Def(Aust)5679 Standard Issue 2 (Department of Defence
2008). The factors are the following.
1. The extent to which design information about the
NDIs is available: there needs to be sufficient infor-
mation available about the NDIs in order to build the
safety case.
2. The use of external standards: it may be diffi-
cult to transfer assurance from external standard to
Def(Aust) 5679 Issue 2.
3. The extent to which the safety case relies on the use
of NDIs: extensive reliance on NDIs makes the as-
surance of the safety case vulnerable to changes in
the nature or availability of particular NDIs.
The preferred means for dealing with Non-Development
items in the Standard is to treat them as Non-Development
equipment within a Component. The distinction between
Components and Equipment is artificial but useful. Equip-
ment is the bottom up view and Component is the top
down view. The requirements for a Component flow natu-
rally from the System requirements. The use of equipment
to implement the Components may be dealt with infor-
mally in the explanation of the Virtual Machine. The use
of the Virtual Machine concept offers several advantages.
1. Handling mismatches in safety functions. Any mis-
matches between the safety functionality offered
by the Component and that offered by the Non-
Development equipment may be accommodated in-
formally in the Virtual Machine without having to be
handled formally.
2. Protects from change. Changes to the Non-
Development equipment may be handled informally
in the Safety Case rather than requiring a change to
the Design Model.
3. Information about previous usage may be used to jus-
tify the choice of Non-Development equipment. This
must be accompanied by a Maintenance design that
is justified by a reliability analysis based on the sup-
plied fault histories.
Finally, in the situation where no system design in-
formation or assurance evidence is available, it must be
accepted that, the fact that - although a Hazard Analysis
should be feasible and worthwhile as a means of exposing
the level of safety risk that exists - the other two phases of
the Safety Case are unlikely to be achievable. No amount
of ”game-playing” or loose interpretation of the Standard
is going to make up for the fact that there is no coherent
argument for system safety.
4.3 Methods for Architecture Assurance
A survey is presented of the commercial tools, techniques
and languages that are applicable to Safety Architecture
analysis. The survey includes descriptions and some ex-
amples of
• several formal, semi-formal, and informal methods
and tools that may be applicable to safety architec-
ture design modelling and verification at the various
safety assurance levels,
• several tools for automated test case generation,
• tools and techniques for criticality assessment.
4.4 Methods for Design Assurance
A survey is presented of the commercial tools, techniques
and languages that are applicable to design assurance.
The survey includes descriptions and some examples
of
• many formal, semi-formal, and informal methods
and tools that may be applicable to design assurance
at the various safety assurance levels and for the var-
ious implementation technologies,
• several tools and techniques that may be applicable
to maintenance design.
5 Conclusion
In this paper we have described the guidance material that
was produced to accompany the re-issue of the Def(Aust)
5679 Standard. The guidance material was prepared with
input from the major stakeholders of safety critical sys-
tems within the Australian DoD. In all, the project pro-
duced four issues guidance papers, eight DIDs, and a case
study involving fourteen reports.
While every attempt has been made to choose a system
that is representative of the kinds of system to which the
Standard is likely to be applied, there will undoubtedly be
many issues associated with application of the Standard
that are not exposed by this particular case study. This is
a fundamental limitation of any case study.
There are few other examples of guidance for safety
critical systems development of a scale similar to the
PARTI case study. In most academic papers, the size of
the examples is limited by the size of the paper. However,
some examples were discovered which covered the en-
tire safety case at the SunnyDay Website (MIT 2008) and
there are also some examples of hazard analysis (Pasquale
et al. 2003) as well as safety architecture analysis by Gar-
lan et al. (Garlan & Schmerl 2006, Garlan et al. 2005).
Finally, other examples of B and Event-B being used to
model systems may be found for rail (Butler & Falampin
2002, Lecomte et al. 2007) and other safety critical sys-
tems (Taouil-Traverson & Vignes 1998).
References
Abadi, M. & Lamport, L. (1994), ‘An old-fashioned
recipe for real-time’, ACM Transactions on Program-
ming Languages and systems 16(5), 1543–1571.
Abrial, J. (1996), The B-Book: Assigning Programs to
Meanings, Cambridge University Press.
Atchinson, B. & Lindsay, P. (1999), Resolution of
technical issues in Def(Aust) 5679, DefSafe Report
CA38809-301, Technical report, SVRC.
Atchison, B. & Cant, T. (1999), Improving safety manage-
ment in defence acquisition, Technical Report 99-42,
SVRC.
Butler, M. & Falampin, J. (2002), An approach to mod-
elling and refining timing properties in B, in ‘Refine-
ment of Critical Systems (RCS02)’.
Department of Defence (1998), Def(Aust) 5679, The Pro-
curement of Computer-Based Safety Critical Systems.
Department of Defence (2008), Def(Aust) 5679, Safety
Engineering for Defence Systems.
Department of Defence, U. (2000), Military Standard
MIL-STD-882D, Standard Practice for System Safety.
Garlan, D., Reinholtz, W. K., Schmerl, B., Sherman, N. D.
& Tseng, T. (2005), Bridging the Gap between Systems
Design and Space Systems Software, in ‘Proceedings of
the 29th IEEE/NASA Software Engineering Workshop
(SEW-29)’, pp. 34–46.
Garlan, D. & Schmerl, B. (2006), Architecture-driven
modelling and analysis, in ‘SCS ’06: Proceedings of
the eleventh Australian workshop on Safety critical sys-
tems and software’, Australian Computer Society, Inc.,
Darlinghurst, Australia, Australia, pp. 3–17.
Kurki-Suonio, R. (2005), A practical Theory of Re-
active systems: Incremental Modeling of Dynamic
Behaviours, Texts in Theoretical Computer Science,
Springer. EATCS.
Lecomte, T., Servat, T. & Pouzancre, G. (2007), For-
mal methods in safety-critical railway systems, in ‘Pro-
ceedings of Brazilian Symposium on Formal Methods:
SMBF 2007’, pp. 26–30.
Lindsay, P. A. (2001), Improved acquisition processes for
safety-critical systems in the australian department of
defence, in ‘SCS ’01: Proceedings of the Sixth Aus-
tralian workshop on Safety critical systems and soft-
ware’, Australian Computer Society, Inc., Darlinghurst,
Australia, Australia, pp. 31–38.
Lindsay, P. & Smith, G. (2000), Safety assurance of
commercial-off-the-shelf software, in A. Griffiths, ed.,
‘5th Australian Workshop on Safety Critical Systems
and Software’, Australian Computer Society, pp. 43–
51.
MIT (2008), ‘Aero/Astro Software Engineer-
ing Research Laboratory (SERL) Papers’,
http://sunnyday.mit.edu/papers/dfw2.pdf.
Pasquale, T., Rosaria, E., Pietro, M., Antonio, O. & Fer-
roviario, A. S. (2003), Hazard analysis of complex dis-
tributed railway systems, in ‘22nd International Sympo-
sium on Reliable Distributed Systems’, pp. 283 – 292.
Taouil-Traverson, S. & Vignes, S. (1998), Designing a b
model for safety-critical software systems, in ‘B ’98:
Proceedings of the Second International B Conference
on Recent Advances in the Development and Use of
the B Method’, Springer-Verlag, London, UK, pp. 210–
225.
UK Ministry of Defence (2004), Interim Defence Stan-
dard 00-56, Safety Management Requirements for De-
fence Systems: Part 1 (Requirements), Part 2 (Guid-
ance).
