1. Safety Critical Systems
Design for safety hardware and software
Ilkka Herttua

2. V - Lifecycle model Knowledge Base * Requirements Test Scenarios
System
Acceptance
Integration & Test
Module
Requirements
Analysis
Requirements Model
Test Scenarios
Software
Implementation
& Unit Test
Design
Document
Systems
Analysis & Design
Functional /
Architechural - Model
Specification
Knowledge Base *
* Configuration controlled Knowledge
that is increasing in Understanding
until Completion of the System:
Requirements Documentation
Requirements Traceability
Model Data/Parameters
Test Definition/Vectors

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

4. Designing for Safety 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. 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)

6. Fault Tolerance
Fault tolerance hardware - Achieved mainly by redundancy - Adds cost, weight, power consumption, complexity Other means: - Improved maintenance, single system with better materials (higher mean time between failure - MTBF)

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

8. Hardware redundancy techniques
Active techniques:
Parallel (k of N)
Voting (majority/simple)
Standby techniques :
Operating - hot stand by
Non-operating – cold stand by

9. Hardware reliability prediction
Electronic Components
Based on probability and statistical
MIL-Handbook 217 – experimental data on actual device behaviour
Manufacture information and allocated circuit types
Bath tube curve; burn in – useful life – wear out

10. Safety Critical Hardware
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

11. Safety Critical Hardware
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.

12. Safety Critical Hardware
2. Special reliable Microprocessors
Collins Avionics/Rockwell AAMP2
Used in Boeing (30+ pieces)
High cost – bench testing, documentation, formal verification
Other models: SparcV7, TSC695E, ERC32 (ESA radiation-tolerant), 68HC908GP32 (airbag)

13. Safety Critical Hardware
3. Programmable Logic Controllers (PLC)
Contains power supply, interface and one or more processors.
Designed for high mean time between failure (MTBF)
Solid Firmware
Program stored in EEPROMS
Programmed with ladder or function block diagrams

14. Safety Critical Software
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.

15. Safety Critical Software
Dependable Software :
Process for development
Work discipline
Well documented
Quality management
Validated/verified

16. Safety-Critical Software
Software faults:
Requirements defects: failure of software requirements to specify the environment in which the software will be used or unambiguous requirements
Design defects: not satisfying the requirements or documentation defects
Code defects: Failure of code to conform to software designs.

17. Safety-Critical Software
Software faults:
Subprogram effects: Definition of a called variable may be changed.
Definitions aliasing: Names refer to the same storage location.
Initialising failures: Variables are used before assigned values.
Memory management: Buffer, stack and memory overflows
Expression evaluation errors: Divide-by-zero/arithmetic overflow

18. Safety Critical Software
Safety Critical Programming Language:
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.

19. 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)
Validated compilers for Pascal and Ada
Available expertise: with common languages higher productivity and fewer mistakes, but C still not appropriate.

20. Safety Critical Software
Languages used :
Boeing uses mostly Ada, but still for type about 75 languages 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.

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

23. Safety Critical Software
Designing Principles 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)

24. Safety Critical Software
Designing Principles 2
Add barriers: hard/software locks for critical parts
Minimise single point failures: increase safety margins, exploit redundancy and allow recovery.
Isolate failures: don‘t let things get worse.
Fail-safe: panic shut-downs, watchdog code
Avoid common mode failures: Use diversity – different programmers, n-version programming

25. Safety Critical Software
Designing Principles 3
Fault tolerance: Recovery blocks – if one module fails, execute alternative module.
Don‘t relay on run-time systems

26. Safety-Critical Software
Techniques/Tools:
Fault prevention: Preventing the introduction or occurrence of faults by using design supporting tools (UML with CASE tool)
Fault removal: Testing, debugging and code modification

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

28. Practical Design Process (By I-Logix tool manufacture – Statemate)

29. Improved Development Process

30. Intergrated Development Process

31. Verified software process

32. Safety Critical Software
Reduction of Hazardous Conditions
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

33. Home assignments 2 a Cont.
Neil Storey’s book: Safety Critical Computer Systems
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.

34. Home assignments 2 b Email by 1. March to herttua@eurolock.org
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.
by 1. March to
0,7
0,7
0,9
0,7
0,98
0,97
0,99