Safety-Critical Systems 6 Certification

1
Safety-Critical Systems 6Certification

• T 79.232

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
Requirements Model
Requirements Analysis
Test Scenarios
Test Scenarios
System Acceptance
Requirements Document
Functional / Architechural - Model
System Integration Test
Systems Analysis Design
Specification Document
Software Design
Module Integration Test
Software Implementation Unit Test
6
I - Requirements

• Requirements are stakeholders (customer) demands
  what they want the system to do.
• Not defining how !!! gt 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
Requirements Model
Requirements Analysis
Test Scenarios
Test Scenarios
System Acceptance
Requirements Document
Functional / Architechural - Model
System Integration Test
Systems Analysis Design
Specification Document
Software Design
Module Integration Test
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, complexityOther means- Improved
  maintenance, single system with better materials
  (higher MTBF)

20
V - Lifecycle model
Requirements Model
Requirements Analysis
Test Scenarios
Test Scenarios
System Acceptance
Requirements Document
Functional / Architechural - Model
System Integration Test
Systems Analysis Design
Specification Document
Software Design
Module Integration Test
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 dont 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.
• Dont 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
Requirements Model
Requirements Analysis
Test Scenarios
Test Scenarios
System Acceptance
Requirements Document
Functional / Architechural - Model
System Integration Test
Systems Analysis Design
Specification Document
Software Design
Module Integration Test
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
• 11.18 Z-language
• 12.7 Dynamic testing
• 12.20 Constructed environment
• Please email your home assignments by 12 May 2005
  to herttua_at_eurolock.org
• References OFFIS, I-Logix, KnowGravity