1 / 27

Safety-Critical Systems 3

Safety-Critical Systems 3. T 79.232 Designing Safety Software Ilkka Herttua. Requirements Model. Requirements Analysis. Test Scenarios. Test Scenarios. System Acceptance. Requirements Document. Functional / Architechural - Model. System Integration & Test. Systems

bellini-fadden
Télécharger la présentation

Safety-Critical Systems 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Safety-Critical Systems 3 T 79.232 Designing Safety Software Ilkka Herttua

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

  3. Common Software Development Process (By I-Logix tool manufacture – Statemate)

  4. Improved Development Process

  5. Intergrated Development Process

  6. Verified software process

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

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

  9. Safety-Critical Software Safety-Critical Programming Language: Logical soundness: Unambigous definition of the language- no dialects of C++ Simple definition: 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 definition: 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.

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

  11. 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 evalution errors: Divide-by-zero/arithmetic overflow

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

  13. Safety-Critical Software Languages used : Boeing uses mostly Ada, but still for type 747-400 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.

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

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

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

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

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

  19. Safety-Critical Software Software 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 od the people involved and also determine the likelihiid 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.

  20. Safety-Critical Software Architectural design: Layered structure 1 - High level command and control functions 2 – Intermediate level routines 3 – I/O routines and device driver

  21. Practical Design Process

  22. Safety-Critical Software Architectural design: -Designis done after partitioning of the required functions on hardware and software. - Complete specification of the architecture with components, data structures and interfaces (messages/protocols)

  23. Safety-Critical Software Architectural design: Test plan for each module (testability) Human-computer interface Change control system needed for inconsistencies and inadequacies within specification. Verification of the architectural design against specification Software partitioning: modular aids comprehension and isolation (fault limiting)

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

  25. Safety-Critical Software Home assignments 3 : 7.15 (reliability model) 9.17 (reuse of software) Please email to herttua@eurolock.org by 23 of March 2005

  26. T 79.232 • New schedule for spring lectures/case studies 9 March 2005 Case Study 16 March 2005 Case Study 23 March 2005 Lecture – Formal Methods 6 April 2005 Lecture – Testing &Verification 13 April 2005 Case Study 20 April 2005 Lecture - Tools and Application 27 April 2005 Summary

More Related