Download as PDF, PPTX
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
BlockLibrary Specification DSL – Block Semantics
Modes bind block interfaces and semantic functions.
mode DelayMode_List implements ALT (ListDelay_ScalarInput,
ListDelay_VectorInput, ListDelay_MatrixInput)
{
definition bal = init {
postcondition ocl { Mem.value = Init.value }
Mem.value := Init.value; }
definition bal = compute {
postcondition ocl { Output.value = Mem.value->first() }
Output.value := Mem.value[0]; }
definition bal = update {
postcondition ocl {
Mem.value = Mem.value->excluding(Mem.value->first())
->append(Input.value)}
var iter = 0;
while (iter < (Delay.value - 1)){
invariant { 0 <= iter && iter < Delay.value }
invariant {
Set{0 .. iter}->forAll(i | (0 <= i && i < iter)
implies (Mem.value->subList(1,i) =
(Mem.value@pre)->subList(2,i+1))) }
variant { Delay.value - iter }
Mem.value[iter] := Mem.value[iter + 1];
iter := iter + 1;
}
Mem.value[Delay.value - 1] := Input.value;
}
}
BlockLibrary BlockType
BlockVariant
...
BV
Constraints
BlockMode
Pre PostAction
...
BM
Constraints
Parameter
Port
Memory
Constraints
Constraints
Constraints
ref
ref
ref
DataType
...
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 15 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-15-2048.jpg)
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Example: Translation Validation of the Counter System (4)
[wp] Running WP plugin...
[wp] Collecting axiomatic usage
[rte] annotating function Counter_compute
[rte] annotating function Counter_init
[wp] 53 goals scheduled
[wp] [Qed] Goal typed_Counter_compute_assign_part1 : Valid
...
[wp] [Qed] Goal typed_Counter_compute_stmt_post : Valid
[wp] [Qed] Goal typed_Counter_compute_stmt_assign : Valid
[wp] [Qed] Goal typed_Counter_compute_stmt_post_2 : Valid (4ms)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_2 : Valid
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_3 : Valid (36ms) (27)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_3 : Valid
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_4 : Valid (Qed:4ms) (40ms) (32)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_4_part1 : Valid
...
[wp] [Qed] Goal typed_Counter_compute_stmt_post_5 : Valid (4ms)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_5 : Valid
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_6 : Valid (Qed:4ms) (52ms) (41)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_6 : Valid
[wp] [Qed] Goal typed_Counter_compute_stmt_post_7 : Valid (4ms)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_7_part1 : Valid
...
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_8 : Valid (Qed:4ms) (60ms) (39)
[wp] [Qed] Goal typed_Counter_compute_stmt_assign_8_part1 : Valid
...
[wp] [Qed] Goal typed_Counter_compute_stmt_post_9 : Valid (4ms)
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_9 : Valid (Qed:8ms) (40ms) (34)
[wp] [Qed] Goal typed_Counter_compute_stmt_post_10 : Valid (8ms)
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_10 : Valid (36ms) (34)
[wp] [Qed] Goal typed_Counter_compute_stmt_post_11 : Valid
[wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_11 : Valid (Qed:4ms) (44ms) (34)
[wp] [Alt-Ergo] Goal typed_Counter_init_assign_part1 : Valid (28ms) (16)
[wp] [Alt-Ergo] Goal typed_Counter_init_assign_part2 : Valid (32ms) (16)
[wp] [Qed] Goal typed_Counter_init_stmt_post : Valid
[wp] [Alt-Ergo] Goal typed_Counter_init_stmt_assign : Valid (32ms) (18)
[wp] [Qed] Goal typed_Counter_init_stmt_post_2 : Valid
[wp] [Alt-Ergo] Goal typed_Counter_init_stmt_assign_2 : Valid (32ms) (18)
[wp] Proved goals: 53 / 53
Qed: 31 (4ms-8ms)
Alt-Ergo: 22 (28ms-192ms) (247)
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 25 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-27-2048.jpg)
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (1/4)
This example
requires a loop in the
update function to
shift all elements in
the memory by one.
The annotated
version of the
generated C code
should contain:
a loop invariant and
a loop variant for
the verification to
succeed
automatically.
1 mode DelayMode_List implements ALT (
ListDelay_ScalarInput,
2 ListDelay_VectorInput, ListDelay_MatrixInput)
3 {
4 definition bal = init {
5 postcondition ocl { Mem.value = Init.value }
6 Mem.value := Init.value; }
7 definition bal = compute {
8 postcondition ocl
9 { Output.value = Mem.value->first() }
10 Output.value := Mem.value[0]; }
11 definition bal = update {
12 postcondition ocl {
13 Mem.value = Mem.value->excluding(
14 Mem.value->first())->append(Input.value)}
15 var iter = 0;
16 while (iter < (Delay.value - 1)){
17 invariant { 0 <= iter && iter < Delay.value }
18 invariant {
19 Set{0 .. iter}->forAll(i | (0 <= i && i < iter)
20 implies (Mem.value->subList(1,i) =
21 (Mem.value@pre)->subList(2,i+1))) }
22 variant { Delay.value - iter }
23 Mem.value[iter] := Mem.value[iter + 1];
24 iter := iter + 1;
25 }
26 Mem.value[Delay.value - 1] := Input.value;
27 }
28 }
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 28 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-30-2048.jpg)
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (2/4)
Here, the annotations
have been explicitly
included in the
specification
(lines 17-22).
Manually specifying
loop annotations for
routine operations is
tedious and
error-prone.
The annotations
must also be
translated and
fine-grain woven
into the generated
code.
1 mode DelayMode_List implements ALT (
ListDelay_ScalarInput,
2 ListDelay_VectorInput, ListDelay_MatrixInput)
3 {
4 definition bal = init {
5 postcondition ocl { Mem.value = Init.value }
6 Mem.value := Init.value; }
7 definition bal = compute {
8 postcondition ocl
9 { Output.value = Mem.value->first() }
10 Output.value := Mem.value[0]; }
11 definition bal = update {
12 postcondition ocl {
13 Mem.value = Mem.value->excluding(
14 Mem.value->first())->append(Input.value)}
15 var iter = 0;
16 while (iter < (Delay.value - 1)){
17 invariant { 0 <= iter && iter < Delay.value }
18 invariant {
19 Set{0 .. iter}->forAll(i | (0 <= i && i < iter)
20 implies (Mem.value->subList(1,i) =
21 (Mem.value@pre)->subList(2,i+1))) }
22 variant { Delay.value - iter }
23 Mem.value[iter] := Mem.value[iter + 1];
24 iter := iter + 1;
25 }
26 Mem.value[Delay.value - 1] := Input.value;
27 }
28 }
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 29 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-31-2048.jpg)
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (3/4)
Routine operations
on non-scalar data
can be integrated
into the DSL as
primitives or defined
via higher-level
operators.
E.g. line 15 instead
of former lines 15-26.
The primitives and
higher-level
operators are
automatically
expanded
with appropriate
annotations.
1 mode DelayMode_List implements ALT (
ListDelay_ScalarInput,
2 ListDelay_VectorInput, ListDelay_MatrixInput)
3 {
4 definition bal = init {
5 postcondition ocl { Mem.value = Init.value }
6 Mem.value := Init.value; }
7 definition bal = compute {
8 postcondition ocl
9 { Output.value = Mem.value->first() }
10 Output.value := Mem.value[0]; }
11 definition bal = update {
12 postcondition ocl {
13 Mem.value = Mem.value->excluding(
14 Mem.value->first())->append(Input.value)}
15 Vector_Shift_Left1(Mem.value, Input.value)
16 }
17 }
18 }
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 30 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-32-2048.jpg)
![Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (4/4)
Example: Delay
block instance
with:
scalar input,
static delay
length,
delay length
value = 2.
C code
generated by
GENEAUTO and
annotated with
ACSL
annotations
derived from
BlockLibrary.
/* START Block memory write:
<SequentialBlock: name=Delay2> */
/*@ ensures append: _state_->Delay2_memory[1] == system_In1;
ensures sublist: forall integer i; 0 <= i < 1 ==>
_state_->Delay2_memory[i] ==
old(_state_->Delay2_memory[i+1]);
*/
{/*@ loop invariant forall integer i; 0 <= i < iter ==>
_state_->Delay2_memory[i] ==
at(_state_->Delay2_memory[i+1],LoopEntry);
loop invariant 0 <= iter < 2;
loop assigns iter, _state_->Delay2_memory[0];
loop variant 1 - iter; */
for (int iter = 0; iter < 1; iter++){
_state_->Delay2_memory[iter] =
_state_->Delay2_memory[iter+1];
}
_state_->Delay2_memory[1] = system_In1;}
/* END Block memory write:
<SequentialBlock: name=Delay2> */
A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 31 / 33](https://image.slidesharecdn.com/slides-160927141426/75/Block-Library-Driven-Translation-Validation-for-DataFlow-Models-in-Safety-Critical-Systems-33-2048.jpg)
Uploaded byMarc Pantel
Block Library Driven Translation Validation for DataFlow Models in Safety Critical Systems
The document discusses the development and validation of a block library-driven translation validation approach for dataflow models in safety-critical systems. It highlights the challenges and methodologies for verifying the generated code from automatic code generators, emphasizing the importance of ensuring safety and correctness in high-stakes embedded systems. The authors present a formal framework for validating block library specifications and generated code, leveraging domain-specific languages and model-driven engineering techniques.
![ANPARA THERMAL POWER STATION[1] sangam.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/anparathermalpowerstation1sangam-251121115219-9261cde4-thumbnail.jpg?width=640&height=640&fit=bounds)
Block Library Driven Translation Validation for DataFlow Models in Safety Critical Systems
- 1. Block Library DrivenTranslation Validation for Dataflow Models in Safety Critical Systems Arnaud Dieumegard1 Andres Toom234 Marc Pantel2 1 Institut de Recherche Technologique Antoine de Saint Exupéry 118 route de Narbonne, CS 44248, 31432 Toulouse Cedex 4, France 2 Institut de Recherche en Informatique de Toulouse, Université de Toulouse ENSEEIHT, 2 rue Charles Camichel, 31071 Toulouse Cedex, France 3 Institute of Cybernetics at Tallinn University of Technology Akadeemia tee 21, EE-12618 Tallinn, Estonia 4 IB Krates OÜ, Mäealuse 4, EE-12618 Tallinn, Estonia Work funded by research projects OPEES and PROJET P
- 2. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives 1 Context Context Use case The problem 2 BlockLibrary DSL Process Overview The Block Library DSL Verification of BlockLibrary specifications 3 Verification of the Generated Code Block Library Driven Translation Validation Example Handling loops 4 Conclusions and Perspectives A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 2 / 33
- 3. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives 1 Context Context Use case The problem 2 BlockLibrary DSL Process Overview The Block Library DSL Verification of BlockLibrary specifications 3 Verification of the Generated Code Block Library Driven Translation Validation Example Handling loops 4 Conclusions and Perspectives A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 3 / 33
- 4. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Safety Critical Embedded Systems Safety critical embedded system: failure may cause loss of life. Domain specific safety certification standards DO-178C for aeronautics ECSS-Q80A for space ISO-26262 for automotive CEI60880 for nuclear energy ... System certification development objectives Specification, verification, traceability, independence, ... Do not enforce technical solutions (except test) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 4 / 33
- 5. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Classical Process of Embedded Systems Development Precise and constrained development process Software specification (HLR) Software design (LLR) Hand-made programming based on LLR Traceability is mandatory Hand-made verification Proof reading Requirement-based testing with Modified Condition / Decision Coverage Non-exhaustive (test), error-prone (proof reading) and costly. May fail to ensure safetyA.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 5 / 33
- 6. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Modern Process of Embedded Systems Development Taking advantage of Model-Driven Engineering (DO-331) and Formal Methods (DO-333) Automated Code Generators (ACG) Automated verification tools → Fewer errors and more exhaustive than hand-made DO-330: Tool qualification or Tool output verification Tool code: same quality as system code Even more costly qualification process Modified Condition / Decision Coverage (MC/DC) on a language Even less representative (test) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 6 / 33
- 7. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Data Flow Languages Graphical data flow language structure Parameter: Sign = ”++” Mono-clock system/block Semantics A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 7 / 33
- 8. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives High Variability of the Block’s Structure and Semantics Delay block Number of structural configurations: 144 Number of “algorithms” (semantic functions): 12 Block Ports Parameters Memories Semantics In Out Delay Init DelayMemory Outn+1 = Inn Out0 = Init In Out Delay Init DelayMemory Outn+Delay = Inn Out0 = Init(0) ... OutDelay−1 = Init(Delay −1) ... ... ... ... ... A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 8 / 33
- 9. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives The problem - Is the generated code correct? Option 1: Trusted Automatic Code Generator (ACG) E.g. qualified according to DO-178C, DO-330: Tool Operational Requirements (TOR): HLR for the ACG. Specification and constraints for the input and output languages Tool Requirements (TR): LLR for the ACG. Generated code patterns for all supported input configurations (translation rules). Extensive verification and validation of the ACG wrt. TR, TOR. Usually test-based, MC/DC coverage of the ACG’s source code. Option 2: Verification of the ACG’s output (generated code) Generated code behaves as design? =⇒ Translation validation. Prerequisite: Complete and consistent specification of the input language Issue: Most ACG input languages specifications are semi-formal A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 9 / 33
- 10. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives 1 Context Context Use case The problem 2 BlockLibrary DSL Process Overview The Block Library DSL Verification of BlockLibrary specifications 3 Verification of the Generated Code Block Library Driven Translation Validation Example Handling loops 4 Conclusions and Perspectives A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 10 / 33
- 11. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Block Library Driven Specification and Development Process MyModel.mdl Model BlockLibrary BlockLibrary Specification BlockLibrary DSL (ecore + OCL + syntax) Dataflow modelling toolset (Simulink, ...) BlockLibrary modelling toolset Instance of Specifies Bacon ipsum dolor sit amet venison cow jowl bacon swine pork belly, beef ribs rump chicken chuck brisket sirloin. Leberkas jowl beef ribs landjaeger, doner corned beef rump bacon pancetta t-bone tenderloin ham ball tip andouille pork chop. Pork loin porchetta Chicken ground round beef ribeye fatback, pancetta tenderloin shankle venison. Drumstick venison prosciutto, ground round pig chicken t-bone shank hamburger strip steak biltong turkey sirloin salami rump. Tail t-bone beef venison cow, hamburger sausage ground Bacon ipsum dolor sit amet venison cow jowl bacon swine pork belly, beef ribs rump chicken chuck brisket sirloin. Leberkas jowl beef ribs landjaeger, doner corned beef rump bacon pancetta t-bone tenderloin ham ball tip andouille pork chop. Pork loin porchetta Use MyBL.mdl MyBL.bls Bacon ipsum dolor sit amet venison cow jowl bacon swine pork belly, beef ribs rump chicken chuck brisket sirloin. Leberkas jowl beef ribs landjaeger, doner corned beef rump bacon pancetta t-bone tenderloin ham ball tip andouille pork chop. Pork loin porchetta Chicken ground round beef ribeye fatback, pancetta tenderloin shankle venison. Drumstick venison prosciutto, ground round pig chicken t-bone shank hamburger strip steak biltong turkey sirloin salami rump. Tail t-bone beef venison cow, hamburger sausage ground BlockLibrary Toolset Specifies Instance of Instance of Why3 Verification Tool Formal verification toolset Static BlockLibrary Formalisation DataTypes OCL BlockLibrary Language Constructs Structure and variability Verification Goals + Blocks Semantics Conforms to SMT solvers ImplementsCode Generation Tool Code generation backends Source Code Use Annotations Expresses Code verification tool (Frama-C, Spark, ...) Translated to Verifies Verifies Proof Assistant Use A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 11 / 33
- 12. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Key Block-Related Development Aspects Structural definition Ports, parameters, memory Constraints Semantic definition axiomatic: pre-conditions / post-conditions operational: algorithm Variability management Polymorphism wrt. data types, dimensionality and basic operations Complexity management User accessibility (specification designers and users) Ease of writing, understanding and automated analysis of specifications A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 12 / 33
- 13. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Language Modeling Solution (SPLC 2014) Issues: Language size and complexity ⇒ Unbounded language use Tool development cost Proposed solution Domain-Specific Language (DSL) derived from SPLE and UML User-specific interface Documentation generation ⇒ Reading easiness ⇒ Standard documentation building Extensibility / Accessibility Model-driven engineering based ⇒ Textual editors / Form-based / ... Verifiability Specification verification ⇒ Verification relying on transformations A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 13 / 33
- 14. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives BlockLibrary Specification DSL – Block Interfaces Inspired from Software Product Line Engineering (SPLE) methodology n-ary AND, n-ary ALT (XOR) composition operators Interface definitions (variants) and feature constraints variant InternalDelay { parameter Delay : TInt32 } variant ExternalDelay { in data Delay : TInt32 } variant DelayVar extends ALT (InternalDelay, ExternalDelay) { invariant ocl { Delay.value > 0 } } variant ListDelay_ScalarInput extends AND ( ResetParam, DelayVar, InputScalar ) { invariant ocl { Delay.value > 1 } invariant ocl { Init.value.size() = Delay.value } memory Mem { datatype auto ocl {In.value} length auto ocl {0} } } Out DelayBlock Init Mem DelayIn Out DelayBlock Init Mem In Delay A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 14 / 33
- 15. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives BlockLibrary Specification DSL – Block Semantics Modes bind block interfaces and semantic functions. mode DelayMode_List implements ALT (ListDelay_ScalarInput, ListDelay_VectorInput, ListDelay_MatrixInput) { definition bal = init { postcondition ocl { Mem.value = Init.value } Mem.value := Init.value; } definition bal = compute { postcondition ocl { Output.value = Mem.value->first() } Output.value := Mem.value[0]; } definition bal = update { postcondition ocl { Mem.value = Mem.value->excluding(Mem.value->first()) ->append(Input.value)} var iter = 0; while (iter < (Delay.value - 1)){ invariant { 0 <= iter && iter < Delay.value } invariant { Set{0 .. iter}->forAll(i | (0 <= i && i < iter) implies (Mem.value->subList(1,i) = (Mem.value@pre)->subList(2,i+1))) } variant { Delay.value - iter } Mem.value[iter] := Mem.value[iter + 1]; iter := iter + 1; } Mem.value[Delay.value - 1] := Input.value; } } BlockLibrary BlockType BlockVariant ... BV Constraints BlockMode Pre PostAction ... BM Constraints Parameter Port Memory Constraints Constraints Constraints ref ref ref DataType ... A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 15 / 33
- 16. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Verification and Validation of BlockLibrary Specifications Structural correctness (syntax, structure) ⇒ Metamodel conformance and OCL constraints on models Semantics behavior correctness criteria (verification) Disjointness: Configurations are unique Completeness: All possible configurations are specified Hoare-based semantics consistency ⇒ Translation to a formal verification platform Validation of the specifier’s intent ⇒ Generation of test cases to compare with simulation in the modelling environment A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 16 / 33
- 17. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Verification Strategy: Translation to Why3 Why3Utheory Why3Umodule DataTypes Predicates Disjointness Completeness Goals Configuration Transformation Configuration Predicate GoalsUExtraction BlockUDomain Transformation Why3Utheory Use SemanticsUstep FunctionsSemanticsU Verification Transformation Use init compute update BlockLibrary BV BM BlockType BlockMode BM BlockVariant Constraints Pre PostAction ... ... BV Constraints Parameter Port Memory Constraints Constraints Constraints DataType ref ref ref ... ⇒ SMT solver/Proof assistant to verify goals and functions Development effort: 11000 LOC (Java), 1200 LOC (Why) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 17 / 33
- 18. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Verification of the Disjointness and Completeness Properties 1 – Block specification (extract) variant InternalDelay { parameter Delay : TInt32 } variant ExternalDelay { in data Delay : TInt32 } variant DelayVar extends ALT( InternalDelay, ExternalDelay) { invariant ocl { Delay.value > 0 } } variant ListDelay_ScalarInput extends AND( ResetParam, DelayVar, InputScalar ) { invariant ocl { Delay.value > 1 } invariant ocl { Init.value.size() = Delay.value } memory Mem { datatype auto ocl {In.value} length auto ocl {0} } } 2 – Generated Why predicates (extract) type tDelay_InternalDelay_TInt32 = tParameter (tRealInt32) type tDelay_ExternalDelay_TInt32 = tInPortGroup (tRealInt32) type tMem_ListDelay_ScalarInput_TArray1Dim_TDouble = tMemoryVariable (list (tRealDouble)) (* Theory 1 *) predicate delayvar_inv_1 (...) = delay.value_pt > 0 predicate listdelay_scalarinput_modeInv_1 (...) = delay.value_pt > 1 predicate listdelay_scalarinput_modeInv_2 (...) = let init_0 = init.value_pt in length init_0 = delay.value_pt (* Theory 2*) predicate listdelay_scalarinput_modeInv_2 (...) = let init_0 = init.value_pt in length init_0 = delay.value_inpg 3 – Generated verification goal (extract) goal Delay_completeness : forall reset_Algo : tReset_Algo_ResetParam_TResetAlgo , delay : tDelay_InternalDelay_TInt32 , init : tInit_InternalICMatrix_TMatrixDouble, ... delay_Simple_sig0 reset_Algo delay iC mem output input block / delay_Simple_sig1 reset_Algo delay mem iC output input block ... 4 – Verification output DelayComplet_Delay.why Delay_Verif Delay_completeness : Valid (2.01s) DelayComplet_Delay.why Delay_Verif Delay_disjointness : Valid (7.85s) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 18 / 33
- 19. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives 1 Context Context Use case The problem 2 BlockLibrary DSL Process Overview The Block Library DSL Verification of BlockLibrary specifications 3 Verification of the Generated Code Block Library Driven Translation Validation Example Handling loops 4 Conclusions and Perspectives A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 19 / 33
- 20. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Block Library Driven Translation Validation – Overview Formalisation of the input language Dataflow + Block library-specific concepts =⇒ BlockLibrary DSL Formalisation of the output languages C (current work): ANSI C + ACSL annotations (MISRA C subset) Ada (future work): Ada 2012 code + annotations (SPARK subset) SPEC#, JML, B, Eiffel, . . . (other possiblities): Equivalence relation between the input and output Generation of BlockLibrary-based formal contracts for concrete block instances and resp. code sections: Code structure + Semantics of init, update and compute code + Integration of blocks (dataflow) Verification framework: FRAMA-C + WP plugin + SMT solvers / Proof-assistants. A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 20 / 33
- 21. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Block Library Driven Translation Validation – Implementation Options Verification of a concrete run of the ACG – Black box approach Analyse the input model and extract block instances. Determine the configuration of blocks and derive corresponding specification instances. Generate respective contracts. Weave the contracts into the generated output code. Verify the annotated code (C + ACSL). A light-weight version – White box approach Instrument the ACG with additional manually or automatically derived source code to generate the annotations based on the BlockLibrary specifications. Generate annotated code. Pro: Much simpler to implement. Contra: Assumes the ACG source code is available. Contra: Risk of modifying the behavioural part of the output code. Contra: Lower confidence in the verification (common-mode). A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 21 / 33
- 22. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Block Library Driven Translation Validation – Black Box (Planned) Verification of a concrete run of the ACG – Black box approach Analyse the input model and extract block instances. A dedicated parser+analyser for serialised models OR A model analyser integrated into the modelling environment (SIMULINK) Determine the configuration of blocks and derive corresponding specification instances. Component in the BlockLibrary toolset Generate respective contracts. Component in the BlockLibrary toolset Weave the contracts into the generated output code. Dedicated FRAMA-C plugin. Uses traceability information provided by the ACG for mapping block instances and code sections Verify the annotated code (C + ACSL). FRAMA-C + WP plugin + SMT solvers A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 22 / 33
- 23. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Block Library Driven Translation Validation – White Box (Experimental) Instrumented version of the open source GENEAUTO ACG Verification of a concrete run of the ACG – White box approach Analyse the input model and extract block instances. Existing functionality in GENEAUTO Determine the configuration of blocks and derive corresponding specification instances. Dedicated manually written code in GENEAUTO Generate respective contracts. Dedicated manually written code in GENEAUTO Generates abstract contracts Weave the contracts into the generated output code. Dedicated manually written code in GENEAUTO Renders the abstract contracts as ACSL annotations during the final code printing phase Verify the annotated code (C + ACSL). FRAMA-C + WP plugin + SMT solvers A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 23 / 33
- 24. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Example: Translation Validation of the Counter System (1/3) void Counter_compute(t_Counter_io *_io_, t_Counter_state *_state_) { BOOL reset; BOOL LO; BOOL LO2; BOOL LO4; /" A "/ /" A "/ /" A "/ Counter_UD1 = _state_->UD1_memory; /" A "/ /" A "/ /" A "/ /" A "/ reset = _io_->reset; /" A "/ /" A "/ /" A "/ /" A "/ LO = !reset; /" A "/ /" A "/ /" A "/ /" A "/ Counter_LO1 = Counter_UD1 && LO; /" A "/ /" A "/ /" A "/ /" A "/ Counter_UD = _state_->UD_memory; /" A "/ /" A "/ /" A "/ /" A "/ LO2 = !Counter_UD; /" A "/ Code generation (GeneAuto) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 24 / 33
- 25. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Example: Translation Validation of the Counter System (2/3) void Counter_compute(t_Counter_io *_io_, t_Counter_state *_state_) { BOOL reset; BOOL LO; BOOL LO2; BOOL LO4; /" A "/ /" A "/ /" A "/ Counter_UD1 = _state_->UD1_memory; /" A "/ /" A "/ /" A "/ /" A "/ reset = _io_->reset; /" A "/ /" A "/ /" A "/ /" A "/ LO = !reset; /" A "/ /" A "/ /" A "/ /" A "/ Counter_LO1 = Counter_UD1 && LO; /" A "/ /" A "/ /" A "/ /" A "/ Counter_UD = _state_->UD_memory; /" A "/ /" A "/ /" A "/ /" A "/ LO2 = !Counter_UD; /" A "/ mode AndOp implements OtherOp { modeinvariant ocl { Operator.value = !! LogicOperator::AND } definition bal = compute_AndOp { postcondition ocl { S1.value = (E1.value and E2.value) } S1.value = E1.value && E2.value; } compute compute_AndOp } Code generation (GeneAuto) Mode resolution A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 24 / 33
- 26. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Example: Translation Validation of the Counter System (3/3) void Counter_compute(t_Counter_io *_io_, t_Counter_state *_state_) { BOOL reset; BOOL LO; BOOL LO2; BOOL LO4; /*@ ensures Counter_UD1 == _state_->UD1_memory; assigns Counter_UD1; */ { Counter_UD1 = _state_->UD1_memory; } /*@ ensures reset == _io_->reset; assigns reset; */ { reset = _io_->reset; } /*@ ensures LO == !reset; assigns LO; */ { LO = !reset; } /*@ ensures Counter_LO1 == (Counter_UD1 && LO); assigns Counter_LO1; */ { Counter_LO1 = Counter_UD1 && LO; } /*@ ensures Counter_UD == _state_->UD_memory; assigns Counter_UD; */ { Counter_UD = _state_->UD_memory; } /*@ ensures LO2 == !Counter_UD; assigns LO2; */ { LO2 = !Counter_UD; } mode AndOp implements OtherOp { modeinvariant ocl { Operator.value = !! LogicOperator::AND } definition bal = compute_AndOp { postcondition ocl { S1.value = (E1.value and E2.value) } S1.value = E1.value && E2.value; } compute compute_AndOp } Code generation (GeneAuto) Mode resolution Annotation generation A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 24 / 33
- 27. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Example: Translation Validation of the Counter System (4) [wp] Running WP plugin... [wp] Collecting axiomatic usage [rte] annotating function Counter_compute [rte] annotating function Counter_init [wp] 53 goals scheduled [wp] [Qed] Goal typed_Counter_compute_assign_part1 : Valid ... [wp] [Qed] Goal typed_Counter_compute_stmt_post : Valid [wp] [Qed] Goal typed_Counter_compute_stmt_assign : Valid [wp] [Qed] Goal typed_Counter_compute_stmt_post_2 : Valid (4ms) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_2 : Valid [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_3 : Valid (36ms) (27) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_3 : Valid [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_4 : Valid (Qed:4ms) (40ms) (32) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_4_part1 : Valid ... [wp] [Qed] Goal typed_Counter_compute_stmt_post_5 : Valid (4ms) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_5 : Valid [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_6 : Valid (Qed:4ms) (52ms) (41) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_6 : Valid [wp] [Qed] Goal typed_Counter_compute_stmt_post_7 : Valid (4ms) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_7_part1 : Valid ... [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_post_8 : Valid (Qed:4ms) (60ms) (39) [wp] [Qed] Goal typed_Counter_compute_stmt_assign_8_part1 : Valid ... [wp] [Qed] Goal typed_Counter_compute_stmt_post_9 : Valid (4ms) [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_9 : Valid (Qed:8ms) (40ms) (34) [wp] [Qed] Goal typed_Counter_compute_stmt_post_10 : Valid (8ms) [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_10 : Valid (36ms) (34) [wp] [Qed] Goal typed_Counter_compute_stmt_post_11 : Valid [wp] [Alt-Ergo] Goal typed_Counter_compute_stmt_assign_11 : Valid (Qed:4ms) (44ms) (34) [wp] [Alt-Ergo] Goal typed_Counter_init_assign_part1 : Valid (28ms) (16) [wp] [Alt-Ergo] Goal typed_Counter_init_assign_part2 : Valid (32ms) (16) [wp] [Qed] Goal typed_Counter_init_stmt_post : Valid [wp] [Alt-Ergo] Goal typed_Counter_init_stmt_assign : Valid (32ms) (18) [wp] [Qed] Goal typed_Counter_init_stmt_post_2 : Valid [wp] [Alt-Ergo] Goal typed_Counter_init_stmt_assign_2 : Valid (32ms) (18) [wp] Proved goals: 53 / 53 Qed: 31 (4ms-8ms) Alt-Ergo: 22 (28ms-192ms) (247) A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 25 / 33
- 28. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Handling of loops (1/2) Automated deductive verification of loop constructs is still challenging. Explicit loop invariants and loop variants must be often given for the verification to succeed. Practical control algorithms contain a lot of non-scalar, i.e. vector and matrix calculations. Leading to code with many loops . . . assignments between matrices or their parts, element-wise application of mathematical functions, matrix multiplication, transpose etc. The semantics of these loops is given in the specification. However, it is impractical to write out all the low-level loops, their invariants and variants in the specification. Instead, the specification of behaviour could be given via a formal post-condition and/or rely on higher-level operators not present in the target language. A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 26 / 33
- 29. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Handling of loops (2/2) The ACG must implement the behaviour given in the specification. Problem: The verification framework must infer the intended semantics of the generated loops. Manual derivation and addition of loop invariants and variants into the generated low-level code is not really a good option . . . Solution? The ACG knows the intended semantics of all of these loops. Use hints provided by the ACG. We can let the ACG generate these loop invariants and variants. But, it must not introduce any contradiction or false axiom to the axiom set. Otherwise, the verification can show incorrect code to be “correct”! Alternative: Use traceability information provided by the ACG to identify the operator that the loop implements and construct the invariants and variants on the side of the verification framework. A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 27 / 33
- 30. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Loop annotation example (1/4) This example requires a loop in the update function to shift all elements in the memory by one. The annotated version of the generated C code should contain: a loop invariant and a loop variant for the verification to succeed automatically. 1 mode DelayMode_List implements ALT ( ListDelay_ScalarInput, 2 ListDelay_VectorInput, ListDelay_MatrixInput) 3 { 4 definition bal = init { 5 postcondition ocl { Mem.value = Init.value } 6 Mem.value := Init.value; } 7 definition bal = compute { 8 postcondition ocl 9 { Output.value = Mem.value->first() } 10 Output.value := Mem.value[0]; } 11 definition bal = update { 12 postcondition ocl { 13 Mem.value = Mem.value->excluding( 14 Mem.value->first())->append(Input.value)} 15 var iter = 0; 16 while (iter < (Delay.value - 1)){ 17 invariant { 0 <= iter && iter < Delay.value } 18 invariant { 19 Set{0 .. iter}->forAll(i | (0 <= i && i < iter) 20 implies (Mem.value->subList(1,i) = 21 (Mem.value@pre)->subList(2,i+1))) } 22 variant { Delay.value - iter } 23 Mem.value[iter] := Mem.value[iter + 1]; 24 iter := iter + 1; 25 } 26 Mem.value[Delay.value - 1] := Input.value; 27 } 28 } A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 28 / 33
- 31. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Loop annotation example (2/4) Here, the annotations have been explicitly included in the specification (lines 17-22). Manually specifying loop annotations for routine operations is tedious and error-prone. The annotations must also be translated and fine-grain woven into the generated code. 1 mode DelayMode_List implements ALT ( ListDelay_ScalarInput, 2 ListDelay_VectorInput, ListDelay_MatrixInput) 3 { 4 definition bal = init { 5 postcondition ocl { Mem.value = Init.value } 6 Mem.value := Init.value; } 7 definition bal = compute { 8 postcondition ocl 9 { Output.value = Mem.value->first() } 10 Output.value := Mem.value[0]; } 11 definition bal = update { 12 postcondition ocl { 13 Mem.value = Mem.value->excluding( 14 Mem.value->first())->append(Input.value)} 15 var iter = 0; 16 while (iter < (Delay.value - 1)){ 17 invariant { 0 <= iter && iter < Delay.value } 18 invariant { 19 Set{0 .. iter}->forAll(i | (0 <= i && i < iter) 20 implies (Mem.value->subList(1,i) = 21 (Mem.value@pre)->subList(2,i+1))) } 22 variant { Delay.value - iter } 23 Mem.value[iter] := Mem.value[iter + 1]; 24 iter := iter + 1; 25 } 26 Mem.value[Delay.value - 1] := Input.value; 27 } 28 } A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 29 / 33
- 32. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Loop annotation example (3/4) Routine operations on non-scalar data can be integrated into the DSL as primitives or defined via higher-level operators. E.g. line 15 instead of former lines 15-26. The primitives and higher-level operators are automatically expanded with appropriate annotations. 1 mode DelayMode_List implements ALT ( ListDelay_ScalarInput, 2 ListDelay_VectorInput, ListDelay_MatrixInput) 3 { 4 definition bal = init { 5 postcondition ocl { Mem.value = Init.value } 6 Mem.value := Init.value; } 7 definition bal = compute { 8 postcondition ocl 9 { Output.value = Mem.value->first() } 10 Output.value := Mem.value[0]; } 11 definition bal = update { 12 postcondition ocl { 13 Mem.value = Mem.value->excluding( 14 Mem.value->first())->append(Input.value)} 15 Vector_Shift_Left1(Mem.value, Input.value) 16 } 17 } 18 } A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 30 / 33
- 33. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Loop annotation example (4/4) Example: Delay block instance with: scalar input, static delay length, delay length value = 2. C code generated by GENEAUTO and annotated with ACSL annotations derived from BlockLibrary. /* START Block memory write: <SequentialBlock: name=Delay2> */ /*@ ensures append: _state_->Delay2_memory[1] == system_In1; ensures sublist: forall integer i; 0 <= i < 1 ==> _state_->Delay2_memory[i] == old(_state_->Delay2_memory[i+1]); */ {/*@ loop invariant forall integer i; 0 <= i < iter ==> _state_->Delay2_memory[i] == at(_state_->Delay2_memory[i+1],LoopEntry); loop invariant 0 <= iter < 2; loop assigns iter, _state_->Delay2_memory[0]; loop variant 1 - iter; */ for (int iter = 0; iter < 1; iter++){ _state_->Delay2_memory[iter] = _state_->Delay2_memory[iter+1]; } _state_->Delay2_memory[1] = system_In1;} /* END Block memory write: <SequentialBlock: name=Delay2> */ A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 31 / 33
- 34. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives 1 Context Context Use case The problem 2 BlockLibrary DSL Process Overview The Block Library DSL Verification of BlockLibrary specifications 3 Verification of the Generated Code Block Library Driven Translation Validation Example Handling loops 4 Conclusions and Perspectives A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 32 / 33
- 35. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Conclusions and Perspectives BlockLibrary specification DSL Captures a practical, rich and highly variable modelling language (SIMULINK). Relies on standard and well-known MDE technologies. Adapted for reuse, evolution, maintenance and verification. Allows for the formal verification of Automatic Code Generators. And also, formal verification of low-level designs at the code level. Demonstration on a white box approach. Perspectives Automatic validation of specifications by simulation in the modelling environment (SIMULINK). Automatic generation of test cases from specifications. Implementation of the black box approach. Translation and verification against system-level contracts expressed e.g. as synchronous observers. Applying and extending the BlockLibrary DSL in an industrial setting: QGen ACG. A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 33 / 33
- 36. Context BlockLibrary DSLVerification of the Generated Code Conclusions and Perspectives Related Links Thanks for your attention! http://block-library.enseeiht.fr/html A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 34 / 33