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

2. 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

3. OVERVIEWOVERVIEW 3 Current status Work directions Conclusion

4. Approaches for checking correctness Checking correctness Physical prototypes e.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

5. Verification: Three essential ingredients Verification Method Requirements System Model YES, NO, DONTKNOW 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 systems 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)

6. 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

7. 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). f1 f2 f3

8. Building models (1/3) v= … u=.. x= … y= … z=x y MODEL z x y u v HW For hardware, it is easy to get faithful logical finite state models represented as systems of boolean equations semantics

9. Building models (2/3) if…. while valid do if x<0 then z=x else z=-x; while … PROGRAM semantics abstraction For software this may be much harder …. valid x<0 z:=x x>=0 z:=-x valid SEMANTIC MODEL valid b z:=b b z:= b valid ABSTRACT MODEL

10. Building models (3/3) Tasks Command Handlers Event Handlers 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 Antenna Task Scheduler Sensors Event Scheduler Timers EXECUTION PLATFORM

11. Algorithmic Verification: Using Abstraction (1/2) S A satisfies f A implies S satisfies f where S A =(Q A,R A ) is an abstraction of S=(Q,R) for formulas f involving only universal quantification over execution paths QAQA Q 2Q2Q 2Q2Q A are monotonic 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

12. 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 checkingAbstract interpretation

13. OVERVIEWOVERVIEW 13 Current status Work directions Conclusion

14. Work 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

15. Thread-based programming Work Directions: Component-based Modeling Actor-based programming Software EngineeringSystems Engineering

16. Work Directions: Component-based Modeling Build a component C satisfying given requirements f, from C 0 a set of atomic components described by their behavior GL ={gl 1, …, gl i, …} a set of glue operators on components c1c1 c1c1 gl1 c2c2 c2c2 gl12 satisfies f gl2 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. 17 Work Directions: Constructivity Today, a posteriori verification at high development costs limited to medium complexity systems Tomorrow, 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

18. 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 cici sat P i implies gl gl ~ sat gl(P 1,..,P n ) gl c1c1 cncn ~

19. 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 X sat P gl c1c1 cncn and sat P gl c1c1 cncn implies sat P P gl c1c1 cncn

20. Work Directions: Constructivity - Example Checking global deadlock-freedom of a system built from deadlock-free components, by separately analyzing the components and the architecture. S1S2 p1 p2 q1q2 S2 p1 S1 p2 Potential deadlock D = en(p1) en(p2) en(q2) en(q1) p1p2 q3r3 S1S2 S3 r1 q2 Potential deadlock D = en(p1) en(p2) en(q2) en(q3) en(r3) en(r1)

21. Work Directions: Constructivity - Example

22. OVERVIEWOVERVIEW 22 Current status Work directions Conclusion

23. 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. 24 Thank You