AADL execution semantics transformation for formal verification

1LiSyC ENSIETA/DTN 02/04/2008

AADL execution semantics transformation for formal

verification

Joel Champeau, Thomas Abdoul, Pierre Yves Pillain, Philippe Dhaussy, Jean Charles Roger

LiSyCENSIETA/DTN

[email protected]


Context

• MDD approach for embedded systems

• MDD approach provides opportunity to develop or to couple analysis methods and tools.

• Multiformalism inputs for a same formal technique.

• Improvements of modeling techniques for this purpose:– View point dedicated to behavioral analysis.– Including execution models in metamodels


Observer Based Prover (OBP) Environment

Simulation &exploration

ofTransition

system

Property Observer

Restriction Automata

Context Automata

System

Composition

IF-2 Programs

Transformations

Models(SDL, UML, AADL)

Formal model(IF-2)

Platform Models

Diagnostic Models Diagnostics

Plugging Eclipse / TopCased

OBP platform is developed in the TOPCASED project context*

Requirement and

context Models(CDL)

* Granded by French industry ministry


Contents

• Introduction

• Used formalisms in the transformation– Target language : IF Language– Source language : AADL execution model

• AADL model transformation– Transformation context– Structure– Behavior– Execution semantics

• Experiments and analysis

• Conclusion


Introduction

• Multiformalism approach context

• Capitalization on: – Formal verification technique based on

Observer with a tool (OBP)– Design modular and reusable transformations

• Improve the execution semantic modeling in the metamodel.


Contents

• Introduction

• Used formalisms in the transformation

• AADL model transformation


• Conclusion


IF language

• If language is used in the IFx framework:– If simulator– Reachability graph for analysis– Time is discrete or dense.

• If language – The system entity is the root concept– A system is composed of active entities = process– The processes are timed automata– The processes interact with signal based on asynchronous

communications.

• Advantages of the IF language– Timed behavior modeling– Asynchronous communication– Efficient tooling


AADL language

• Based on hierarchical definition of components:– Software and hardware categories– Connection and port for communication– Behavior annex to describe the inside component behavior.

• NTIF language for our purpose, due to its clear and precise semantics.– Execution model precisely defined:

• Process and Thread management• Concept of mode

• AADL properties – Adding dedicated information– Standard and custom properties

• Properties for execution model– Subprogram invocation = Server_Call_Protocol (Synchronous, half synchronous

or asynchronous)– Dispatch_Protocol = period value for periodical Threads– Port mechanism with Queue_Size, Queue_Processing_Protocol,

Overflow_Handling_Protocol


AADL language

• Control automaton for Thread dispatch protocol– Without modes

Thread initialization

Wait For Dispatch

Thread Computation

complete initialization assert t <= Initialize_Deadline

? Enabled(t)Dispatch computation t<- 0

complete computationassert t <= Compute_Deadline t<- 0

Thread halted

<EventDataPort> a

<EventPort> b

Buffer (Port a)

Internal counter (Port b)

AADL Thread

3

a a a

b

a a


AADL language

• Control automaton for Thread dispatch protocol


Wait For Dispatch

Thread Computation




Thread halted

<EventDataPort> a

<EventPort> b

Buffer (Port a)


AADL Thread

1

a a


AADL language

• Control automaton for Thread dispatch protocol


Wait For Dispatch

Thread Computation




Thread halted

<EventDataPort> a

<EventPort> b

Buffer (Port a)


AADL Thread

3

a a a

b

a a


Contents

• Introduction

• Used formalisms in the transformation

• AADL model transformation


• Conclusion


Transformation context

• Eclipse/EMF framework

• IF metamodel created– 120 metaclasses with 17 abstract classes

• AADL metamodel – Standard Eclipse implementation– 254 metaclasses with 56 abstract classes– NTIF metamodel created for behavior annex

• Kermeta metalanguage [INRIA/Triskell]– For complementary metamodeling – Transformation with Visitor pattern


Structure transformation

• Validation purpose, focus on:– Behavior of software components– Process and Thread with port management

• Basic concept equivalences– AADL SystemImpl to IF System– AADL data types to IF types– Process and Thread to IF process

• Port and properties – Port management with Event and EventData to IF Signals with

independent process– Time value of the thread Dispatch_Protocol property memorized and

processed.

• Conclusion– Static structure mapped to the IF structure– Execution information via properties are memorized


Behavior transformation

• Including :– Behavior description with the NTIF language– AADL Subprogram management

• Behavior description– NTIF and IF are closed– But NTIF provides high level instructions, like Select:

• Several transition out of a state to intermediate states with property on transitions

• AADL Subprogram – Property Server_Call_Protocol = HSER (synchronous call)


Behavior transformation• IF result for a subprogram call.

state Producer_Receive;deadline eager;provided put_bitReceives = 7;

fork process_subprogram_put(word,self);nextstate Producer_Receive_wait_put;….

endstate;

state Producer_Receive_wait_put;deadline eager;input put_return();

task put_bitReceives := 0;nextstate Producer_End;

endstate;

state Producer_End;….Endstate;


Execution model transformation

• Execution model is not explicitly in the metamodel definition– Definition is splitted in several

properties– Control automaton for thread

management only in the standard

• Control automaton– States are added– IF clocks for transition guards– Thread computation state is the

behavior of the thread


Wait For Dispatch

Thread Computation




Thread halted



• Port management and the dispatch protocol

<EventDataPort> a

<EventPort> b

Internal buffer (Port a)


1

a a

b b

a a a

IF DispatchProcess

a a a

2

IF ThreadProcess

a a

1

« public »Control and data signals

AADL Thread



• To improve the execution model transformation:– 2 metaclasses added:

• DispatchBehavior– Properties to control the dispatch mechanism.– Queue_Processing_Protocol, Queue_Processing_Protocol,

Dispatch_Protocol, …• Behavior

– Entry point for the behavior– Execution deadline with the value of Thread_Comptutation_Deadline

• Control automaton management (3 versions)1. Hard coded in the transformation2. IF model loaded3. Beginning of a metamodeled definition to complete the

AADL metamodel


Experiments and analysis

• Application on Sensor/Filter model– Real time application with different frequencies for the threads– Sporadic and period threads

• Transformation metrics– AADL model

• 417 objects from 62 metaclasses (out of 254, and 56 abstracts)– IF Model

• 512 objects from 59 metaclasses (out of 120 and 17 abstracts)

• IF model growing– The behavior transformation creates more transitions and states– The execution model is not explicitly defined in the source model.

• Execution model metaclasses instantiated before applying transformation.

• Modular transformation implementation based on 3 parts:– Structure– Behavior– Execution model


Conclusion

• AADL to IF transformation – AADL metamodel analysis– Execution model analysis for our purpose– Modular and reusable implementation

• Using Kermeta:– Adding concepts by metamodel veawing.

• Any impact on the ECore “standard” implementation– Transformation implementation with the extended

metamodel.

• Future works– Complete the transformation.– Test on other AADL models– Improve the execution model definition

• Adding the control automaton definition in the metamodel


Questions ?

Documents

AADL execution semantics transformation for formal verification