AADL execution semantics transformation for formal verification

1. AADL execution semantics transformation for formal verification Joel Champeau, Thomas Abdoul, Pierre Yves Pillain, Philippe Dhaussy, Jean Charles Roger LiSyC ENSIETA/DTN joel.champeau@ensieta.fr

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

3. Observer Based Prover (OBP) Environment OBP platform is developed in the TOPCASED project context* Models (SDL, UML, AADL) Plugging Eclipse / TopCased IF-2Programs System Transformations Requirement and context Models (CDL) Formal model (IF-2) Simulation & exploration of Transition system Property Observer Context Automata Platform Models Restriction Automata Composition Diagnostic Models Diagnostics * Granded by French industry ministry

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

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

6. Contents • Introduction • Used formalisms in the transformation • AADL model transformation • Experiments and analysis • Conclusion

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

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

9. a a a a a 3 b Thread halted Thread initialization complete initialization assert t <= Initialize_Deadline Wait For Dispatch ? Enabled(t) Dispatch computation t<- 0 complete computation assert t <= Compute_Deadline t<- 0 Thread Computation AADL language • Control automaton for Thread dispatch protocol • Without modes AADLThread Buffer (Port a) <EventDataPort> a Internal counter (Port b) <EventPort> b

10. a a 1 Thread halted AADL language • Control automaton for Thread dispatch protocol AADLThread Buffer (Port a) <EventDataPort> a Thread initialization complete initialization assert t <= Initialize_Deadline Internal counter (Port b) <EventPort> b Wait For Dispatch ? Enabled(t) Dispatch computation t<- 0 complete computation assert t <= Compute_Deadline t<- 0 Thread Computation

11. a a a a a 3 b Thread halted Thread initialization complete initialization assert t <= Initialize_Deadline Wait For Dispatch ? Enabled(t) Dispatch computation t<- 0 complete computation assert t <= Compute_Deadline t<- 0 Thread Computation AADL language • Control automaton for Thread dispatch protocol AADLThread Buffer (Port a) <EventDataPort> a Internal counter (Port b) <EventPort> b

12. Contents • Introduction • Used formalisms in the transformation • AADL model transformation • Experiments and analysis • Conclusion

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

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

15. 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)

16. 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;

17. 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 Thread halted Thread initialization complete initialization assert t <= Initialize_Deadline Wait For Dispatch ? Enabled(t) Dispatch computation t<- 0 complete computation assert t <= Compute_Deadline t<- 0 Thread Computation

18. a a a a a 1 b b a a a a a 2 1 Execution model transformation • Port management and the dispatch protocol AADLThread Internal buffer (Port a) <EventDataPort> a Internal counter (Port b) <EventPort> b IF DispatchProcess IF ThreadProcess Control and data signals « public »

19. Execution model transformation • 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) • Hard coded in the transformation • IF model loaded • Beginning of a metamodeled definition to complete the AADL metamodel

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

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

22. Questions ?