Critical software developement

Slide: 1Copyright © 2014 AdaCore

Quentin Ochem

Technical Account Manager

Critical Software Development


What is Critical Software?


Case-StudyAvionics and DO-178B


• Any software flying in the civil air space must have be certified against– DO-178B in USA– ED-12B in Europe

• Military aircraft do not need to comply to it except if they fly in the civil air space– E.g. A400 M

• Other industries have or think about similar standards (see IEC-50128)– Railroad, military, automotive, energy, medical…

DO-178B/C applications


• Certifying most parts of a plane is centered on the result– When does the wing break?– Can I get this many people out in this many time?

• It’s not possible to just “experiment” the software– Too complex

• So certifying a software is based on the process

The software certification problem


Certifying a system is showing best possible effort has been made in understanding and mastering the

environment, specification, implementation and verification

In one sentence


• The development is organized through processes• Each process describes

– Objectives– Activities

Processes

Objective Activity Applicability Output Control Category

A B C D A B C D

Test coverage of

Software Structure Is

achieved

6.4.4.2.a6.4.4.2.b6.4.4.2.d

Software Verification Results

2 2 2


• Each activity may be achieved with independence• When achieved with independence, and other

person (outside of any hierarchical dependency) need to perform verifications

Reviews and independence

Objective Activity Applicability Output Control Category

A B C D A B C D

Test coverage of

Software Structure Is

achieved

6.4.4.2.a6.4.4.2.b6.4.4.2.d

Software Verification Results

2 2 2

System RequirementsSystem Requirements

High Level Requirements


Software ArchitectureSoftware ArchitectureLow Level Requirements

Low Level Requirements

Source CodeSource Code

referencestrace

trace

references

references

trace

Executable Object Code


generates

[5] Main Development Objectives









compliancetraceability

compliance

compatibilitycompliancetraceability

compliancetraceability

[6] Main Verification Objectives (1/4)









complete and correct

verifiableconformanceaccuracy and consistency

accuracy & consistencyHW compatibility verifiability conformance

consistencyHW compatibility verifiability conformance partition integrity

accuracy & consistency HW compatibility verifiabilityconformance










compliancerobustness

compliancerobustness

compatible with target










structural and functional coverage



Tools and Constraints around the Code


• Objectives can be achieved by manual activities or automated activities

• Some activities are well suited to automation– E.g. Code standard checker, coverage analysis, stack analysis…

• If a tool replaces a manual activity, it must be qualified

• Qualification is a lighter certification process

Tool Support


Verification - Static Analysis

• Coding Standard Verification

• Stack Usage

• Worst Case Execution Time

• Run-Time Error Analysis

• Formal Proof


Verification - Dynamic Analysis Tools

• Unit Testing

• Structural Code Coverage

• Stack Usage (!)

• Worst Case Execution Time (!)


Structural Coverage Analysis

• Statement coverage– Each line of code is tested

• Decision coverage– Each decision (boolean expression) is tested True and False

• Modified Condition / Decision coverage (MC/DC)– Each condition (operand of a boolean expression) can

change the result of the decision


DO-178 – Structural Coverage Example (1/2)

Coverage function Sep (X : Character) return Boolean is

Result : Boolean := False;begin if X = ‘/’ or else X = ‘\’ or else X = ‘:’ then Result := True; end if; return Result;end Sep;

Statement coverage -> call with any X

Decision coverage -> test X = ‘:’ and X = ‘z’


DO-178 – Structural Coverage Example (2/2)

MC/DC if X = ‘/’ or else X = ‘\’ or else X = ‘:’ then

Cond1:X = ‘/’ => TFF => TRUEX = ‘z’ => FFF => FALSE

Cond2X = ‘\’ => FTF => TRUEX = ‘y’ => FFF => FALSE

Cond3X = ‘y’ => FFF => FALSEX = ‘:’ => FFT => TRUE

There is a redundant test here (FFF). 4 tests would be enough.

In general n + 1 test are enough to test an expression of n conditions


• No dynamic allocation / pointers

• No exceptions

• No object orientation (except if…)

• No non-deterministic behavior

• Limited or no use of the run-time

