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

Block Library Driven Translation Validation forDataflow Models in Safety Critical Systems

Arnaud Dieumegard1 Andres Toom234 Marc Pantel2

1Institut de Recherche Technologique Antoine de Saint Exupéry118 route de Narbonne, CS 44248, 31432 Toulouse Cedex 4, France

2Institut de Recherche en Informatique de Toulouse, Université de ToulouseENSEEIHT, 2 rue Charles Camichel, 31071 Toulouse Cedex, France

3Institute of Cybernetics at Tallinn University of TechnologyAkadeemia tee 21, EE-12618 Tallinn, Estonia

4IB Krates OÜ, Mäealuse 4, EE-12618 Tallinn, Estonia

Work funded by research projects OPEES and PROJET P

Context BlockLibrary DSL Verification of the Generated Code Conclusions and Perspectives

1 ContextContextUse caseThe problem

2 BlockLibrary DSLProcess OverviewThe Block Library DSLVerification of BlockLibrary specifications

3 Verification of the Generated CodeBlock Library Driven Translation ValidationExampleHandling loops

4 Conclusions and Perspectives

A.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 2 / 33








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)



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 withModified 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


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 thanhand-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)



Data Flow Languages

Graphical data flow language structure

Parameter: Sign = ”++”

Mono-clock system/block Semantics



High Variability of the Block’s Structure and Semantics

Delay blockNumber of structural configurations: 144

Number of “algorithms” (semantic functions): 12

Block Ports Parameters Memories Semantics

InOut

DelayInit

DelayMemoryOutn+1 = Inn

Out0 = Init

InOutDelay

Init DelayMemory

Outn+Delay = Inn

Out0 = Init(0)...OutDelay−1 = Init(Delay−1)

......

......

...



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 forall 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 inputlanguage

Issue: Most ACG input languages specifications are semi-formalA.Dieumegard A.Toom M.Pantel Block Library Driven Translation Validation 9 / 33








Block Library Driven Specification and Development Process

MyModel.mdl

Model BlockLibraryBlockLibrary Specification

BlockLibrary DSL(ecore + OCL + syntax)

Dataflow modelling toolset (Simulink, ...) BlockLibrary modelling toolset

Instance ofSpecifies

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


Use

MyBL.mdl MyBL.bls


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

BlockLibraryToolset

Specifies

Instance of

Instance of

Why3Verification Tool

Formal verification toolset

StaticBlockLibraryFormalisation

DataTypes

OCL

BlockLibraryLanguageConstructs

Structure and variabilityVerification Goals

+Blocks Semantics

Conforms to

SMT solvers

ImplementsCode GenerationTool

Code generationbackends

SourceCode

Use

Annotations

Expresses

Code verificationtool (Frama-C, Spark, ...)

Translated to

Verifies

Verifies

Proof Assistant

Use



Key Block-Related Development Aspects

Structural definitionPorts, parameters, memoryConstraints

Semantic definition

axiomatic: pre-conditions / post-conditionsoperational: algorithm

Variability managementPolymorphism wrt. data types, dimensionality and basicoperationsComplexity management

User accessibility (specification designers and users)Ease of writing, understanding and automated analysisof specifications



Language Modeling Solution (SPLC 2014)

Issues:Language sizeand complexity

⇒ Unbounded language useTool development cost

Proposed solutionDomain-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 ontransformations



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



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

MemoryConstraints

Constraints

Constraints

ref

ref

ref

DataType

...



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 themodelling environment



Verification Strategy: Translation to Why3

Why3Utheory

Why3Umodule

DataTypes

Predicates

DisjointnessCompleteness

Goals

ConfigurationTransformation

ConfigurationPredicate

GoalsUExtraction

BlockUDomainTransformation

Why3Utheory

Use

SemanticsUstepFunctionsSemanticsU

VerificationTransformation

Use

initcomputeupdate

BlockLibrary BV

BM

BlockType

BlockMode BM

BlockVariant

Constraints

Pre PostAction

...

...

BV

