Presentation of the use of the Block Library domain specific language for the translation validation of automated generated code at the FMICS-AVOCS 2016 workshop in Pisa, Italia.

1. Block Library Driven Translation 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 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

16. Context BlockLibrary DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 DSL Verification 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 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

28. Context BlockLibrary DSL Verification 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 DSL Verification 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 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

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

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

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

34. Context BlockLibrary DSL Verification 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 DSL Verification 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 DSL Verification 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