1. Developing safety critical systems
Chapter 5, Storey

2. Safety-critical systems
There are several approaches to the design of safety-critical systems.
In order of precedence these are.
To produce a system that is intrinsically safe.
To adopt design techniques that prevent or minimize the occurrence of hazards (interlocks, guards).
To use techniques to control hazards when they occur (failsafe devices, damage control, containment).
To adopt methods that aim to reduce the impact of hazards (use of warning devices, training of staff in emergency procedures).
We are primarily concerned with the second of these approaches.
System safety kan oppnås på forskjellige måter, i prioritert rekkefølge:
Å produsere et system som er ”safe” i seg selv.
Benytte teknikker som hindrer eller minimerer tilfellene av hasarder (interlocks, guards).
Benytte teknikker som kontrollerer hasarder når de oppstår (failsafe devices, damage control and containment).
Benytte design teknikker som har som mål å redusere skadene av hasarder (warning devices, the training of staff in emergency procedures).
Interlocks: mekanismer som sikrer at potensielle hasardiøse aksjoner kun gjennomføres når de er sikre. Benytter sensorer til å oppdage et systems tilstand.
Guards: holder mennesker unna fra farlige deler av et system til de er sikre. Benytter actuators for å hindre eksponering av fare.

3. Lifecycle models
Lifecycle models are a means of describing the different phases of the development process.
A safety lifecycle emphasizes those aspects that have particular relevance to safety.
The lifecycle from IEC is widely used. This cover all aspects of the development process from an initial concept through to decommissioning (see figure 5.2).
A general lifecycle model:

4. Different types of lifecycle models
Waterfall model:
This is the most common and classic of lifecycle models, also referred to as a linear-sequential life cycle model. 
A sequential software development model in which development is seen as flowing steadily downwards through the phases (requirements, design, implementation…)
Proceeds from one phase to the next in a purely sequential manner, only when each phase is fully completed, one proceeds to the next phase.

5. Different types of lifecycle models
Iterative and incremental model:
Each iteration result in an increment, which is a release of a system that contains added or improved functionality compared to the previous release.
All iterations will include work in most of the process disciplines( requirement, design, implementation and testing)
“The process for constructing several partial deliverables, each having incrementally more functionality.”

6. Different types of lifecycle models
Spiral model:
The spiral model is similar to the iterative incremental model, with more emphasis placed on risk analysis. 
The spiral model has four phases: planning, risk analysis, engineering and evaluation.
A software project repeatedly passes through these phases in iterations. Each iteration of the spiral results in a deliverable.
Requirements are gathered in the planning phase. In the risk analysis phase, risks are identified and a prototype is produced. Software is produced in the engineering phase, along with testing. In the evaluation phase the customer evaluates the output of the project, before the project continues to the next spiral.

7. Different types of lifecycle models
V-model:
The model identifies the major elements of the development process.
Just like the waterfall model, the V-shaped lifecycle is a sequential path of execution of processes.  Each phase must be completed before the next phase begins. 
One of the attractions of this model is that its form emphasises a top-down approach to the design and a bottom-up approach to testing.
In the figure above a typical development lifecycle model is shown (the V-model). The model identifies the major elements of the development process. One of the attractions of this model is that its form emphasises a top-down approach to the design and o bottom-up approach to testing. Such models are only an approximations to the development process. In practice the various stages are not always performed in such a strict sequential manner. Design often involves a great deal of iteration, with a series of operation performed repeatedly until a satisfactory result is obtained. Also missing from this simple model is any indication of information flow between the various stages.

8. Developing safety-critical systems
The process of developing a safety-critical system may be both complicated and time consuming.
Like all development projects it has various phases, which can be presented diagrammatically using a lifecycle model.
The main elements of the development of a safety-critical system are, in general, similar to those of less critical units.
However, in critical applications the development process is dominated by a need to produce and demonstrate dependability.
Consequently, each phase is carefully structured and documented to ensure that it is performed correctly.
IEC also describes an overall safety lifecycle (see figure 5.3). The form of the safety lifecycle is very similar to that of the overall system lifecycle, with the addition of phase concerned with hazard and risk analysis.
The main elements of the development of a safety-critical system are, in general, similar to those of less critical units. However, in critical applications the development process is dominated by a need to produce and demonstrate dependability. Consequently, each phase is carefully structured and documented to ensure that it is performed correctly.
The process of developing a safety-critical system may be both complicated and time consuming. Like all development projects it has various phases, which can be presented diagrammatically using a lifecycle model.

