Formal Validation of Aerospace Software

Presented by David LESENS and Johannes KANIG

Thursday, 16 May 2013

Astrium Space Transportation

AdaCore

Formal Validation of Aerospace SoftwareDASIA 2013

David LESENS and Johannes KANIG Formal Validation of Aerospace Software15/05/2013 p2

Software was of low quality Software often did not meet requirements Projects were unmanageable and code difficult to maintain …

Software was of low quality Software often did not meet requirements Projects were unmanageable and code difficult to maintain …

Software crisis in space


Where is theWhere is thesoftware crisis?software crisis?


The software crisisThe software crisisis everywhereis everywhere

Topics of thispresentation


Agenda Implementation in C or in Ada? Ada 2012 and SPARK 2014 Application – On Board Control Procedure Conclusion


How to chose a programming language?

Availability of a compiler for the target

Quality of the compiler

Training of the development teams

What about the intrinsic qualities of the language?

Ada is known to be safer than CAda is known to be safer than CAda is known to be safer than CAda is known to be safer than C


ISO formatISO format

French formatFrench format

C syntax isC syntax isnot alwaysnot always

perfectly clearperfectly clear









C syntax isC syntax issometimessometimes

not understandablenot understandableby a non expertby a non expert













Can this code be reviewed by a non software engineer?Can this code be reviewed by a non software engineer?


Ada has a lessAda has a lessambiguous syntaxambiguous syntax

Ada has a lessAda has a lessambiguous syntaxambiguous syntax


Ada has Ada has a lessa lessambiguous syntaxambiguous syntax

andand a stronger a strongersemanticssemantics

Ada has Ada has a lessa lessambiguous syntaxambiguous syntax

andand a stronger a strongersemanticssemantics

Does it really matter?Does it really matter?


Does it really matter?Does it really matter?


An Ada compilerAn Ada compilermay detect bugs…may detect bugs…

……even before testingeven before testing

An Ada compilerAn Ada compilermay detect bugs…may detect bugs…

……even before testingeven before testing


Is Ada the perfect programming language?Is Ada the perfect programming language?

Unfortunately no!Unfortunately no!


Correct if Y / Z is evaluated firstCorrect if Y / Z is evaluated first

Run time error ifRun time error ifF(X) is evaluated first F(X) is evaluated first !!


Objectives:Objectives: Improve the quality thanks to formal proofImprove the quality thanks to formal proof Prepare SPARK 2014Prepare SPARK 2014


There are two ways of constructing asoftware design. One way is to make it sosimple that there are obviously nodeficiencies. And the other way is to makeit so complicated that there are noobvious deficiencies.

There are two ways of constructing asoftware design. One way is to make it sosimple that there are obviously nodeficiencies. And the other way is to makeit so complicated that there are noobvious deficiencies.

Professor C. A. R. HoareThe 1980 Turing award lecture

Professor C. A. R. HoareThe 1980 Turing award lecture

Our approach

Applicable to Requirements Baseline Technical Specification Design Coding Validation & Verification

Applicable to Requirements Baseline Technical Specification Design Coding Validation & Verification


SPARK isSPARK isa restriction of Adaa restriction of Ada


Function with side effectsFunction with side effectsare potentially dangerous are potentially dangerous

and thus not in SPARKand thus not in SPARK

Function with side effectsFunction with side effectsare potentially dangerous are potentially dangerous

and thus not in SPARKand thus not in SPARK

SPARK isSPARK isa restriction of Adaa restriction of Ada


Limitations of testing

Testing shows the presence, not the absence of bugs

Testing shows the presence, not the absence of bugs

Edsger Wybe DijkstraEdsger Wybe Dijkstra


SPARK allowsSPARK allowsformal proofformal proof


SPARK allowsSPARK allowsformal proofformal proof

That is still SPARK 2005!That is still SPARK 2005!

Why SPARK 2014?Why SPARK 2014?




Ada 2012 and SPARK 2014

SPARK has been based on the notion of contract Pre- and Postcondition as logical formulas for formal proof

Ada 2012, inspired by SPARK, introduces executable contracts

Pre- and Postconditions as Boolean expressions for dynamic verification

SPARK 2014 introduces formal proof for Ada 2012 Ease of use (e.g. Boolean expressions instead of logical formulas) Support for dynamic verification (executable contracts) Automation of proof Mixing of dynamic and static verification


How can we avoidHow can we avoidsuch incorrectsuch incorrect

setting?setting?


We can defineWe can definea validity functiona validity function

New in(expression function, case expression)


……and use it inand use it ina contracta contract

New in(contract)

““Set_YearSet_Year” can be called” can be calledonly if its only if its PreconditionPrecondition is true is trueThen, it ensures thatThen, it ensures thatits its PostconditionPostcondition will be true will be true


The correctness ofThe correctness ofcontracts can thencontracts can thenbe formally provedbe formally proved


Proved!Proved!

Not proved!Not proved!



The contractThe contractshall beshall be

completecomplete


The code is now correctThe code is now correctProved!Proved!

Proved!Proved!

Proved!Proved!


The proof toolThe proof toolchecks that the userchecks that the userrespects the contractrespects the contract



Proved!Proved!Not proved!Not proved!




Proved!Proved!Proved!Proved!

Proved!Proved!


Express properties of Express properties of arraysarrays

New in(quantified expressions)


