SafetyCritical Systems 6 Quality Management and Certification - PowerPoint PPT Presentation

About This Presentation
Title:

SafetyCritical Systems 6 Quality Management and Certification

Description:

Systematic actions to gain quality,which is essential in the life cycle of a ... systems and equipment that complies with accepted airworthiness requirements. ... – PowerPoint PPT presentation

Number of Views:71
Avg rating:3.0/5.0
Slides: 39
Provided by: CT5
Category:

less

Transcript and Presenter's Notes

Title: SafetyCritical Systems 6 Quality Management and Certification


1
Safety-Critical Systems 6Quality Management and
Certification
  • T 79.5303

2
Quality Management
  • Systematic actions to gain quality,which is
    essential in the life cycle of a safety system.
  • Quality Assurance
  • - concentrates that manufacture prosess and
    work are performed correctly.
  • Quality Control
  • - ensures that product is correct.

3
ISO 9000Quality Management System
  • International Organisation for Standardisation
    (ISO) created the Quality Management System (QMS)
    basis already in 1987.
  • ISO 90011987 Model for quality assurance in
    design, development, production, installation and
    servicing.
  • ISO 90021987 Model for quality assurance in
    production, installation and servicing.
  • ISO 90031987 Model for quality assurance in
    final inspection and test covered only the final
    inspection of finished product.

4
ISO 9001
  • ISO 90002000 combines the three standards 9001,
    9002, and 9003 into one, now called 9001.
  • Design and development procedures are required
    only if a company does in fact engage in the
    creation of new products.
  • New version has a goal to improve effectiveness
    via process performance metrics numerical
    measurement of the effectiveness of tasks and
    activities.

5
ISO 9001
  • A company or organization that has been
    independently audited and certified to be in
    conformance with ISO 9001 may publicly state that
    it is "ISO 9001 certified" or "ISO 9001
    registered."
  • Certification to an ISO 9000 standard does not
    guarantee the compliance (and therefore the
    quality) of end products and services rather, it
    certifies that consistent business processes are
    being applied.
  • ISO 9001 is not enough and more strict systems
    are needed. These are described on norms, which
    have to be followed according to get system
    certificated.

6
ISO 9001 System
  • The requirements in ISO 9001 include
  • a set of procedures that cover all key processes
    in the business
  • monitoring manufacturing processes to ensure
    manufactures are producing quality produce
  • keeping proper records
  • checking outgoing product for defects, with
    appropriate corrective action where necessary
  • regularly reviewing individual processes and the
    quality system itself for effectiveness.

7
Certification
  • Process to indicate conformance with a standard
    checked by an authorised body.
  • National Safety Authority, Minister of
    Transportation
  • International institutes and certified /notified
    bodies in EU
  • Follow given guidelines, like DO-178B, IEC 61508
    or CENELEC norms.

8
(No Transcript)
9
Example in Avionic systemDO-178B Certification
  • DO-178B provides the aviation community with
    guidelines for developing software for airborne
    systems and equipment that complies with accepted
    airworthiness requirements.
  • Five software levels (A through E), Level A is
    the most stringent.

10
(No Transcript)
11
DO-178B Certification
The number of objectives to be satisfied. In the
standard, "with independence" refers to a
separation of responsibilities where the
person(s) who verify an objective must not be the
developers of the item in question. In some
cases, an automated tool may be equivalent to
independence.
12
Safety-Critical Systems Summary

13
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
14
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.
  •  

15
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
  •  

16
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).

17
I - Hazard formalisation
18
I Multiple Hazards
19
I - Hazard example
20
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)

21
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.
 
22
Fault event not fully traced to its source
Basic event, input
Fault event resulting from other events
OR connection
23
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.

24
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
25
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)

26
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

27

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)

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

30
III - Safety-Critical Software 2
  • Dependable Software
  • Process for development
  • Work discipline
  • Well documented
  • Quality management
  • Validated/verificated

31
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)

32
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

33
III - Safety-Critical Software 5
  • Designing Principles
  • Fault tolerance Recovery blocks if one module
    fails, execute alternative module.
  • Dont relay on run-time systems

34
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

35
Verified software process
36
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
37
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.

38
Home assignments
  • 1.12 (primary, functional and indirect safety)
  • 2.4 (unavailability)
  • 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
  • Please email your home assignments by 26 April
    2007 to herttua_at_uic.asso.fr
  • References OFFIS, I-Logix, KnowGravity
Write a Comment
User Comments (0)
About PowerShow.com