safety critical systems - safety

7/30/2019 Safety Critical Systems - Safety

1/25

Software for Safety Critical Systems Lecture 3 - 1 of 1

Software forSafety-Critical

Systems

Safety Matters


2/25


Your Notes

Notes

Standards usually emerge following the success of prototype methods andtechnology, from the adoption of well-recognised techniques or from theexperience of several people within a specific field of research.

Standards allow best practices in software development to be shared, providea basis for certification and comparison and equip organisations with themeans to structure and control their processes and products.


3/25


Standards for Safety-Critical Systems

Standards and guidance on software development provide ameans for consistent, controlled development.

Standards can be particularly beneficial in the case of softwarefor Safety-Critical Systems where high levels of safety andreliability must be achieved.

Insisting that software suppliers comply to software standardsprovides a means to help attain these levels.

Of course, by using standards, the suppliers themselves benefit

from the structured approach to development they introduce.

We examine two standards related to Safety Critical Systems:-

INT DEF STAN 00-55

The Procurement of Safety-Critical Software in DefenceEquipment

IEC 1508

Functional Safety: Safety-Related Systems


4/25


Your Notes

Notes

INT DEF STAN 00-55 was developed by the MoD in response to theincreasing use of software to perform safety-critical functions in defencesystems that they procured. It was realised that current practice in softwareengineering was inadequate to produce the high-reliability software required.

The standard is intended to be equally applicable in the private sector.

References

[MoD91] Ministry of Defence: INT DEF STAN 00-55: The Procurement ofSafety Critical Software in Defence Equipment - Issue 1, MoD, April1991

Available from: Ministry of Defence, Directorate for Standardisation, Kentigern House, 65 Brown

Street, Glasgow G2 8EX


5/25


INT DEF STAN 00-55

The Procurement of Safety Critical Software in Defence Equipment

INT DEF STAN 00-55 is an interim standard developed by theUK Ministry of Defence (MoD).

Originally published on 5th April 1991. A new version is

currently under development.

It is used by the MoD when selecting contractors to supplysoftware.

The standard establishes a set of procedures and technicalrequirements for the development of safety critical software and

shall be followed on all contracts by all agencies who are involvedin developing, supplying and supporting software for the MoD.

In particular, the standard prescribes Formal Design Methods as

the means to achieve the rigorous development and validationrequired. The scope includes software engineering andmanagement processes which are deemed to promote theproduction of safety critical software.


6/25


Your Notes

Notes


7/25


INT DEF STAN 00-55

The standard advocates best practices in software engineering,considered to be the most effective techniques and methodscurrently available for the development of safety-criticalsoftware.

By ensuring that these practices are followed, the procurers ofsoftware can have confidence that software is being developedin a rigorous, defined manner.

To quote from the Preface to the standard:

It is recognised that many of the procedures and technical practicesneeded to generate SCS are still being developed. The proceduresand technical practices referred to in this Standard are considered tobe the best currently available.

The Standard sets out a software development process in whichVerification and Validation are integral parts, and achieved by using

formal mathematical methods in conjunction with dynamic testingand static path analysis.


8/25


Your Notes

Notes

IEC is the International Electrotechnical Commission which is responsible forInternational Standardisation in many technical areas. It comprises theequivalent of 43 national standards bodies.

Functional Safety

The ability of a safety-related system to carry out the actions necessary to achieve a

safe state for the equipment-under-control (EUC) or to maintain a safe state for theEUC

References

[IEC95] IEC/TC65: Draft IEC1508: Functional Safety: Safety RelatedSystems, IEC, 1995

[Bel94] Bell, R.: IEC Draft International Standard on Functional Safety:Current Position, Journal of High Integrity Systems, Vol. 1, No. 1,

1994


9/25


IEC Standard 1508

Functional Safety: Safety-Related Systems

IEC 1508 is a generic standard which is at a draft stage ofdevelopment.

By Generi c it is meant that it can act as:-

- a basis for the development of other application sectorspecific standards.

- an existing standard for application sectors where there isno existing industry specific standard.

It aims to harmonise and build on existing standards for Safety-Related Systems.

Contained within the standard are explicit requirements and