9. Phases of the development process
Requirements:
The starting point of any development project is determined by the system requirements (customer requirements), which is an almost abstract definition of what the system should do.
Before the system can be implemented these abstract requirements must be formalised into a functional requirements document (user requirements specification), which attempt to describe what the system should do.
The starting point of any development project is determined by the system requirements (customer requirements), which is an almost abstract definition of what the system should do. Before the system can be implemented these abstract requirements must be formalised into a functional requirements document (requirement capture, user requirements specification), which attempt to describe what the system should do.

10. Phases of the development process
Hazard and risk analysis:
Once the functional requirements of the system have been established, hazard and risk analysis is performed to identify potential dangers in the system and to allocate an overall level of integrity.
One of the outputs from these analyses is the safety requirements, which defines what the system must and must not do, in order to ensure safety.
Once the functional requirements of the system have been established, hazard and risk analysis is performed to identify potential dangers in the system and to allocate an overall level of integrity. One of the outputs from these analyses is the safety requirements, which defines what the system must and must not do, in order to ensure safety.

11. Phases of the development process
Specification:
From the functional requirements and the safety requirements of the system a specification is produced, which will include measures for safety assurance in line with the integrity level assigned.
The specification attempts to define, in an unambiguous manner, a system that will completely fulfil these requirements.
In reality this is hard and it is easy to make mistakes at this stage.
Requirements are often written in natural languages, which are subject to ambiguity.
A misunderstanding of some aspect of the requirements may lead to a specification that is incomplete or incorrect.
the testing performed is aimed at establishing that the system meets its specification.
From the functional requirements and the safety requirements of the system a specification is produced, which will include measures for safety assurance in line with the integrity level assigned.
The specification attempts to define, in an unambiguous manner, a system that will completely fulfil these requirements.
In reality this is hard and it is easy to make mistakes at this stage. Requirements are often written in natural languages, which are subject to ambiguity. A misunderstanding of some aspect of the requirements may lead to a specification that is incomplete or incorrect. Errors is specification are a major problem in the production of highly critical systems, as much of the testing performed is aimed at establishing that the system meets its specification.

12. Phases of the development process
An ideal specification should be:
Correct
Complete
Consistent
Unambiguous
The problems associated with the production of unambiguous specifications may be tackled by using:
semiformal methods
formal methods
An ideal specification should be:
Correct
Complete (failing to specify what the system should do in situations that are though to be impossible.)
Consistent (not say different things in different places.)
Unambiguous (it is very difficult to write in a completely unambiguous way in any natural language. In addition ambiguity of natural languages makes it difficult to use automated methods to check if specifications are correct, complete or consistent. The problems associated with the production of unambiguous specifications may be tackled in a number of ways: 1) semiformal methods and 2) formal methods)

13. Software animation of the specification - prototyping
Faults within the specification represent one of the greatest problems in the development of safety-critical systems
inadequacies in the requirements documents
specification does not accurately reflect the requirements
Software animation can be used to illustrate various characteristics of the system defined by the specification.
Investigates particular aspects of the system rather than to satisfy the complete specification.
Involves writing software that models the system defined in a specification in order to investigate the characteristics of that specification.
This technique differs from simulation which emulates the performance of trial design.
Software animation is used to validate the specification, whereas simulation is used to investigate a design.

14. Phases of the development process
Top-level design:
Once the specification has been produced, this is used as the basis for the top-level design that defines the systems architecture.
One of the major aspect of this process is to partition the system into hardware and software.
The top-level design will split the project into a number of more manageable modules to simplify the design and testing processes.
Specifications will than be produced for each module and later used for module testing.
Once the specification has been produced, this is used as the basis for the top-level design that defines the systems architecture.
The top-level design will split the project into a number of more manageable modules to simplify the design and testing processes. Specifications will than be produced for each module and later used for module testing.

