Know or Go Practical Quest for Reliable Software

Size: px

Start display at page:

Download "Know or Go Practical Quest for Reliable Software"

Bartholomew Atkinson
8 years ago
Views:

1 Know or Go Practical Quest for Reliable Software Dr.-Ing. Jörg Barrho Dr.-Ing. Ulrich Wünsche AVACS Project meeting Rolls-Royce Power Systems AG The information in this document is the property of Rolls-Royce Power Systems AG and may not be copied or communicated to a third party, or used for any purpose other than that for which it is supplied without the express written consent of Rolls-Royce Power Systems AG. This information is given in good faith based upon the latest information available to Rolls-Royce Power Systems AG, no warranty or representation is given concerning such information, which must not be taken as establishing any contractual or other commitment binding upon Rolls-Royce Power Systems AG or any of its subsidiary or associated companies. The ROLLS-ROYCE Name, RR badge and RR monogram logos are registered Trade Marks of Rolls-Royce plc.

other than that for which it is supplied without the express written consent of Rolls-Royce Power Systems AG.

2 Contents Rolls-Royce Power Systems Development of safety critical software Risk Analysis Risk Minimization Limits of support Conclusion 2

3 Our Products Rolls-Royce Power Systems AG High-speed Engines Distributed Energy Systems Medium-speed Engines Components Bergen Engines AS Complete Drive and Propulsion Systems up to 10,000 kw Gas Gensets up to 2,530 kw Diesel Gensets up to 3,250 kw Diesel Gensets for NPP up to 8,300 kw Diesel and Gas Engines up to 9,620 kw Injection Systems 3

Propulsion Systems up to 10,000 kw Gas Gensets up to 2,530 kw Diesel Gensets up to

4 Diverse Product Portfolio Propulsion & Power Generation Marine & Offshore Governmental C&I, Agriculture Underground Mining 4 Rail, Mining, Oil & Gas Power Generation

5 Diverse Product Portfolio Energy Solutions & Marine Medium Speed Bergen Engines AS Components Nuclear Power Plants Energy Solutions & Marine Medium Speed Injection Systems 5

6 Objects of IEC60880 In safety critical Instrumentation & Control systems for nuclear power plants software must be developed according to the recognized standard IEC The standard provides requirements for the purpose of achieving highly reliable software. It addresses each stage of software generation and documentation, including: Requirements specification Design Implementation Verification, validation Operation 6

The standard provides requirements for the purpose of achieving highly reliable software.

7 Provide Evidence to Trust Know Highly reliable software means RELIABLE SOFTWARE Each work product must be checked thoroughly After best analysis no doubt shall remain Proofs provide best evidence Or go Identify sources of doubt and remove root causes Fight failures systematically The unsuspecting will not stay in project for long 7

remain Proofs provide best evidence Or go Identify sources of doubt and remove root

8 Safety Playground Process Conventional New Natural Language Interpretation Language sub set Manual process Debugging Trust commercial tools Review Dynamic sampling Requirements Specification Implementation Compilation Test Formal language Automatic test possible Qualified code generator skipped Verified tool Automatic Static proof 8

Requirements Specification Implementation Compilation Test Formal language

9 Risk Driven by Six Categories Data access conflict Data initialization, data out of range, type conversion, invalid pointers, data alignment, array sizes Defective operation Rounding, overflow, /0, scaling, side effects, precedence/execution order, array ranges Design error Specification incomplete, hardware access, specified execution order, abstraction level of specification Tool based errors Compiler faults/undefined behaviour, data coherence (prototypes, data declarations) Error handling Unhandled interrupts, error detection (reporting, default behaviour) Runtime limits Loop iteration count, excessive runtime, deadlocks 9

