Critical software developement

Slide: 1Copyright © 2014 AdaCore
Quentin Ochem
Technical Account Manager
Critical Software Development

What is Critical Software?

Case-Study
Avionics 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.a
6.4.4.2.b
6.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.a
6.4.4.2.b
6.4.4.2.d
Software Verification
Results
2 2 2

System RequirementsSystem Requirements
High Level
Requirements
High Level
Requirements
Software ArchitectureSoftware Architecture
Low Level
Requirements
Low Level
Requirements
Source CodeSource Code
referencestrace
trace
references
references
trace
Executable Object
Code
Executable Object
Code
generates
[5] Main Development Objectives

High Level
Requirements
High Level
Requirements
Low Level
Requirements
Low Level
Requirements
Executable Object
Code
Executable Object
Code
compliance
traceability
compliance
compatibilitycompliance
traceability
compliance
traceability
[6] Main Verification Objectives (1/4)

High Level
Requirements
High Level
Requirements
Low Level
Requirements
Low Level
Requirements
Executable Object
Code
Executable Object
Code
complete and correct
verifiable
conformance
accuracy and consistency
accuracy & consistency
HW compatibility
verifiability
conformance
consistency
HW compatibility
verifiability
conformance
partition integrity
accuracy & consistency
HW compatibility
verifiability
conformance

High Level
Requirements
High Level
Requirements
Low Level
Requirements
Low Level
Requirements
Executable Object
Code
Executable Object
Code
compliance
robustness
compliance
robustness
compatible with target

High Level
Requirements
High Level
Requirements
Low Level
Requirements
Low Level
Requirements
Executable Object
Code
Executable Object
Code
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 => TRUE
X = ‘z’ => FFF => FALSE
 Cond2
X = ‘’ => FTF => TRUE
X = ‘y’ => FFF => FALSE
 Cond3
X = ‘y’ => FFF => FALSE
X = ‘:’ => 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

1994
T
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 use
record
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 other
technologies (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

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

Critical software developement

Recommended

Recommended

More Related Content

Similar to Critical software developement

Similar to Critical software developement (20)

More from nedseb

More from nedseb (7)

Recently uploaded

Recently uploaded (20)

Critical software developement