![Design-By-Contract
Well-known forms:
{P}C{Q}
P =⇒ [C]Q
where P – precondition, C – code, Q – postcondition. Invariant is a
form of a global pre- and post- condition {I}C{I}
In OOP languages:
Pre- and Post- conditions are specified for methods
Invariant is specified for the whole class
Also, for loops Loop Invariants and Loop Variant are specified
The things can be specified:
As a part of language syntax (Eiffel)
In comments (Frama-C)
In annotations and special code (MS Code contracts)
5 / 42](https://image.slidesharecdn.com/staroletovcontractscyber-191226060112/85/Staroletov-Design-by-Contract-verification-of-Cyber-physical-systems-5-320.jpg)
 (2)
Then, we decompose the system into precondition, continuous
PD-controller and requirements. Precondition:
init :== v ≥ 0 ∧ c > 0 ∧ Kp = 2 ∧ Kd = 3 ∧ V(p, pr , v) < c (3)
The continuous state:
controller :== p = v, v = −Kp · (p − pr ) − Kd · v (4)
As the requirement it is proposed to try stability using Lyapunov
method:
req :== V(p, pr , v) < c (5)
V(p, pr , v) = 5/4 · (p − pr )2
+ (p − pr ) · v/2 + v2
/4 (6)
*Quesel et al.: How to Model and Prove Hybrid Systems with
KeYmaera
40 / 42](https://image.slidesharecdn.com/staroletovcontractscyber-191226060112/85/Staroletov-Design-by-Contract-verification-of-Cyber-physical-systems-40-320.jpg)
Staroletov Design by Contract, verification of Cyber-physical systems
- 1. Modern Software Testing and Formal Verification Techniques Day 3 Sergey Staroletov Polzunov Altai State Technical University, Lenin avenue 46, Barnaul, 656038, Russia Email: serg [email protected] June 26, 2019 1 / 42
- 2. Today’s agenda 1 Design-By-Contract. MS Code Contracts 2 Deductive verification of C-code with Frama-C WP 3 C-code: is LTL applicable here? 4 Cyber-physical systems and their verification 2 / 42
- 3. Overall picture of tools applicability 3 / 42
- 4. Design-By-Contract Created by Bertrand Meyer, firstly implemented in Eiffel language and based on the Sir Tony Hoare’s logic The approach is based on specifying pre-conditions, post-conditions and invariant to functions (methods, classes). 4 / 42
- 5. Design-By-Contract Well-known forms: {P}C{Q} P =⇒ [C]Q where P – precondition, C – code, Q – postcondition. Invariant is a form of a global pre- and post- condition {I}C{I} In OOP languages: Pre- and Post- conditions are specified for methods Invariant is specified for the whole class Also, for loops Loop Invariants and Loop Variant are specified The things can be specified: As a part of language syntax (Eiffel) In comments (Frama-C) In annotations and special code (MS Code contracts) 5 / 42
- 6. A bit about Hoare’s Logic Program− > (Sentence)+ Sentence− > Skip|Assignment|If|Loop|Composition 6 / 42
- 7. A bit about Hoare’s Logic Skip changes nothing Assignment has an influence to the post-condition Composition makes sequential execution with making transition of post-condition If has two branches with “or” operator which holds with 2 preconditions Loop is characterized with the Invariant of the cycle which holds before the cycle, in the cycle and after the cycle is finished. Also there is addition control for resolving The halting Turing problem – the Variant, which should decrease at the each step and to be always positive. 7 / 42
- 8. MS Code contracts Microsoft, known for its research departments, has added a method to programming using contracts for .NET programs as a special library and extension for Visual Studio. Initially, the research included Spec# (Specification Sharp) language for contract description, but now the contracts are fully integrated into the project in the target programming language (for example, in C#). Contracts can be checked: In dynamic, that is, while the program is running, expressions in the contracts are calculated, and if they are not as expected, an exception is thrown. In static, i.e. during the project build without needing it to run, a special static checker can check the program branches and find some potential errors. 8 / 42
- 9. MS VS Addition for Code Contracts 9 / 42
- 10. Class Student 10 / 42
- 11. Class Student constructor contract with a precondition 11 / 42
- 12. Class Student object invariant 12 / 42
- 13. Class Student contract violation 13 / 42
- 14. Class Student contract violation – throw the exception 14 / 42
- 15. Static checker for contracts in the IDE 15 / 42
- 16. More complex contracts 16 / 42
- 17. Add a student to a group list 17 / 42
- 18. Remove a student from a group list 18 / 42
- 19. Group invariant 19 / 42
- 20. Double check 20 / 42
- 21. Contracts in C# – resume A good method to move academic approach into production Moves logic of class stability to a class Different way of implementation of checks Does not guarantee a class correctness 21 / 42
- 22. The Weakest Precondition Dijkstra has proposed the addition to Hoare’s logic – the weakest precondition (WP approach), which requires the precondition to be as simple as possible to reach just a postcondition {P}f{Q} =⇒ {wp(f, Q)fQ} In this case, the further program verification will be as follows: we calculate W = wp(f, Q), go from the end of Q to the start of the function, and we post a task to prove P => W to a theorem prover 22 / 42
- 23. Frama-C An extensible static-analyze tool Created by INRIA Based on annotation that user write to C code by hand Some annotations can be generated ACSL language for ISO-standardized annotations, provable specification for C code To prove the annotations, the WP approach is used. 23 / 42
- 24. Frama-C: the interface 24 / 42
- 25. Frama-C: inserting runtime checks 25 / 42
- 26. ACSL example 26 / 42
- 27. ACSL example in Frama-C 27 / 42
- 28. Verifying a simple car moving model 28 / 42
- 29. Towards verifying a drone attitude PID-controller 29 / 42
- 30. Towards verifying a drone attitude PID-controller Even for this simple code the verification on real floating point numbers is challenging! 30 / 42
- 31. Towards verifying a drone attitude PID-controller 31 / 42
- 32. Towards verifying a drone attitude PID-controller We should run Frama-C on infinite abstract real numbers model! 32 / 42
- 33. Towards verifying a drone attitude PID-controller 33 / 42
- 34. Towards verifying a drone attitude PID-controller 34 / 42
- 35. Towards verifying a drone attitude PID-controller 35 / 42
- 36. C code and LTL: Aora¨ı 36 / 42
- 37. C code and LTL: Aora¨ı 37 / 42
- 38. Verification of Cyber-physical systems demo Cyber-physical system: A Cyber part – descrete controller A Physical part – continuous model of the system, here – expressed in ODEs. 38 / 42
- 39. Verification of Cyber-physical systems These systems can be modeled as Hybrid automata which represent discrete-time and continuous-time transitions; such models are known as Hybrid models and specified using the Hybrid Dynamic Logic . According to A. Platzer, the syntax of hybrid programs is defined as follows: α ::= x := e | ?Q | x = f(x)&Q | α ∪ α | α; α | α∗ (1) where α is a meta-variable for the hybrid programs, x is a meta-variable for program variables, e is a meta-variable for the first-order real-valued terms, f is a meta-variable for the continuous real functions, and Q is a meta-variable for the first-order formulas over real numbers. The construct ‘;’ means here the sequential composition, ‘∪’ — is the non-deterministic choice, ‘?’ — is the condition operator, and ‘∗’ — is the non-deterministic iteration (like Kleene-star). * Platzer, Andr´e. ”Logical Foundations of Cyber-Physical Systems.” 39 / 42
- 40. Verification of a simple PD-controller The simplification of PID is PD-controller and the model of the system is given as a Hoare’s triple: init =⇒ [controller](req) (2) Then, we decompose the system into precondition, continuous PD-controller and requirements. Precondition: init :== v ≥ 0 ∧ c > 0 ∧ Kp = 2 ∧ Kd = 3 ∧ V(p, pr , v) < c (3) The continuous state: controller :== p = v, v = −Kp · (p − pr ) − Kd · v (4) As the requirement it is proposed to try stability using Lyapunov method: req :== V(p, pr , v) < c (5) V(p, pr , v) = 5/4 · (p − pr )2 + (p − pr ) · v/2 + v2 /4 (6) *Quesel et al.: How to Model and Prove Hybrid Systems with KeYmaera 40 / 42
- 41. KeYmaera – verification results of the model KeYmaera – is an automatic theorem prover and it implements the Dynamic Differential Logic and KeYmaera’s input are hybrid programs. 41 / 42
- 42. Learn more about ways of verification and contracts 42 / 42