Safety%20Critical%20Systems

1
Safety Critical Systems

• T 79.5303
• Safeware - Design for safety hardware and
  software
• Ilkka Herttua

2
V - Lifecycle model
3
Designing for Safety (Analyse)

• Faults groups
• - requirement/specification errors
• - random component failures
• - systematic faults in design (software -
  process)
• Approaches to tackle problems
• - right system architecture (fault-tolerant)
• - reliability engineering (component, system)
• - quality management (designing and producing
  processes)

4
Designing for Safety (Architecture)

• Hierarchical design
• - simple modules, encapsulated functionality
• - separated safety kernel safety critical
  functions
• Maintainability
• - preventative versa corrective maintenance
• - scheduled maintenance routines for whole
  lifecycle
• - easy to find faults and repair short MTTR
  (mean time to repair)
• Reduce human error
• - Proper HMI

5
HardwareComponent reliability prediction

• Electronic Components
• Based on probability calculation and statistical
  data
• MIL-Handbook 217 experimental data on actual
  device behaviour
• Manufacture information and allocated circuit
  types
• Bath tube curve burn in useful life wear out

6
HardwareBath tube curve

7
Hardware Faults

• Intermittent faults
• Fault occurs and recurs over time (loose
  connector)
• Transient faults
• Fault occurs and may not recur (lightning)
• Electromagnetic interference
• Permanent faults
• Fault persists / physical processor failure
  (design fault over current or temperature)

8
Safety Critical System

• Fault Detection
• Routines to check that hardware works
• Signal comparisons
• Information redundancy parity check etc..
• Watchdog timers
• Bus monitoring check that processor alive
• Power monitoring

9

Hardware Design Guideline

• Fault tolerance hardware- Achieved mainly by
  redundancy- Adds cost, weight, power
  consumption, complexityOther means- Improved
  maintenance, single system with better materials
  (higher mean time between failure - MTBF)

10
Redundancy Methods

• Active Redundancy
• Redundant units are always operating in parallel
• Dynamic Redundancy (standby)
• Failure has to be detected
• Changeover to other module

11
Hardware redundancy techniques

• Active techniques
• Parallel (k of N)
• Voting (majority/simple)
• Standby techniques
• Operating - hot stand by
• Non-operating cold stand by

12
Redundancy Techniques
13
Simple Parallel RedundancyActive - Type 1
In its simplest form, redundancy consists of a
simple parallel combination of elements. If any
element fails open, identical paths exist through
parallel redundant elements.
14
Duplex Parallel RedundancyActive - Type 2
This technique is applied to redundant logic
sections, such as A1 and A2 operating in
parallel. It is primarily used in computer
applications where A1 and A2 can be used in
duplex or active redundant modes or as a separate
element. An error detector at the output of each
logic section detects noncoincident outputs and
starts a diagnostic routine to determine and
disable the faulty element.
15
Simple Majority VotingActive - Type 4
Decision can be built into the basic parallel
redundant model by inputting signals from
parallel elements into a voter to compare each
signal with remaining signals. Valid decisions
are made only if the number of useful elements
exceeds the failed elements.
16
Non-Operating RedundancyStandby - Type 7
A particular redundant element of a parallel
configuration can be switched into an active
circuit by connecting outputs of each element to
switch poles. Two switching configurations are
possible. 1) The element may be isolated by the
switch until switching is completed and power
applied to the element in the switching
operation. 2) All redundant elements are
continuously connected to the circuit and a
single redundant element activated by switching
power to it.
17
Safety Critical Hardware

• Avoid commercial microprocessors
• - No safety firmware, least assurance
• Redundancy makes better, but common failures
  possible
• Fabrication failures, microcode and
  documentation errors
• Use components which have history and
  statistics.

18
Safety Critical Hardware

• 2. Use special reliable microprocessors
• Collins Avionics/Rockwell AAMP2
• Used in Boeing 747-400 (30 pieces)
• High cost bench testing, documentation, formal
  verified functionality
• Other models SparcV7, TSC695E, ERC32 (ESA
  radiation-tolerant), 68HC908GP32 (airbag)

19
Safety Critical Hardware

• 3. Programmable Logic Controllers (PLC)
• Contains power supply, interface and one or more
  processors, used in industrial application -
  chemical processes, infrastructure control
  water, heat, electricity
• Designed for high mean time between failure
  (MTBF)
• Solid Firmware and application software stored
  in non volatile memory
• Programmed with simple ladder or function block
  diagrams

20
SoftwareProcess guideline

• Software development
• Normally iteration is needed to develop a
  working solution. (writing code, testing and
  modification).
• In non-critical environment code is accepted,
  when tests are passed.
