Safety-Critical Systems 3

T 79.232

Designing Safety Software

Ilkka Herttua

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

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

Improved Development Process

Intergrated Development Process

Verified software process

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.

Safety-Critical Software

Dependable Software :

- Process for development

- Work discipline

- Well documented

- Quality management

- Validated/verificated

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.

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.

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

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.

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.

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.

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)

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

Safety-Critical Software

Designing Principles:

- Fault tolerance: Recovery blocks – if one module fails, execute alternative module.

- Don‘t relay on run-time systems

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

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.

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

Practical Design Process

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)

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)

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

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

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