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