15. Phases of the development process
Detailed design:
Top-level design is followed by the detailed design of both the hardware and the software for each of the modules.
Often the process of decomposition is iterative, which modules being broken into successively smaller sub modules, each with its own specification.
Module implementation / Module test:
When the design stage is complete the modules are constructed and tested individually.
Testing methods may be divided into :
Dynamic techniques: involves operating and executing the module to investigate its characteristics
Static techniques: looks at the characteristics of the module without executing it (design reviews, code walkthroughs)
This testing forms part of the process of verification which is used to establish that each module satisfies its specification.
Top-level design is followed by the detailed design of both the hardware and the software for each of the modules. When the design stage is complete the modules are constructed and tested individually. This testing forms part of the process of verification which is used to establish that each module satisfies its specification.

16. Phases of the development process
System integration:
Once the various modules have been completed and verified, the process of system integration may begin. This can be done by various approaches:
Progressively integration: here a small number of modules are combined to make a minimal system, which is then tested and any problems removed. Additional modules are then added successively, performing testing at each stage. This process continues until the system is complete.
Big-bang approach: here all the modules are combined immediately and the complete system is tested.
Once the various modules have been completed and verified, the process of system integration may begin. This can be done by various approaches: 1) Progressively integration, where more and more modules being combined and tested, 2) big-bang approach, where the complete system is assembled and tested as a whole.

17. Phases of the development process
System test (verification and validation):
Once the system is complete and appears to be functioning correctly, the verification and validation of the entire system may begin.
Verification: the process of determining that the system, or module, meets its specification.
Validation: the process of determining that the system is appropriate for its purpose.
From these definitions we see that verification seeks to show that the system corresponds to its specification, whereas the validation sets out to determine whether the system as a whole accurately meets the requirements of the user. It therefore includes considerations of the correctness of the specification itself.
Once the system is complete and appears to be functioning correctly, the verification and validation of the entire system may begin.
Verification: the process of determining that the system, or module, meets its specification.
Validation: the process of determining that the system is appropriate for its purpose.
From these definitions we see that verification seeks to show that the system corresponds to its specification, whereas the validation sets out to determine whether the system as a whole accurately meets the requirements of the user. It therefore includes considerations of the correctness of the specification itself.

18. Phases of the development process
Certification:
For highly critical systems the final stage is to convince some external regulating body that the system is safe and thereby to achieve certification.
This will necessitate the provision of documentary evidence to support all aspects of work, and full details on the tests and their results.
For this reason the certification process must be planned at the beginning of the project.
It is a benefit to use standards and guidelines during development, in order to achieve certification.
For highly critical systems the final stage is to convince some external regulating body that the system is safe and thereby to achieve certification. It is a benefit to use standards and guidelines during development, in order to achieve certification.

19. Safety analysis
Safety analysis is the process of assessing the safety of a system by looking at the associated hazards and the methods used by the system to cope with them
In IEC this subject is referred to as overall safety validation
The major components of the safety analysis process are described in the UK Health and Safety Executive (HSE) guidelines and other standards.

20. Safety analysis The main activities in a safety analysis process are:
Analyse the hazards
Identify the potential hazards
Evaluate the event leading to these hazards
Identify the safety-related systems within the plant
Decide on the required level of safety integrity for the safety-related systems
Design the safety-related systems using the safety integrity criteria appropriate for the specific application
Carry out safety integrity analysis to assess the level of safety integrity achieved by the safety-related systems
Ensure, from the analysis of 5, that the integrity levels of 3 have been achieved.
Safety analysis is an ongoing process that continues throughout the lifecycle.
Hovedaktivitetene i en ”safety analysis process” er:
1) Analyser hasardene.
a) identifiser potensielle hasarder.
b) evaluer hendelsene som leder til disse hasardene.
2) Identifiser ”safety-related” systemer.
3) Sett sikkerhetsnivå (safety integrity level) for disse systemene.
4) Design systemet ved å benytte kriteriene som ligger til grunn for det sikkerhetsnivået som er satt.
5) Utfør en sikkerhetsnivåanalyse som fastsetter hvilket sikkerhetsnivå som systemet har oppnådd.
6) Forsikre, utifra resultatene i analysen i 5), at sikkerhetsnivået som ble satt i 3) har blitt oppnådd.
Sikkerhetsanalyse er en vedvarende prosess som fortsetter igjennom hele utviklingsprosessen.

21. Exercises
Chapter 5: 1, 6, 7, 9, 10, 11, 12, 13, 18, 23
Chapter 6: 3, 4, 14, 15, 16, 17, 18, 34, 35, 36, 37, 38