access, specified execution order, abstraction level of specification Tool based errors Compiler faults/undefined behaviour, data coherence (prototypes, data

10 Procedural Coding: 71 Risks 10

11 Model Based: 27 Risks Remain 11

12 Detection Still Very Conventional Risk Category Method Data access conflict Defective operation Design error Tool based Error Handling Runtime limits Verification Static Analysis Execution Time check 3 3 Stack check 1 1 Rules check Dynamic test Manual checks 62/109: Verification, Dynamic test, 20 % of rules check 12

Static Analysis 1 9 17 27 Execution Time check 3 3 Stack check 1 1 Rules check 5 14 19 Dynamic

13 Properties to be Ensured Worst Case Execution Time Consumption of Memory (program/const and variable/stack) Absence of run time errors - division by 0, - numerical overflow, - access out of bounds Functional Properties Check of defined coding risk reductions (language subset) 13

- division by 0, - numerical overflow, - access out of bounds

14 Tool objectives Tool usability, support, and certifiability Tool resource consumption - Limitation in space consumption - Limitation in tool runtime Tool impact increases with - Quality of results (less false-positives, etc.) - Effectiveness Development process shall be accompanied by the tool - [Simplicity in use] 14

impact increases with - Quality of results (less false-positives, etc.

15 C Language Subset ANSI C ISO 9899:1989 => well used paths in compiler No floating point data (as int as possible) => integer promotion far from common sense No bitfields => allocation compiler specific No unions => ambiguous access methods No pointer arithmetics => bounds hard to identify No function pointers => traceability Control flow preferred over data driven => Better understanding Defined structure and formatting => reading focus on contents However: No quantitative figures on effects of measures available Code accessible to static analysis 15

to identify No function pointers => traceability Control flow preferred over data driven => Better understanding Defined structure and

16 Using Compilers is Dangerous The Situation Virtually all commercially available compilers have bugs Source code checks need continuous updating due to newly identified limiting rules Applying a test suite strongly binds to set of compiler flags Conventional Attempt for Resolution Compiler validation for limited language subset offered Compiler code coverage in validation is low One just cannot be sure Or a different approach Compcert (with subset preprocessor and validated assemblylinkage)? 16

Conventional Attempt for Resolution Compiler validation for limited language subset offered Compiler code coverage in

17 Formal Specification in Frama-C /** Calculate Delta speed demand by processing speed-up and speed-down buttons.*/ requires -200 <= t_speedhold <= 200; assigns t_speedhold; behavior SpeedConst: assumes SpeedDown == 0; assumes SpeedUp == 0; ensures \result == 0; [..] behavior SpeedD1: assumes SpeedDown!= 0; assumes SpeedHold >= 0; ensures \result == -ENGINE_SPEED_SCALE; ensures t_speedhold == -1; [..] behavior SpeedU1: assumes SpeedDown == 0; assumes SpeedUp!= 0; assumes t_speedhold <= 0; ensures \result == ENGINE_SPEED_SCALE; ensures t_speedhold == 1; [..] complete behaviors; disjoint behaviors; */ Ansi C specification language ACSL Permits formal specification of behaviors Behavior proven vs. Abstract syntax tree Well possible for simple functions But Difficult to read for the untrained programmer Yet another tool Why not generate proven code from spec automatically? 17

$= 0; assumes SpeedHold >= 0; ensures \result == -ENGINE_SPEED_SCALE; ensures t_speedhold == -1; [..] behavior SpeedU1: assumes SpeedDown == 0; assumes SpeedUp!$

18 Challenges Abstract Interpretation Control-driven vs data-flow driven algorithms - Control-flow driven designs Require less annotations Provide more precise results Model-generated code (e.g., SCADE) - Automation by integration required Function pointers and pointer arithmetics - Increase false-positives especially if pointers are shared over different calling contexts 18

19 Example: Signal Debouncing Propagate a logical TRUE iff Condition is TRUE for more than CountMax cycles Using a design verifier to prove absence of overflows with - Condition in [FALSE, TRUE] - CountMax in [1, INT32_MAX 1] is not feasible (after 15h of runtime and more 70GB of space consumption) 19

overflows with - Condition in [FALSE, TRUE] - CountMax in [1, INT32_MAX 1]

20 Concurrency Runaway Auto Synchronous Thread Interrupt Thread Pointer gets lost void Func1(void) { int a[3]; Func2(a); } static int *c; void Func2(int* b) { c=b; } void Func3(void) { /* use c */ } Version works better static int c[3]; void Func2(int b[3]) { int i; for(i=0;i<3;i++) c[i]=b[i]; } void Func3(void) { /* use c */ } 20

} void Func3(void) { /* use c */ } Version works better static int c[3]; void

21 Data Driven Code Hard to Check Stimulated regularly, s in [0..4]; Using interval domains: code coverage ok a[1] never accessed => dead data int f(int s) { struct { int b,c; } a[3] = {{ 1, 2 }, { 2, 999 }, { 5, 0 }}; } static int t=0; if(s==a[t].b) t=a[t].c; return t; 21

22 Post Proof Debugging Coders and testers do not always believe in proofs Known fact: {x x N}: (2 * x) & 1 = 0 If the practical case is x=5 humans still check if 10 is an even number Assumption In software development everything is uncertain until each specific case is investigated (which is impossible in finite time). 22

23 Failure Culture: Fight until Done Failure count per module Singular case Specific to one module F Failures favourite biotope One specific type Number of modules 23

24 Conclusion Reliable software is product of risk minimization Prevention before Detection Commercially available analysis tools support safety process Specification error avoidance hardly available Still manual effort prevailing Provable compliance is not within reach yet 24

25 Quellen [IEC60880]: IEC60880:2006: Nuclear power plants Instrumentation and control systems important to safety Software aspects for computer-based system performing category A functions 25

Anwendung von Polyspace im Software Entwicklungsprozess nach IEC 60880. München, 19.05.2011, Dr.-Ing. Jörg Barrho

Anwendung von Polyspace im Software Entwicklungsprozess nach IEC 60880 München, 19.05.2011, Dr.-Ing. Jörg Barrho Agenda 01 Tognum and MTU Friedrichshafen 02 Background and project 03 Overview IEC 60880