1. Safety-Critical Systems 6 Certification

2. Quality Management
Quality and systematic actions to gain it, are essential for producing a safety system.
Quality = Product or service satisfies needs
Standards - ISO 9001

3. Certification
Prosess to indicate conformance with a standard – checked by an authorised body.
National Safety Authority, Goverment
International institutes, certified bodies
Follow given guidelines, like IEC 1508 or CENELEC norms

4. Safety-Critical Systems Summary

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

6. I - Requirements
Requirements are stakeholders (customer) demands – what they want the system to do.
Not defining how !!! => specification
Safety requirements are defining what the system must do and must not do in order to ensure safety. Both positive and negative functionality.

7. I - Requirement Engineering Right Requirements
Ways to refine Requirements
- complete – linking to hazards (possible dangerous events)
- correct – testing & modelling
- consistent – semi/formal language
- unambiguous – text in real English

8. I - Semi-formal Requirements
Requirements should be inambigious, complete, consistent and correct.
Natural language has the intepretation possibility. More accurate description needed.
Using pure mathematic notation – not always suitable for communication with domain expert.
Formalised Methods are used to tackle the requirement engineering. (Structured text, formalised English).

9. I - Hazard formalisation

10. I – Multiple Hazards

11. I - Hazard example

12. I - Hazard Analysis
A Hazard is situation in which there is actual or potential danger to people or to environment.
Analytical techniques:
- Failure modes and effects analysis (FMEA)
- Failure modes, effects and criticality analysis (FMECA)
- Hazard and operability studies (HAZOP)
- Event tree analysis (ETA)
- Fault tree analysis (FTA)

13. Fault Tree Analysis 1
The diagram shows a heater controller for a tank of toxic liquid. The computer controls the heater using a power switch on the basis of information obtained from a temperature sensor. The sensor is connected to the computer via an electronic interface that supplies a binary signal indicating when the liquid is up to its required temperature. The top event of the fault tree is the liquid being heated above its required temperature.

14. Fault event not
fully traced to its source
Basic event, input
Fault event resulting
from other events
OR connection

15. I - Risk Analysis
Risk is a combination of the severity (class) and frequency (probability) of the hazardous event.
Risk Analysis is a process of evaluating the probability of hazardous events.
The Value of life??
Value of life is estimated between 0.75M –2M GBP.
USA numbers higher.

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

17. II - Designing for Safety 1
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)

18. II - Designing for Safety 2
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
Human error
- Proper HMI

19. II Design - Fault Tolerance
Fault tolerance hardware - Achieved mainly by redundancy Redundancy - Adds cost, weight, power consumption, complexity Other means: - Improved maintenance, single system with better materials (higher MTBF)

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

21. III - Safety-Critical Software 1
Correct Program:
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 – Needs an assessment process: dynamic/static testing, simulation, code analysis and formal verification.

22. III - Safety-Critical Software 2
Dependable Software :
Process for development
Work discipline
Well documented
Quality management
Validated/verificated

23. III - Safety-Critical Software 3
Designing Principles
Use hardware interlocks before computer/software
New software features add complexity, try to keep software simple
Plan for avoiding human error – unambigious human-computer interface
Removal of hazardous module (Ariane 5 unused code)

24. III - Safety-Critical Software 4
Designing Principles
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. III - Safety-Critical Software 5
Designing Principles:
Fault tolerance: Recovery blocks – if one module fails, execute alternative module.
Don‘t relay on run-time systems

26. III - Safety-Critical Software 6
Reduction of Hazardous Conditions -summary
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

27. Verified software process

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

29. Testing
Testing is a process used to verify or validate system or its components.
Testing is performed during various stage of system development. V-lifecycle diagram.
Module testing – evaluation of a small function of the hardware/software.
System integration testing – investigates correct interaction of modules.
System validation testing – a complete system satisfies its requirements.

30. Home assignments 1.12 (primary, functional and indirect safety)
2.4 (unavailability)
4.18 (tolerable risk)
5.10 (incompleteness within specification)
7.15 (reliability model)
9.17 (reuse of software)
11.2 Textual specification
Z-language
Dynamic testing
12.20 Constructed environment
Please your home assignments by 12 May 2005 to
References: OFFIS, I-Logix, KnowGravity