The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.

The Quest for Correctness

Joseph SifakisJoseph Sifakis

VERIMAG LaboratoryVERIMAG Laboratory

2nd Sogeti Testing Academy 2nd Sogeti Testing Academy April 29th 2009April 29th 2009

Correctness by checking vs. Correctness by construction

Building systems which are correct with respect to given

requirements is the main challenge for all engineering disciplines

Correctness can be achieved:

Either by checking that a system or a model of a system

meets given requirements

Or by construction by using results such as algorithms,

protocols, architectures e.g. token ring protocol, time

triggered architecture

A big difference between Computing Systems Engineering and

disciplines based on Physics is the importance of a posteriori

verification for achieving correctness

OVERVIEW

3

Current status

Work directions

Conclusion

Approaches for checking correctness

Checking correctness

Physical prototypese.g. testing

Ad hoc models e.g. SystemC simulation

Formal models (well-defined notion of state and transition)

Verification Algorithmic Verification e.g. Model checking

Deductive Verification

Models (Virtual SW Prototypes)

Exhaustivity

Verification: Three essential ingredients

Verification

Method

RequirementsRequirementsSystem System ModelModel

YES, NO, DON’TKNOW

Should be: faithful e.g.

whatever property is satisfied for the model holds for the real system

generated automatically from system descriptions

Should be: consistent e.g.

there exists some model satisfying them

complete e.g. they tightly characterize the system’s behavior

As a rule, for infinite state models all non trivial properties are undecidable e.g. bounded memory

Intrinsically high complexity for finite state models (state explosion problem)

Requirements specification (1/3)

always( inev ( enable( send ) ) )

always( inev ( enable( receive) ) )

Using formulas, in particular temporal logic, to characterize a set of execution structures e.g. traces, execution trees

Good for expressing global properties such as mutual exclusion, termination, fairness

Property-based

Using a machine (monitor) to specify observable behavior

send

receive

State-based

Good for characterizing causal dependencies e.g. sequences of actions

We need a combination of both property-based and state-based styles

Requirements specification (2/3)

Temporal logic was a breakthrough in understanding and formalizing

requirements for concurrent systems e.g. mutex, fairness Nonetheless, the declarative style is not always easy to master and

understand - Moving towards a “less declarative” style e.g. MSC, modal automata

We need requirement specification languages for engineers e.g. PSL/Sugar

Much to be done for extra-functional requirements characterizing: security (e.g. privacy properties, electronic voting) reconfigurability (e.g. non interference of features) quality of service (e.g. degree of jitter).

f1f2

f3

Building models (1/3)

v= …u= ..x= …y= …z=xy

MODEL

z

x

yu

v

HW

For hardware, it is easy to get faithful logical finite state models represented as systems of boolean equations

semantics

Building models (2/3)

if….while valid do if x<0 then z=x

else z=-x;

while …

PR

OG

RA

M

semantics

abst

ract

ion

For software this may be much harder ….

validx<0

z:=xx>=0 z:=-x

valid

SE

MA

NT

IC

MO

DE

L

validb

z:=b b z:= b

valid

AB

ST

RA

CT

M

OD

EL

Building models (3/3)

TasksTasksCommandCommandHandlersHandlers

EventEventHandlersHandlers

APPLICATION

SW

For mixed Software / Hardware systems: there are no faithful modeling techniques as we have a poor

understanding of how software and the underlying platform interact validation by testing physical prototypes or by simulation of ad hoc

models

AntennaAntenna

TaskTaskSchedulerScheduler

SensorsSensors

EventEventSchedulerScheduler

TimersTimers

EXECUTION

PLATFORM

Algorithmic Verification: Using Abstraction (1/2)

SA satisfies fA implies S satisfies f where SA =(QA,RA) is an abstraction of S=(Q,R) for formulas f involving only universal quantification over execution paths

QA

Q

2Q 2Q A

are monotonic

Id Id

F is the best approximation of F in the abstract state space

F F

[Cousot&Cousot 79] Abstract interpretation, a general framework for computing abstractions based on the use of Galois connections

Algorithmic Verification: Using Abstraction (2/2)

