safety-critical systems 6 certification t 79.232
TRANSCRIPT
![Page 1: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/1.jpg)
Safety-Critical Systems 6Certification
T 79.232
![Page 2: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/2.jpg)
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
![Page 3: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/3.jpg)
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
![Page 4: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/4.jpg)
Safety-Critical Systems Summary
![Page 5: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/5.jpg)
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:
• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors
![Page 6: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/6.jpg)
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.
![Page 7: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/7.jpg)
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
![Page 8: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/8.jpg)
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).
![Page 9: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/9.jpg)
I - Hazard formalisation
hazardous state undesired state(damage)
undesired event(accident occurence)
safe state
i.e. protection process
a
p
![Page 10: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/10.jpg)
I – Multiple Hazards
condition 1
condition 2
condition 3
Situation/Szenario A hazardous state 1 undesired state(damage 1)
undesired event(accident occurence)
safe state
i.e. protection process
a
p
hazard occurence 1
hazardous state 2 undesired state(damage 2)
undesired event(accident occurence)
safe state
i.e. protection process
a
p
hazard occurence 2
condition 4
Situation/Szenario B
HAZARD B
HAZARD A
![Page 11: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/11.jpg)
I - Hazard example
bogie or chassis failure
train/railway infrastructure information correct
correct speed set values
correct safeguarding
train speed execution is incorrect
possible derailment onflexible track element
![Page 12: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/12.jpg)
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)
![Page 13: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/13.jpg)
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.
![Page 14: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/14.jpg)
Fault event notfully traced to its source
Basic event, input
Fault event resultingfrom other events
OR connection
![Page 15: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/15.jpg)
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.
![Page 16: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/16.jpg)
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:
• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors
![Page 17: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/17.jpg)
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)
![Page 18: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/18.jpg)
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
![Page 19: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/19.jpg)
• Fault tolerance hardware- Achieved mainly by redundancy Redundancy- Adds cost, weight, power consumption, complexityOther means:- Improved maintenance, single system with better materials (higher MTBF)
II Design - Fault Tolerance
![Page 20: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/20.jpg)
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:
• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors
![Page 21: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/21.jpg)
III - Safety-Critical Software 1Correct 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.
![Page 22: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/22.jpg)
III - Safety-Critical Software 2
Dependable Software :
- Process for development
- Work discipline
- Well documented
- Quality management
- Validated/verificated
![Page 23: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/23.jpg)
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)
![Page 24: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/24.jpg)
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
![Page 25: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/25.jpg)
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
![Page 26: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/26.jpg)
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
![Page 27: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/27.jpg)
Verified software process
![Page 28: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/28.jpg)
V - Lifecycle model
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Requirements Model
Test Scenarios Test Scenarios
SoftwareImplementation
& Unit Test
SoftwareDesign
Requirements Document
Systems Analysis &
Design
Functional / Architechural - Model
Specification Document K
now
led
ge B
ase
** Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:
• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors
![Page 29: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/29.jpg)
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.
![Page 30: Safety-Critical Systems 6 Certification T 79.232](https://reader036.vdocuments.mx/reader036/viewer/2022062516/56649e6f5503460f94b6c3a2/html5/thumbnails/30.jpg)
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 [email protected]: OFFIS, I-Logix, KnowGravity