• Explicit coding standard

• …

Typical Code Constraints


• Local Type Substitutability is a new objective in DO-332, allowing the use of object orientation and dispatching calls

• It relies on a demonstration of consistency between overriding methods which can be verified by testing or formal analysis

• Given a dispatching call from a Root type to one of its methods …

• … at run-time, it’s OK to call an overridden method of a child if– The child method precondition does not require additional properties– The child method postcondition provides at least as many properties

Local Type Substitutability (part of DO-332, OOT supplement)

Root.Method


• On top of correctness of pre and post conditions, we need to demonstrate that– Parent preconditions imply Child preconditions– Child postconditions imply Parent postconditions

Local Type Substitutability Example

type Abstract_Plane is tagged record

Speed : Integer;

Landed : Boolean;

end record;

procedure Land (V : Root)

with Pre => V.Speed <= 10.0,

Post => V.Landed;

type My_Plane is new Abstract_Plane with record

Gears_Deployed : Boolean;

end record;

overriding

procedure Land (V : Child)

with Pre => V.Speed <= 15.0,

Post => V.Landed and V.Gears_Deplyed;

V <= 10.0 V <= 15.0 {V.Landed, V.Gears_Deployed} V.Landed


1994T

AdaAda


Can You Find the Seven Bugs?

float * compute (int * tab, int size) {

float tab2 [size]; float * result;

for (int j = 0; j <= size; ++j) { tab [j] = tab2 [j] / 10;

}

result = tab2; return result;}


And in Ada?

type Int_Array is array (Integer range <>) of Integer;

type Float_Array is array (Integer range <>) of Float;

function Compute (Tab : Int_Array) return Float_Array is

