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

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

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.

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

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

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

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

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

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

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

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

22. Practical Design Process

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

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

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

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

27. 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 6April 2005 Lecture – Testing &Verification 13April 2005 Case Study 20April2005 Lecture - Tools and Application 27 April 2005 Summary