Developing safety critical systems

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.

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 61508 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.

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 61508 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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 61508 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.

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