Initially, focused on finite state systems (hardware, control intensive reactive systems).

Later, it addressed verification of infinite state systems by using abstractions.

Used to check general properties specified by temporal logics.

Driven by the concern for finding adequate abstract domains for efficient verification of program properties, in particular properties related to program execution.

Focuses on forward or backward reachability analysis for specific abstract domains.

Significant results can still be obtained by combining these two approaches

e.g. by using libraries of abstract domains in model checking algorithms.

Model checking Abstract interpretation

OVERVIEW

13

Current status

Work directions

Conclusion

Work Directions: Component-based ModelingWork Directions: Component-based Modeling

Heterogeneity: Embedded systems are built from components with different

characteristics

Execution: synchronous and asynchronous components

Interaction: function call, broadcast, rendezvous, monitors

Abstraction levels: hardware, execution platform, application software

SW Component frameworks: Coordination languages extensions of programming languages e.g.

BPEL, Javaspaces, TSpaces, Concurrent Fortran, NesC Middleware e.g. Corba, Javabeans, .NET Software development environments: PCTE, SWbus, Softbench, Eclipse

System modeling languages: Statecharts, SysML, Matlab/Simulink, AADL, Ptolemy

Hardware description languages: Verilog, VHDL, SystemC

Build complex systems by composing components (simpler systems). This confers numerous advantages such as productivity and correctness

Thread-based programming

Work Directions: Component-based ModelingWork Directions: Component-based Modeling

Actor-based programming

Software Engineering Systems Engineering

Work Directions: Component-based ModelingWork Directions: Component-based Modeling

Build a component C satisfying given requirements f, from C0 a set of atomic components described by their behavior GL ={gl1, …, gli, …} a set of glue operators on components

c1 c’1

gl1c2 c’2

gl12

satisfies fgl2

Move from single low-level composition operators e.g. automata-based to families of high-level composition operators e.g. protocols, controllers

We need a unified composition paradigm for describing and analyzing the coordination between components to formulate system designs in terms of tangible, well-founded and organized concepts

17

Work Directions: Constructivity

Today, a posteriori verification at high development costs limited to medium complexity systemsTomorrow, correct-by-construction results should advantageously take into account architectures and their features.

There is a large space to be explored, between full constructivity and a posteriori verification. Develop correct-by-construction results For particular

architectures (e.g. client-server, star-like, time triggered)

programming models (e.g. synchronous, data-flow)

execution models (e.g. event triggered preemptable tasks)

For specific classes of properties such as deadlock-freedom, mutual exclusion, timeliness

Work Directions: Constructivity – Compositionality

Build correct systems from

correct components: rules for

proving global properties from

properties of

individual components

We need compositionality results for the preservation of progress properties such as deadlock-freedom and liveness as well as extra-functional properties

gl

cisat Pi implies gl gl ~ sat gl(P1, ..,Pn)

glc1 cn

~

Work Directions: Constructivity – Composability

Essential properties of components are preserved when they are integrated

gl

gl

Property stability phenomena are poorly understood. We need composability results e.g. non interaction of features in middleware, composability of scheduling algorithms, of Web services, of aspects

Xsat Pgl

c1 cn

and sat P’gl’c1 cn

implies sat PP’gl gl’c1 cn

Work Directions: Constructivity - Example

Checking global deadlock-freedom of a system built from deadlock-free components, by separately analyzing the components and the architecture.

S1 S2p1 p2

q1 q2S2

p1

S1p2

Potential deadlock D = en(p1) en(p2)

en(q2) en(q1)p1 p2

q3r3

S1 S2

S3

r1 q2 Potential deadlockD = en(p1) en(p2) en(q2) en(q3) en(r3) en(r1)

Work Directions: Constructivity - Example

OVERVIEW

22

Current status

Work directions

Conclusion

From a posteriori verification to constructivity at design time

Verification is not the only way for guaranteeing correctness. In contrast to Physics, Computer Science deals with an infinite

number of possibly created universes Limiting the focus on particular tractable universes of systems

can help overcome current limitations

We should concentrate on compositional modeling and verification for sub-classes of systems and properties which are operationally relevant and technically successful

24

Thank YouThank You