Refinement of AADL Models for the Synthesis of Embedded Systems Etienne Borde etienne.borde@telecom-paristech.fr
AADL: Architecture Analysis and Design Language We use AADL to model SCES architectures: It is standardized (by the SAE), which guarantees interoperability of different tools It provides a clear and precise semantics, which is also standardized It federates a community of users that focus on each of the aspect mentioned earlier: - Requirements specification - Models analysis - Code generation page 2
A simplified MDE process in a nutshell Requirements definition Rigorous yet abstract representation of the system Verification 1 2 Formal models Generated code 1: Transformation into verifiable properties and models 2: Code generation page 3
Issue with code generation Code generation implies an alteration of the software architecture Ports are mapped into variables identifying ports, Some connections are mapped into queues, potentially requiring protected resources, Modes may require additional threads to manage mode transitions, Health monitoring require faults detection and recovery mechanisms, etc, etc, etc Impact on analysis results? page 4
A simplified MDE process in a nutshell Impact of code generation on analysis results? Requirements definition Rigorous yet abstract representation of the system Verification 1 2 Formal models Generated code Conformance? Problem: consistency between 1 and 2? page 5
First contribution of Reduce the semantic gap between analysed model and deployed system Requirements definition AADL Rigorous yet abstract representation of the system Verification 2 1 Rigorous and (more) precise representation of the system AADL Formal models Generated code page 6
Example of input (ARINC653) AADL model ARINC partition Periodic task T1 Period = 20 Ms Priority = 5 Subprogram_Call: {op1} Sporadic task T4 Periodic Task T2 Period = 10 Ms Priority = 2 Subprogram_Call: {op2} Periodic task T3 Par$$on run$me Scheduling=FPS Bus Scheduling=RMS Scheduling=FPS page 7
First contribution of Requirements definition Verification AADL 2 This techniques paves the way for interleaving analysis and AADL-to-AADL transformations 1 Formal models AADL Generated code It is now implemented as a workflow, describing model transformations, analysis steps, and decisions. page 8
Example of refinement for code generation ARINC partition Periodic task T1 Period = 20 ms Priority = 5 Subprogram_Call: {op1} Periodic Task T2 Period = 10 ms Priority = 2 Subprogram_Call: {op2} ARINC partition Task T1 Priority = 5 Subprogram_Call: { op1;display_blackboard; PERIODIC_WAIT(20) } Periodic Task T2 Priority = 2 Subprogram_Call: { READ_BLACKBOARD;op2; PERIODIC_WAIT(10) } data Par$$on run$me Scheduling=FPS Par$$on run$me Scheduling=FPS page 9
Analysis precision ARINC partition Periodic task T1 Period = 20 ms Priority = 5 Subprogram_Call: {op1} Periodic Task T2 Period = 10 ms Priority = 2 Subprogram_Call: {op2} ARINC partition Task T1 Priority = 5 Subprogram_Call: { op1;display_blackboard; PERIODIC_WAIT(20) } Periodic Task T2 Priority = 2 Subprogram_Call: { READ_BLACKBOARD;op2; PERIODIC_WAIT(10) } data Par$$on run$me Scheduling=FPS Additional CPU consumptions Par$$on run$me Scheduling=FPS Additional memory consumptions page 10
Input semantics variability ARINC partition Periodic task T1 Period = 20 ms Priority = 5 Subprogram_Call: {op1} Periodic Task T2 Period = 10 ms Priority = 2 Subprogram_Call: {op2} Timing=>delayed Default output_rate property value Dequeue_protocol=>AllItems This subset of AADL can be implemented as a lock-free queue [ISORC2013] Removing the delayed property association to another value changes the implementation Similarly, changing the target platform from ARINC to OSEK requires to adapt the code generation. relies on model transformation design pattern to ensure adaptability (template method, strategy, adapter, etc ) [ICECCS2012] page 11
Model Transformations and code generation for AADL BA Code generator for the BA (subset) is integrated in the refinement process Periodic task T1 Period = 20 ms BA: {** **} S1 (initial, complete) Periodic task T1 Period = 20 ms Calls {entry_point} entry (initial) BA {** **} entry_point -[current_state=s1] / {f1();await_dispatch()} -[on dispatch]/f3() -[on dispatch]/f1() -[current_state=s2] / {f2();await_dispatch()} -[on dispatch]/f2() S3 (complete) S2 (complete) -[current_state=s3] / {f3();await_dispatch()} fini (initial) page 12
Consequences on the code generation part Code generation becomes a very simple application Generic code generation for data types, data subcomponents, subprograms, subprogram calls, etc Target specific code generation for initialization of OS data structures (tasks, routing of messages, etc ) ARINC partition Task T1 Priority = 5 Subprogram_Call: { op1;display_blackboard; PERIODIC_WAIT(20) } Periodic Task T2 Priority = 2 Subprogram_Call: { READ_BLACKBOARD;op2; PERIODIC_WAIT(10) } data page 13
Integration status of Directly integrated with the developemennt branch of OSATE (IDE) Open-source, available on our public svn Relies on OS with standardised APIs (uses APEX) Non regression tests based on the open source POK project OSATE, open-source project POK, open-source project page 14
Ongoing and future works Requirements driven selection of model transformations (design space exploration) Interactions with Lab-STICC and UPV on this topic Deployment of generated code on COTS commercial ARINC 653 Operating Systems Interactions with SEI and ISAE Improve the integration of and AADL Inspector Interactions with Ellidiss page 15