guidelines for the functional safety of safety-related softwaresystems.

Primarily concerned with the development of systems used tocarry out safety functions that incorporate Electrical/Electronic/Programmable Electronic Devices (E/E/PES) but isapplicable to other technologies.

A systems approach is adopted.

The approach to safety is based on risk.

IEC 1508 is the culmination of around 10 years activity.


10/25


Your Notes

Notes

The Overall Safety Lifecycle deals with the development of E/E/PES, OtherTechnologies (those that are not E/E/PES) and associated external riskreduction facilities that do not fall into one of these categories.


11/25


The Safety Lifecycle

The Overall Safety Lifecycle as defined by IEC 1508 wasdiscussed in Lecture 2. The standard is structured around thislifecycle.

This lifecycle provides a disciplined and systematic approach tosafety considerations.

For each phase of the Overall Safety Lifecycle there is anassociated set of:

- objectives

- requirements

- scope

- input

- deliverables

Safety-Related Systems based on E/E/PES are used to control apiece of hazardous equipment, to maintain it in a safe state or totake evasive action should it enter a hazardous state.

Equipment Under Control (EUC) Safety-Related System (SRS)


12/25


Your Notes

Notes

Some definitions (from the standard):-

Safety Integrity

The probability that a safety-related system satisfactorily performs therequired safety function under all the stated conditions within a stated periodof time.

Safety Integrity Level

One of 4 possible discrete levels for specifying the safety integrityrequirements of the safety functions to be allocated to the safety-relatedsystems. SIL 4 has the highest level of safety integrity and SIL 1 the lowestlevel.


13/25


Safety Integrity Levels

There are four Safety Integrity Levels defined within thestandard.

The Safety Integrity Level for the Safety-Related System

determines the measures that need to be taken against bothsystematic and random hardware failures in the design.

These are expressed in terms of Target Failure Measures, whichin turn are expressed as probabilities of failure.

The standard provides recommendations with regard to eachphase of the development of Safety-Related Software Systems.

These recommendations link the Safety Integrity Levels requiredof the system with techniques or measures to be adopted.


14/25


Your Notes

Notes

The Safety Integrity Level reflects the criticality of the system in terms ofrequired failure rates. The Safety Integrity Level selected for thedevelopment of the software will depend on that required for the entiresystem.

There is an implication that, with the current state of technology, higher SILscannot realistically be achieved.


15/25


SILs - Target Failure Measures

There are two columns:

Demand Mode of Operation indicates the probability of failurewhen the demands made on the system are counted.

Continuous/High Demand Mode of Operation assumes acontinuous mode of operation and then the failure is expressed

as the probability of failure per year of operation.

TARGET FAILURE MEASURES FOR A SAFETY-RELATED SYSTEM

SAFETYINTEGRITYLEVEL

Demand Mode ofOperation

PROB OF FAILURE/DEMAND

Continuous/High DemandMode of Operation

PROB OF FAILURE/YEAR

4 >=10-5 to < 10-4 >=10-5 to < 10-4

3 >=10-4 to < 10-3 >=10-4 to < 10-3

2 >=10-3 to < 10-2 >=10-3 to < 10-2

1 >=10-2 to < 10-1 >=10-2 to < 10-1


16/25


Your Notes

Notes

Measures here mean preventative measures put in place to avoid hazardoussituations, not quantitative measurements.


17/25


Techniques and Measures

Each set of recommendations is presented in a table whichprovides a mapping between Safety Integrity Levels andrecommended techniques and measures.

The indicators used are:-

HR Highly Recommended

R Recommended- No Recommendation

NR Not Recommended

Clause 7.7 : Software Safety Validation

TECHNIQUE/MEASURE Ref SIL1 SIL2 SIL3 SIL4

1. Probabilistic Testing B.47 -- R R HR

2. Simulation/Modelling D.6 R R HR HR

3. Functional and Black-Box Testing D.3 HR HR HR HR

NOTE:

One or more of these techniques shall be selected to satisfy the safety integrity level beingused.

Implementing the recommended techniques and measuresshould result in software of the associated integrity level.

For example, if the software was required to be validated to beof Integrity level 3, Simulation and Modelling are HighlyRecommended Practices, as is Functional and Black-Box Testing.