Tab2 : Float_Array (Tab'Range);

begin

for J in Tab'Range loop

Tab (J) := Tab2 (J) / 10;

end loop;

declare

Result : Float_Array := Tab2;

begin

return Result;

end;

end Compute;


The One-Line-Of-Code Hell

• Is “tab” null?

• Is “tab” an array?

• Is i within the boundaries of “tab”?

• Has “tab” been initialized?

• Is “tab” expecting floats or integers?

• If it’s float, is this a float or a integer division?

tab [i] = tab [i] / 10;

Can’t tell.

Can’t tell.

Can’t tell.

Can’t tell.

Can’t tell.

Can’t tell.


The One-Line-Of-Code Hell

• Is “tab” null?

• Is “tab” an array?

• Is i within the boundaries of “tab”?

• Has “tab” been initialized?

• Is “tab” expecting floats or integers?

• If it’s float, is this a float or a integer division?

tab (i) := tab (i) / 10;

Can’t tell.

No, tab is an array.

Yes, otherwise can’t access to the indices.

Checked at run-time.

If float, compiler runtime.

If needed, explicit conversion.


Driving Design Principles

• Explicit as much as possible– Put as much (formal) information as possible in the code– Put as much (formal) information as possible in the specification– Avoid pointers as much as possible– Avoid shortcuts– Avoid ambiguous constructs as much as possible– Make dubious construct possible but visible

type I_Acc is access all Integer; I : I_Acc := new Integer; function Acc_To_Int is new Ada.Unchecked_Conversion (I_Acc, Integer); function Int_To_Acc is new Ada.Unchecked_Conversion (Integer, I_Acc);

I := Int_To_Acc (Acc_To_Int (I) + I_Acc’Size);

int * i = malloc (sizeof (int));

i++;


Driving Rationale

• Ease manual and automatic analysis– From developer review– From peer review– From compiler errors and warnings– From static analysis tools– From proof tools– From maintainance

• Simplify code an readability when dealing with high level programming concepts

A : Integer_Array (0 .. 10) := (0 => 1, 1 => 1, others => 0)

int [] a = new int [10];

a [0] = 1; a [1] = 1;

for (int i = 2; i < 10; i++) a [i] = 0;


Strong Typing

• A type is a semantic entity, independent from its implementation

• Strong typing forbids implicit conversions

• Values are checked at run-time (can be deactivated)

type Kilometers is new Float;type Miles is new Float;

Length_1 : Miles := 5.0;Length_2 : Kilometers := 10.0;D : Kilometers := Length_1 + Length_2;

type Ratio is new Float range 0.0 .. 100.0;

Qty : Integer := 10;

Total : Integer := 1000;

R : Ratio := Ratio (Total / Qty) * 100.0;


Arrays

• Arrays can be indexed by any discrete types (integers, enumeration)

• First and Last index can be specified at declaration time• Buffer overflows are checked at run-time• There is an array literal (aggregate)

type Some_Array is array (Integer range <>) of Integer;type Color_Array is array (Color range <>) of Integer;

Arr1 : Some_Array (10 .. 11) := (666, 777);Arr2 : Color_Array (Red .. Green) := (Red => 0, others => 1);

Arr1 (9) := 0; -- Exception raised, Index out of range


Parameter Modes

• Three parameter modes : in (input), out (output) and in-out (input/output)

• The correct parameter usage is done at compile-time

• The compiler decides if it has to be passed by reference of copy

• That’s case of explicit pointer avoidance

procedure Do_Something (P1 : in Huge_Structure) –- Passed by reference if too big

procedure Do_Something (P1 : in Integer; -- P1 can’t be changed P2 : out Integer; -- No initial value on P2 P3 : in out Integer) -- P3 can be changed


• Generalized contracts are available through pre and post-conditions

• New type invariants will ensure properties of an object

• Subtype predicates

Pre, Post Conditions and Invariants

type T is private with Invariant => Check (T);

type Even is range 1 .. 10

with Predicate => Even mod 2 = 0;

procedure P (V : in out Integer)

with Pre => V >= 10,

Post => V’Old /= V;


Package Architecture

• All entities are subject to encapsulation– Not only OOP constructions

• Specification and Implementation details are separated from the package, addresses any kind of semantic entity

package Stack is

procedure Push (V : Integer); ...

end Stack; package body Stack is

procedure Push (V : Integer) is begin ...

end Stack;


Data Representation

• Allows to optimize memory usage• Allows to precisely map data

type Size_T is range 0 .. 1023;

type Header is record Size : Size_T; Has_Next : Boolean;end record; for Header userecord Size at 0 range 0 .. 10; Has_Next at 1 range 6 .. 6;end record;


If pointers are needed…

• Pointers are typed, associated with accessibility checks• Objects that can be pointed are explicitly identifed• In the absence of deallocation, pointers are guaranteed to never be dangling• Pointers constraints can be specified

– Is null value expected?– Is the pointer constant?– Is the object pointed by the pointer constant?

type My_Pointer is access all Integer;

Global_Int : aliased Integer;

function Get_Pointer (Local : Boolean) return My_Pointer is

Local_Int : aliased Integer;

Tmp : My_Pointer;

begin

if Local then

Tmp := Local_Int’Access;

else

Tmp := Global_Int’Access;

end if;

return Tmp;

end Get_Pointer;

Tmp := Local_Int’Unchecked_Access;


Concurrent Programing

• Threads and semaphore are first class citizens

task Some_Task is

begin

loop

-- Do something

select

accept Some_Event do

-- Do something

end Some_Event;

or

accept Some_Other_Event do

-- Do something

end Some_Other_Event;

end select;

end loop;

end;

...

Some_Task.Some_Event;


Why is all of this of any use?

• For readability– Specification contains formally expressed properties on the code

• For testability– Constraints on subprograms & code can lead to dynamic checks

enabled during testing

• For static analysis– The compiler checks the consistency of the properties– Static analysis tools (CodePeer) uses these properties as part of its

analysis

• For formal proof– Formal proof technologies can prove formally certain properties of

the code (High-Lite project)


Yes But…

• It is possible to reach similar levels of safety with othertechnologies (MISRA-C, RT-Java)

• … but safety features have to be re-invented– Requires additional guidelines– Requires additional tools– Limited by the original language features

• Examples of features that like “a circle fit in a square”– Types management in MISRA-C– Stack emulation in RT-Java

• When long term reliability is a goal, using the correct paradigm to start with will reach higher levels at lower cost


1994T

http://u.adacore.comhttp://u.adacore.com


Engineering

Critical software developement