Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Block Library Driven Translation Validation for
Dataflow Models in Safety Critical Systems
Arnaud Dieumegard1
Andres Toom23...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
1 Context
Context
Use case
The pro...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
1 Context
Context
Use case
The pro...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Safety Critical Embedded Systems
S...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Classical Process of Embedded Syst...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Modern Process of Embedded Systems...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Data Flow Languages
Graphical data...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
High Variability of the Block’s St...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
The problem - Is the generated cod...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
1 Context
Context
Use case
The pro...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Block Library Driven Specification ...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Key Block-Related Development Aspe...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Language Modeling Solution (SPLC 2...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
BlockLibrary Specification DSL – Bl...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
BlockLibrary Specification DSL – Bl...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Verification and Validation of Bloc...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Verification Strategy: Translation ...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Verification of the Disjointness an...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
1 Context
Context
Use case
The pro...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Block Library Driven Translation V...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Block Library Driven Translation V...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Block Library Driven Translation V...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Block Library Driven Translation V...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Example: Translation Validation of...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Example: Translation Validation of...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Example: Translation Validation of...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Example: Translation Validation of...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Handling of loops (1/2)
Automated ...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Handling of loops (2/2)
The ACG mu...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (1/4)
This...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (2/4)
Here...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (3/4)
Rout...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Loop annotation example (4/4)
Exam...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
1 Context
Context
Use case
The pro...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Conclusions and Perspectives
Block...
Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives
Related Links
Thanks for your atte...
Upcoming SlideShare
Loading in …5
×

Block Library Driven Translation Validation for DataFlow Models in Safety Critical Systems

283 views

Published on

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.

Published in: Engineering
  • Very nice tips on this. In case you need help on any kind of academic writing visit website ⇒ www.HelpWriting.net ⇐ and place your order
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I can advise you this service - ⇒ www.WritePaper.info ⇐ Bought essay here. No problem.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Block Library Driven Translation Validation for DataFlow Models in Safety Critical Systems

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

×