18/25


Your Notes

Notes


19/25


Detailed Techniques and Measures

Related to certain entries in these tables are additional, moredetailed sets of recommendations structured in the same manner.These address techniques and measures for:-

Design and Coding Standards

Dynamic analysis and testing

Approaches to functional or black-box testing

Hazard Analysis

Choice of programming language

Modelling

Performance testing

Semi-formal methods

Static analysis

Modular approaches

These are cross-referenced by the Ref. column in the tables.


20/25


Your Notes

Notes


21/25


Example - Table D.6 Modelling

D.6 : Modelling Referenced by Clauses 7.6

TECHNIQUE/MEASURE Ref SIL1 SIL2 SIL3 SIL4

1. Data Flow Diagrams B.12 R R R R

2. Finite State Machines B.29 -- HR HR HR

3. Formal Methods B.30 -- R R HR

4. Performance Modelling B.45 R R R HR

5. Time Petri Nets B.64 -- HR HR HR

6. Prototyping/Animation B.49 R R R R

7. Structure Diagrams B.59 R R R HR

NOTE:

One or more of the above techniques should be used.

The further entries in the Ref. column (eg. B.12) are references to

the Bibliography in Part 7 of the standard which contains theaims and a description of each technique and measure.

Other examples:-

Formal Methods are Highly Recommended only at SIL 4.

ADA with a subset comes Highly Recommended for all levelswhereas the use of BASIC is explicitly Not Recommended forSIL2, 3 and 4.


22/25


Your Notes

Notes

It is an unfortunate fact that the development of much of the discipline andmethodology which underpins safety issues has been imposed as a result ofmajor incidents.

The examples given here are drawn form the chemical industry but areequally applicable to all safety-related systems.

References

[Bar] Barrell, A.C.: Control of Major Hazards Offshore - Implementing LordCullen's Recommendations, published in Major Hazards Onshoreand Offshore, by the Institution of Chemical Engineers, London,Symposium Series No. 130, pp. 1-13

[Man] Mansfield, D. P.: Proposed Offshore Safety Cases - A Comparison withOffshore CIMAH Safety Cases, published in Major HazardsOnshore and Offshore, by the Institution of Chemical Engineers,London, Symposium Series No. 130, pp. 39-48


23/25


Safety Elsewhere

Throughout the 1970s there were a number of incidentsinvolving chemical plants:-

- In 1974 there was an explosion at a chemical plant inFlixborough, England, which killed some 28 people, causedconsiderable environmental damage and destroyed theplant itself

- In 1976 there was a release of the gas dioxin from achemical plant in Seveso, Italy.

As a consequence of these incidents, the European Directive (the"Seveso" Directive) on "Major Accident Hazards of CertainIndustrial Activities" produced by the European Commissionwas adopted.

In the UK this was implemented as the regulations for the"Control of Industrial Major Accident Hazards" or the CIMAHregulations for short.

Although these were not adopted for offshore activity, certainimportant features of these regulations do underpin existingregulations for both offshore and onshore activity.


24/25


Your Notes

Notes


25/25

The Cullen Report and The Safety Case

The "Piper Alpha" disaster in July 1988 resulted in a majoroverhaul of arrangements for offshore safety.

These were formulated within the findings of the Cullen report -more formally, The Report of the Public Inquiry - which waspublished in November, 1990.

In part there emerged a requirement for the development of aSafety Case which would ensure a disciplined and systematicapproach to ensure that the whole question of health and safetywas properly addressed.

The Safety Case must be comprehensive and cover all activitiesperformed within, or related to, a plant or installation.

Thus a system wide view was implied, and so an integratedapproach to risk assessment which would take full account of allhazards and the possible interactions between these.

Underpinning this were quantified approaches to riskassessment coupled with sound engineering judgement.

This activity would entail a considerable investment in terms oftime and resources but the expectation was that it would lead toa far greater understanding of the issues involved in ensuringthat safety was being properly evaluated and controlled.

Implicit in the development of this notion is the understandingthat the Safety Case would have to be accepted by a regulatory

body such as, in the UK, by the Health and Safety Executive.

safety critical systems - safety

Documents