Constraints

Parameter

Port

MemoryConstraints

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


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 outputDelayComplet_Delay.why Delay_Verif Delay_completeness : Valid (2.01s)DelayComplet_Delay.why Delay_Verif Delay_disjointness : Valid (7.85s)









Block Library Driven Translation Validation – Overview

Formalisation of the input languageDataflow + Block library-specific concepts =⇒ BlockLibrary DSL

Formalisation of the output languagesC (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 outputGeneration of BlockLibrary-based formal contracts for concreteblock 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.



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 correspondingspecification 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 automaticallyderived source code to generate the annotations based on theBlockLibrary 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).



Block Library Driven Translation Validation – Black Box (Planned)

Verification of a concrete run of the ACG – Black box approachAnalyse the input model and extract block instances.

A dedicated parser+analyser for serialised models ORA model analyser integrated into the modelling environment(SIMULINK)

Determine the configuration of blocks and derive correspondingspecification 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 providedby the ACG for mapping block instances and code sections

Verify the annotated code (C + ACSL).

FRAMA-C + WP plugin + SMT solvers



Block Library Driven Translation Validation – White Box (Experimental)

Instrumented version of the open source GENEAUTO ACGVerification 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 correspondingspecification 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 thefinal code printing phase

Verify the annotated code (C + ACSL).FRAMA-C + WP plugin + SMT solvers



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)




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

}


Mode resolution




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

}


Mode resolution

Annotationgeneration



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)



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 theverification to succeed.

Practical control algorithms contain a lot of non-scalar, i.e. vector andmatrix calculations. Leading to code with many loops . . .

assignments between matrices or their parts, element-wiseapplication of mathematical functions, matrix multiplication,transpose etc.

The semantics of these loops is given in the specification. However, it isimpractical to write out all the low-level loops, their invariants andvariants in the specification.

Instead, the specification of behaviour could be given via a formalpost-condition and/or rely on higher-level operators not present inthe target language.



Handling of loops (2/2)

The ACG must implement the behaviour given in the specification.

Problem: The verification framework must infer the intendedsemantics of the generated loops.

Manual derivation and addition of loop invariants and variants into thegenerated 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 tothe axiom set.Otherwise, the verification can show incorrect code to be “correct”!

Alternative: Use traceability information provided by the ACG toidentify the operator that the loop implements and construct theinvariants and variants on the side of the verification framework.



Loop annotation example (1/4)

This examplerequires a loop in theupdate function toshift all elements inthe memory by one.

The annotatedversion of thegenerated C codeshould contain:a loop invariant anda loop variant forthe verification tosucceedautomatically.

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 ocl9 { 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 }




Here, the annotationshave been explicitlyincluded in thespecification(lines 17-22).

Manually specifyingloop annotations forroutine operations istedious anderror-prone.

The annotationsmust also betranslated andfine-grain woveninto the generatedcode.



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 }




Routine operationson non-scalar datacan be integratedinto the DSL asprimitives or definedvia higher-leveloperators.

E.g. line 15 insteadof former lines 15-26.

The primitives andhigher-leveloperators areautomaticallyexpandedwith appropriateannotations.



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 }




Example: Delayblock instancewith:

scalar input,static delaylength,delay lengthvalue = 2.

C codegenerated byGENEAUTO andannotated withACSLannotationsderived fromBlockLibrary.

/* 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> */









Conclusions and Perspectives

BlockLibrary specification DSLCaptures 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.

PerspectivesAutomatic validation of specifications by simulation in themodelling environment (SIMULINK).Automatic generation of test cases from specifications.Implementation of the black box approach.Translation and verification against system-level contractsexpressed e.g. as synchronous observers.Applying and extending the BlockLibrary DSL in an industrialsetting: QGen ACG.



Related Links

Thanks for your attention!

http://block-library.enseeiht.fr/html


http://block-library.enseeiht.fr/html

Date post:	13-Apr-2017
Category:	Engineering
Upload:	marc-pantel
View:	75 times
Download:	0 times