Avoid to write Is_Valid Avoid to write Is_Valid all the timeall the time

New in(type invariants)

Not supported

Not supported

by current version

by current version

of proof toolof proof tool

Not supported

Not supported

by current version

by current version

of proof toolof proof tool


Keep track of Keep track of global variablesglobal variables

New in SPARK 2014(globals annotations)

Z is also readZ is also read


Incorrect flowIncorrect flow

Keep track of Keep track of information flowinformation flow

New in SPARK 2014(information flow)


SPARK 2014 – The toolsAutomatic proof

Execution of annotations possible Allows dynamic verification of properties

Integration with tool chain: Compiler GUI Target configuration


SPARK 2014 RestrictionsForbidden features:

Access types (pointers) Exceptions Aliasing between variables Concurrency features of Ada (Tasking) Side effects in expressions and functions

But free mixing of SPARK and non-SPARK code possibleCombination of verification results possible


SPARK 2014 - MethodologyProof as a means to increase confidence and cut cost

Use proof when it is really required or cheaper than test

Unit Test as a fallback method Use test when full proof of some code is too complex or not applicable

Mixing of test and proof is supported Assumptions of proof can be verified by testing Avoid cost explosion of formal methods (All or nothing)




On-board control procedure Software program designed to be executed by an OBCP engine, which

can easily be loaded, executed, and also replaced, on-board the spacecraft

OBCP code Complete representation of an OBCP, in a form that can be loaded on-

board for subsequent execution

OBCP engine Application of the on-board software handling the execution of OBCPs

OBCP language Programming language in which OBCP source code is expressed by

human programmers


OBCP architecture

FunctionalUnit 1

FunctionalUnit 1

FunctionalUnit 2

FunctionalUnit 2

FunctionalUnit 3

FunctionalUnit 3

FunctionalUnit n

FunctionalUnit n

OBCPengine

Init S1 S2

Init S1 S2

Init S1 S2

Init S1 S2


Event1 Event2 Event3

Not detected Detected Detected


Not detectedNot detected Detected





Example of contract

procedure Reset_Event_Status (Event : in T_Event) with

Post =>

not Event_Status (Event).Detection and

(for all Other_Event in T_Event =>

(if Other_Event /= Event then

Event_Status (Other_Event) = Event_Status'Old (Other_Event)));

Example:Example: A list of event detection statuses Request to reset the detection status for Event

The detection status is unchanged

Post-condition

The detection of event is reset

For all other events


Example of results

Features Total cheks Number proved

Percent proved

assertion 385 385 100

discriminant_check 767 767 100

loop_invariant_initialization 2 2 100

loop_invariant_preservation 2 2 100

overflow_check 2 2 100

postcondition 97 97 100

precondition 413 413 100

range_check 2 2 100

Total 1670 1670 100


Some limitations of the proof toolsubtypesubtype R isis Integer rangerange 1 .. 100;typetype T_Array isis arrayarray (R rangerange <>) ofof Boolean;

typetype T_Record (L : R) isis recordrecord A : T_Array (1 .. L); endend recordrecord;

functionfunction G (X : T_Record) returnreturn Boolean isis (forfor allall I inin X.A'Range => X.A (I));

subtypesubtype R isis Integer rangerange 1 .. 100;typetype T_Array isis arrayarray (R rangerange <>) ofof Boolean;

typetype T_Record (L : R) isis recordrecord A : T_Array (1 .. L); endend recordrecord;

functionfunction G (X : T_Record) returnreturn Boolean isis (forfor allall I inin X.A'Range => X.A (I));

pragmapragma Assert(X >= 0.0 andand thenthen x <= 180.0);pragmapragma Assert(Y >= -180.0 andand thenthen Y <= 0.0);pragmapragma Assert(Z >= 0.0 andand thenthen Z <= 1.0);pragmapragma Assert(X + Y >= 0.0);Result := X + Y * Z;pragmapragma Assert (Result >= 0.0 andand thenthen Result <= 360.0);

pragmapragma Assert(X >= 0.0 andand thenthen x <= 180.0);pragmapragma Assert(Y >= -180.0 andand thenthen Y <= 0.0);pragmapragma Assert(Z >= 0.0 andand thenthen Z <= 1.0);pragmapragma Assert(X + Y >= 0.0);Result := X + Y * Z;pragmapragma Assert (Result >= 0.0 andand thenthen Result <= 360.0);

The size of an arrayThe size of an arraydepends on adepends on adiscriminantdiscriminant

The size of an arrayThe size of an arraydepends on adepends on adiscriminantdiscriminant

Non linearNon linearexpressionexpressionNon linearNon linearexpressionexpression

Not proved with

Not proved with

the current tool version

the current tool versionNot proved with

Not proved with






Formal Validation of Aerospace Software: Conclusion

A programming language with a formal semantics Increases the quality of the software Decreases the development costs

Formal proof can be used For complex software As an efficient complement of tests

SPARK 2014 is foreseen in … 2014 Some developments are still in progress


Thank you for your attentionThank you for your attentionAny question ?Any question ?

[email protected]@[email protected]@adacore.com

Thank you for your attentionThank you for your attentionAny question ?Any question ?

[email protected]@[email protected]@adacore.com

Date post:	12-Jan-2016
Category:	Documents
Upload:	alida
View:	39 times
Download:	0 times

Formal Validation of Aerospace Software

Documents