• Testing is not enough for safety critical
  application Software needs an assessment
  process dynamic/static testing, simulation, code
  analysis and formal verification.

21
Safety Critical Software Dependable and High
Quality

• Detailed Process plan for the whole development
  and testing phases
• Work discipline recorded supervision
• Well documented easier to validate
• Quality management
• Validated/verified

22
Safety-Critical Software Faults

• - In Requirements requirements are not
  specifying the environment in which the software
  will be used or unambiguous requirements
• In Design not satisfying the requirements or
  documentation insufficient
• In Code generated code is not conforming with
  the design.

23
Safety-Critical Software

• Common faults
• Subprogram effects Definition of a called
  variable has been changed.
• Definitions aliasing Names referred to the same
  storage location.
• Initialising failures Variables have been used
  as assigned values.
• Memory management Buffer, stack and memory
  overflows
• Expression evaluation errors Divide-by-zero/arit
  hmetic overflow

24
Software

• Programming Language selection
• Logical soundness Unambiguous definition of the
  language- no dialects of C
• Simple definitions Complexity can lead to
  errors in compliers or other support tools
• Expressive power Language shall support to
  express domain features efficiently and easily
• Security of definitions Violations of the
  language definition shall be detected
• Verification Language supports verification,
  proving that the produced code is consistent with
  the specification.
• Memory/time constrains Stack, register and
  memory usage are controlled.

25
Safety Critical Software

• Language comparison
• Structured assembler (wild jumps, exhaustion of
  memory, well understood)
• Ada (wild jumps, data typing, exception
  handling, separate compilation)
• Subset languages CORAL, SPADE and Ada (Alsys
  CSMART Ada kernel, AdaCoreSpark)
• Validated compiler for Ada
• Available expertise with common languages
  higher productivity and fewer mistakes, but C
  not approved in all applications.

26
Software

• Languages used
• Avionics uses mostly Ada, but for Boeing 747-400
  about 75 languages were used.
• ESA mandated Ada for mission critical systems.
• NASA Space station in Ada, some systems with C
  and Assembler.
• Car ABS systems with Assembler.
• Train control systems with Ada..
• Medical systems with Ada and Assembler
• Nuclear Reactors core and shut down system with
  Assembler, migrating to Ada.

27
Safety Critical Software

• Tools
• High reliability and validated tools are
  required Faults in the tool can result in faults
  in the safety critical software.
• Widespread tools are better tested
• Use confirmed process of the usage of the tool
• Analyse output of the tool static analysis of
  the object code
• Use alternative products and compare results
• Use different tools (diversity) to reduce the
  likelihood of wrong test results.

28
Safety Critical Software

• Design guidelines 1
• New software features add complexity, try to
  keep software simple
• Plan for avoiding human error unambiguous
  human-computer interface
• Removal of hazardous module (Ariane 5 unused
  code)

29
Safety Critical Software

• Designing guidelines 2
• Add barriers hard/software locks for critical
  parts
• Minimise single point failures increase safety
  margins, exploit redundancy and allow recovery.
• Isolate failures dont let things get worse.
• Fail-safe panic shut-downs, watchdog code
• Avoid common mode failures Use diversity
  different programmers, n-version programming

30
Safety Critical Software

• Designing guidelines 3
• Fault tolerance Recovery blocks if one module
  fails, execute alternative module.
• Dont relay on complex operating system in most
  critical application.

31
Safety Critical Software

• Software tool faults
• - Faults in software tools (development/modelling)
  can results in system faults.
• Techniques for software development
  (language/design notation) can have a great
  impact on the performance or the people involved
  and also determine the likelihood of faults.
• The characteristics of the programming systems
  and their runtime determine how great the impact
  of possible faults on the overall software
  subsystem can be.

32
Practical Design Process (By I-Logix tool
manufacture Statemate)
33
Improved Development Process
34
Intergrated Development Process
35
Verified software process
36
Safety Critical Software

• Higher integrity software
• Simplify Code contains only minimum features
  and no unnecessary or undocumented features or
  unused executable code
• Diversity Data and control redundancy
• Multi-version programming shared specification
  leads to common-mode failures, but
  synchronisation code increases complexity

37
Home assignments 2 a

• Neil Storeys book Safety Critical Computer
  Systems
• - 5.10 Describe a common cause of incompleteness
  within specifications. How can this situation
  cause problems?
• 9.17 Describe the advantages and disadvantages of
  the reuse of software within safety critical
  projects.
• Cont.

38
Home assignments 2 b

• 7.15 A system may be described by the following
  reliability model, where the numbers within the
  boxes represent the module reliability. Calculate
  the system reliability.
• Email by 27. March to herttua_at_uic.asso.fr

0,7
0,7
0,7
0,9
0,98
0,97
0,99