architecture analysis & design languagearchitecture analysis & design language julien...

Julien Delange <julien dot delange at esa dot int>

Architecture Analysis & Design Language

Julien Delange <[email protected]>

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or

send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.


Overview

• Introduction to the AADL

• Language overview

• System validation using AADL

• Code generation

• Conclusion & perspectives


General picture

• Capture hardware & software concerns• Binding between application & execution runtime

• Safety-critical oriented• Military, avionics, aerospace, …

• Description of real-time requirements

• Components-based approach

• Extensible


Bits of AADL history

• Inherits from Meta-H modeling language

• AADLv1, 2003

• AADLv2, 2008• New components

• Language extensions, support namespace

• Textual (TXT/XML) & graphic format• Ease communication

• Better tool support


Examples of AADL use

• Error modeling & dependability analysis (COMPASS)• Extension of AADL for error specification

• Avionics system analysis (AVSI, POK, Ocarina)• Detect errors earlier in avionics software development

• System implementation (TASTE)• Automatic integration of app & hard concerns

• Scheduling analysis (Cheddar)• Evaluate system requirements


Other approaches

• UML & MARTE profile• Inheritance of SPT profile

• Inaccurate semantics for system modeling

• Few available tools for system analysis

• No code generation tools

• SysML• System-oriented

• Loosely coupled with software concerns

• Limited toolset


Overview




• Code generation



One language, three representations

• Graphic• Convenient for communication

• High-level modeling

• Textual• Describe components properties

• Fine-grained modeling

• Easy to process for programs

• XML• Inter-exchange format


Types and implementations

• Component type• Define basic components characteristics

• Declare component interfaces

• Component implementation• Contain subcomponents

• Connect interfaces with subcomponents

• Redefine some requirements

• Inheritance & extension• Add more requirements/properties

system mysystemfeatures [ports and access decl]end mysystem;

system implementation mysystem.isubcomponents [subcomp decl]connections [connect ports and accesses]end mysystem.i;


Components interfaces (features)

• Ports• Data port: latest written, latest available, no queue

• Event port: notification, queued events

• Event data port: queued data

• Access• Requires or provides access to a component

• Ex: I need an access to a data/bus

system mysystemfeatures dataout : data port mytype.impl; eth_access : requires bus access ethernet.1Gb;end mysystem;

dataout

eth_access


Properties

• AADL entities requirements• Association with components, ports and access

• Strongly typed, not just strings

• Declaration using properties section or brackets

• Predefined properties and potential extensions• Define your own types and properties

process theprocessfeatures dataout : event port {Queue_Size => 1;};properties Source_Data_Size => 1 Kbyte;end theprocess;

process implementation theprocess.implsubcomponents T1 : thread the_thread.impl {Dispatch_Protocol => periodic;};connections port T1.dataout → dataout {Actual_Connection_Binding => …;};end theprocess.impl;


Annex languages

• Extend AADL semantics• Bind additional language to components

• Describe other properties/requirements to AADL models

• Several annex language already integrated• Behavior (thread/spg behavior with automaton and state-machine)

• Error specific (error definition & propagation)thread speedfeatures Tick : in event port { Dequeue_Protocol => AllItems; }; Sp : out data port Base_types::integer;properties Dispatch_Protocol => periodic; Period => 1000 ms;end speed;thread implementation speed.i annex behavior_specification {** states s0: initial complete state; transitions s0 -[ ]-> s0 { sp := tick'count }; **};end speed.i;


Software components

• Process

• Thread and thread group

• Subprogram and subprogram group

• Data


Process components

• Address space for thread execution• As a regular UNIX process

• Contain thread and data subcomponents

• Associated with• Processor

• Memory

process theprocessfeatures dataout : event port;end theprocess;

process implementation theprocess.implsubcomponents T1 : thread the_thread.impl;connections port T1.dataout → dataout;end theprocess.impl;


Thread components

• Execution support for subprogram• Special calls section

• Sporadic or periodic (cf. Dispatch_Protocol)

• Periodic: execution on a cyclic basis

• Sporadic: activation by an event [data] port

thread thethreadproperties Dispatch_Protocol => Periodic;end thethread;

thread implementation thethread.implcalls call1 : {pspg : subprogram periodic_printer.i;};end thethread.impl;


Subprogram components

• Reference to application concerns• Special calls section

• Describe implementation requirements• No ports but parameters for data handling

• Language and implementation

subprogram hello_worldend hello_world;

subprogram implementation hello_world.newbieproperties Source_Language => Ada; Source_Text => (“hello.adb”);end hello_world.newbie;

subprogram implementation hello_world.warlordproperties Source_Language => C; Source_Text => (“hello.c”);end hello_world.warlord;


Data components

• Define data types• Use data modeling annex

• Set of base types for reuse

• Describe data containment and port types• Shared data across threads/subprograms

• Data sent/received through [event] data portsdata implementation mytype.integerproperties Base_Type => integer;end mytype.integer;

thread mythreadfeatures datain : in event data port mytype.integer; shared : requires data access mytype.integer;end mythread;

thread implementation mythread.isubcomponents myvar : data mytype.integer;end mythread.i;


Hardware components

• Processor & virtual processor

• Bus & virtual bus

• Memory

• Device


Processor components

• Architecture & runtime requirements• Cpu endianess, etc...

• Operating system, libraries, etc.

• Execution support• Processes & devices

• Cf. Actual_Processor_Binding property

processor x86end x86;

processor implementation x86.linuxend x86.linux;

processor implementation x86.rtemsend x86.rtems;


Virtual Processor components

• Part of the execution runtime• Describe platform separation

• Ex: partitioned runtime such as ARINC653

• Part of the hardware processor• Ex: Core of multi-core processors

virtual processor coreend core;

virtual processor implementation core.implend core.impl;

processor x86end x86;

processor implementation x86.dualcoresubcomponents core1 : virtual processor core.impl; core2 : virtual processor core.impl;end implementation x86.dualcore;


Bus components

• Modeling of physical buses• Specify hardware boundaries (ex: bandwidth)

• Binding to connections• Describe connection restrictions

bus ethernetend ethernet;

bus serialend serial;

bus implementation ethernet.100Mproperties bandwidth => 100 Mbyte;end ethernet.100M;

bus implementation ethernet.1Gproperties bandwidth => 1000Mbyte;end ethernet.1G;


Virtual Bus components

• Protocols modeling• Association with connections/ports (ex: this connection requires TCP)

• Protocol layering description (ex: TCP is contained within IP)

• Isolation of data traffic• Separate bus resources

• Allocation of bus resources to each connectionsvirtual bus ipend ip;

virtual bus ip.implsubcomponents tcp : virtual bus tcp.impl; udp : virtual bus udp.impl;end ip.impl;

bus implementation ethernet.impl ip_stack : virtual bus ip.impl;end ethernet.impl;


Memory components

• Describe main memory and its decomposition• Size, Word_Count, … as properties

• Ex: memory segments

• Associated to processes

• Actual_Memory_Binding property

memory ramend ram;

memory segmentproperties Word_Count => 2000;end segment;

memory implementation ram.two_segssubcomponents seg1 : memory segment.i {Base_Address => 0; Word_Count => 1000;}; seg2 : memory segment.i {Base_Address => 1000;};end ram.three_segs;


Device components

• All types of devices (network interface, sensor, etc.)

• Potential access to other components usingproperties and components access

• Specification of runtime requirements

• Driver description with the Device_Driver property

• Association with OS using Actual_Processor_Binding

device ethernet_interfacefeatures eth_link : requires bus access ethernet.impl;end ethernet_interface;

device implementation ethernet_interface.ne2000properties Device_Driver => (mydriver);end ethernet_interface.ne2000;


Other components

• System

• Abstract


System components

• Root component• At least one processor/process

• Potential system of systems• Aggregate system definitions

• Modeling of distributed architectures

system mysystem

end mysystem;

system implementation mysystem.simplesubcomponents P1 : process myprocess.impl; cpu : processor intel.dualcore; ram : memory ram.impl;properties Actual_Processor_Binding => (reference (cpu)) applies to p1; Actual_Memory_Binding => (reference (ram)) applies to p1;end mysystem.simple;


Abstract components

• All-purposes modeling• Generic component

• Refine to a particular component type

abstract mycompend mycomp;

abstract implementation mycomp.implend mycomp.impl;


Producer/consumer example

ethernet_bus

RTEMS/PPC

Linux/x86

Process

RAM

RAM

ThreadConsumer

Process

ThreadProducer


One language, two trees

• Syntax tree• Flat vision of components specification

• No real order

• Instance tree• System component as root component

• Components hierarchy


API for AADL models management

• OSATE• Official AADL API

• Java-based API

• Integration within the Eclipse-based modeling framework

• Ocarina library support• Ada-based library (potential use with C)

• Used by the TASTE toolset (buildsupport)


Modeling tools

• OSATE/TOPCASED (SEI/CMU)

• Ocarina (TELECOM ParisTech)

• TOPCASED (Airbus)

• ADELE & STOOD (Ellidiss)

• Dia (Gnome)


Overview




• Code generation



Basic validation: model consistency

• Verify components hierarchy• Legality of model composition

• Validate basic requirements• Process/processor/memory binding

• No application-specific validation

• Various basic validation tools• OSATE

• Ocarina

• STOOD


Requirements Enforcement Analysis Language

• Check system requirements from AADL models• Verification on the instance tree

• Benefit the modeling of hard & soft concerns

• Rely on components properties, subcomponents

• Used as an annex language

• Ensure requirements consistency• Same specification for validation & implementation

• Avoid any translation error

• Rely on set-theory and theorems• Leverage math theory to AADL

• Available in Ocarina


REAL, example

theorem check_memory foreach prs in process_set do

threads := {x in Thread_Set | is_subcomponent_of (x, prs)};

mems := { x in Memory_Set | is_bound_to (Prs, x)};

check ((sum (property (threads, "Source_Stack_Size")) + sum (property (threads, "Source_Data_Size" )) + sum (property (threads, "Source_Code_Size"))) < (sum (property (mems, "word_count"))));end check_memory;

For each process of the AADL model

We take the threads of each process

We take the memory bound to the process

Validation: the memory required by all threads(properties Source_*_Size of thread components)within the process if lower than the size of thememory allocated to the process (propertyWord_Count of memory components)


OSATE based plugins

• Use OSATE API• Browse models and inspect components

• Use OSATE functions to process components requirements

• No specific formalism for requirements specification• Plug-in specific semantics

• Have to program new plug-ins

• Lot of existing validation programs• Check TOPCASED


Scheduling validation

• Cheddar• Scheduling validation program

• AADL → Cheddar models translation within Ocarina

• Check for RMS/EDF/other scheduling algorithms

• MAST• Include distribution-specific modeling

• AADL → MAST models within Ocarina

• TASTE-CV & Marzhin• Scheduling simulation

• Detect potential deadlock & execution errors

• Need to define components behavior


Correctness, Modeling and Performance of Aerospace System (COMPASS)

• System dependability analysis• Detect potential faults of system components

• Ex: potential failure of a sensor/actuator

• Extend the semantics of AADL models• New language derived from AADL: SLIM

• Components behavior specification

• Error description & fault injection

• Rely on the error modeling annex

• http://compass.informatik.rwth-aachen.de


Overview




• Code generation



Code generation & AADL

• Generate architecture implementation• Foundation for application execution

• Resources & communication handling

• Minimal middleware generation

• Not restricted to code skels !• Generate complete architecture code

• Fit with embedded and real-timerequirements

• Open-Source & commercial tools• Ocarina: http://aadl.telecom-paristech.fr

• RT-Edge: http://www.edgewater.ca/


Code generation process

• Similar to traditional compilation process• Translate the AADL-instance tree into Ada/C-syntax tree

• Use AADL components requirements and properties

• Preserve source language semantics as much as possible

CPU

Process

Thread

Code generation

void thread_job { init_thread(); while (1) { application_function(); wait_next_period; }}

int main () init_process(); create_thread (thread_job); go_to_sleep ();}

ARCH=x86BSP=x86-qemu

all: build-application

Conf & deployment code

Application code integration

Runtime support management


Actual state of code generation (Ocarina)

• Support of heterogeneous architectures• OS: Linux, RTEMS, ORK

• CPU: x86, PPC, SPARC

• Protocols management• Ethernet, serial, spacewire

• TCP/IP, ACN, ….

• Driver integration• Network driver

• Embedded-specific driver (ex: arduino)


Code generation benefits

• Reduce overhead• Avoid traditional useless code introduce by code generation

• Generate only required resources

• Ensure requirements enforcement• No bug/error related to hand-written code

• Strict translation of specs. into code

• Predictable code• Functions/behavior deduced from model

• Ensure conformity with validation results


Overview




• Code generation



Conclusion

• Modeling language for hardware & software concerns• Hardware and software trade-offs assessment

• Precise and extensible

• Several syntax for both high-level and fine-grained modelling

• Leveraging AADL to other formalisms• Translation of AADL models into other representation

• Preserve model requirements

• Ease requirements traceability

• Lack of graphical support• No tool for graphical modeling


Perspectives

• Leverage AADL modeling to domain-specific• Model automotive/avionics/aerospace specific aspects

• Design dedicated modeling & validation tools

• Enhance tool support• Provide graphical model manipulation

• Assist developers by providing predefinedcomponent sets

• Better integration of software• Specify system behavior

• Integration of application models


Resources

• Official website: http://www.aadl.info

• AADL cheat sheet: https://wiki.sei.cmu.edu/aadl/index.php/AADL_in_Education

• TOPCASED: http://www.topcased.org

• ASSERT methodology and TASTE tools: http://www.assert-project.net

• AADL portal at ENST:http://aadl.telecom-paristech.fr

http://www.aadl.info/

https://wiki.sei.cmu.edu/aadl/index.php/AADL_in_Education

http://www.topcased.org/

http://www.assert-project.net/

http://aadl.telecom-paristech.fr/

http://www.aadl.info/

https://wiki.sei.cmu.edu/aadl/index.php/AADL_in_Education

http://www.topcased.org/

http://www.assert-project.net/

http://aadl.telecom-paristech.fr/


Resources (2)

• Cheddar: http://beru.univ-brest.fr/~singhoff/cheddar/

• COMPASS: http://compass.informatik.rwth-aachen.de

• Ellidiss (Stood & TASTE-CV): http://www.ellidiss.com

• MAST: http://mast.unican.es/

• Edgewater: http://www.edgewater.ca/

http://beru.univ-brest.fr/~singhoff/cheddar/

http://compass.informatik.rwth-aachen.de/

http://www.ellidiss.com/

http://mast.unican.es/

http://www.edgewater.ca/

http://beru.univ-brest.fr/~singhoff/cheddar/

http://compass.informatik.rwth-aachen.de/

http://www.ellidiss.com/

http://mast.unican.es/

http://www.edgewater.ca/

Julien Delange <julien dot delange at esa dot int>Architecture Analysis & Design LanguageJulien Delange <[email protected]>This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

Julien Delange <julien dot delange at esa dot int>Overview•Introduction to the AADL•Language overview•System validation using AADL•Code generation•Conclusion & perspectives

Julien Delange <julien dot delange at esa dot int>General picture•Capture hardware & software concerns•Binding between application & execution runtime•Safety-critical oriented•Military, avionics, aerospace, …•Description of real-time requirements•Components-based approach•Extensible

Julien Delange <julien dot delange at esa dot int>Bits of AADL history•Inherits from Meta-H modeling language•AADLv1, 2003•AADLv2, 2008•New components•Language extensions, support namespace•Textual (TXT/XML) & graphic format•Ease communication•Better tool support

Julien Delange <julien dot delange at esa dot int>Examples of AADL use•Error modeling & dependability analysis (COMPASS)•Extension of AADL for error specification•Avionics system analysis (AVSI, POK, Ocarina)•Detect errors earlier in avionics software development•System implementation (TASTE)•Automatic integration of app & hard concerns•Scheduling analysis (Cheddar)•Evaluate system requirements

Julien Delange <julien dot delange at esa dot int>Other approaches•UML & MARTE profile•Inheritance of SPT profile•Inaccurate semantics for system modeling•Few available tools for system analysis•No code generation tools•SysML•System-oriented•Loosely coupled with software concerns•Limited toolset

Julien Delange <julien dot delange at esa dot int>One language, three representations•Graphic•Convenient for communication•High-level modeling•Textual•Describe components properties•Fine-grained modeling•Easy to process for programs•XML•Inter-exchange format

Julien Delange <julien dot delange at esa dot int>Types and implementations•Component type•Define basic components characteristics•Declare component interfaces•Component implementation•Contain subcomponents•Connect interfaces with subcomponents•Redefine some requirements•Inheritance & extension•Add more requirements/propertiessystem mysystemfeatures [ports and access decl]end mysystem;system implementation mysystem.isubcomponents [subcomp decl]connections [connect ports and accesses]end mysystem.i;

Julien Delange <julien dot delange at esa dot int>Components interfaces (features)•Ports•Data port: latest written, latest available, no queue•Event port: notification, queued events•Event data port: queued data•Access•Requires or provides access to a component•Ex: I need an access to a data/bussystem mysystemfeatures dataout : data port mytype.impl; eth_access : requires bus access ethernet.1Gb;end mysystem;dataouteth_access

Julien Delange <julien dot delange at esa dot int>Properties•AADL entities requirements•Association with components, ports and access•Strongly typed, not just strings•Declaration using properties section or brackets•Predefined properties and potential extensions•Define your own types and propertiesprocess theprocessfeatures dataout : event port {Queue_Size => 1;};properties Source_Data_Size => 1 Kbyte;end theprocess;process implementation theprocess.implsubcomponents T1 : thread the_thread.impl {Dispatch_Protocol => periodic;};connections port T1.dataout → dataout {Actual_Connection_Binding => …;};end theprocess.impl;

Julien Delange <julien dot delange at esa dot int>Annex languages•Extend AADL semantics•Bind additional language to components•Describe other properties/requirements to AADL models•Several annex language already integrated•Behavior (thread/spg behavior with automaton and state-machine)•Error specific (error definition & propagation)thread speedfeatures Tick : in event port { Dequeue_Protocol => AllItems; }; Sp : out data port Base_types::integer;properties Dispatch_Protocol => periodic; Period => 1000 ms;end speed;thread implementation speed.i annex behavior_specification {** states s0: initial complete state; transitions s0 -[ ]-> s0 { sp := tick'count }; **};end speed.i;

Julien Delange <julien dot delange at esa dot int>Software components•Process•Thread and thread group•Subprogram and subprogram group•Data

Julien Delange <julien dot delange at esa dot int>Process components•Address space for thread execution•As a regular UNIX process•Contain thread and data subcomponents•Associated with•Processor•Memoryprocess theprocessfeatures dataout : event port;end theprocess;process implementation theprocess.implsubcomponents T1 : thread the_thread.impl;connections port T1.dataout → dataout;end theprocess.impl;

Julien Delange <julien dot delange at esa dot int>Thread components•Execution support for subprogram•Special calls section•Sporadic or periodic (cf. Dispatch_Protocol)•Periodic: execution on a cyclic basis•Sporadic: activation by an event [data] portthread thethreadproperties Dispatch_Protocol => Periodic;end thethread;thread implementation thethread.implcalls call1 : {pspg : subprogram periodic_printer.i;};end thethread.impl;

Julien Delange <julien dot delange at esa dot int>Subprogram components•Reference to application concerns•Special calls section•Describe implementation requirements•No ports but parameters for data handling•Language and implementationsubprogram hello_worldend hello_world;subprogram implementation hello_world.newbieproperties Source_Language => Ada; Source_Text => (“hello.adb”);end hello_world.newbie;subprogram implementation hello_world.warlordproperties Source_Language => C; Source_Text => (“hello.c”);end hello_world.warlord;

Julien Delange <julien dot delange at esa dot int>Data components•Define data types•Use data modeling annex•Set of base types for reuse•Describe data containment and port types•Shared data across threads/subprograms•Data sent/received through [event] data portsdata implementation mytype.integerproperties Base_Type => integer;end mytype.integer;thread mythreadfeatures datain : in event data port mytype.integer; shared : requires data access mytype.integer;end mythread;thread implementation mythread.isubcomponents myvar : data mytype.integer;end mythread.i;

Julien Delange <julien dot delange at esa dot int>Hardware components•Processor & virtual processor•Bus & virtual bus•Memory•Device

Julien Delange <julien dot delange at esa dot int>Processor components•Architecture & runtime requirements•Cpu endianess, etc...•Operating system, libraries, etc.•Execution support•Processes & devices•Cf. Actual_Processor_Binding propertyprocessor x86end x86;processor implementation x86.linuxend x86.linux;processor implementation x86.rtemsend x86.rtems;

Julien Delange <julien dot delange at esa dot int>Virtual Processor components•Part of the execution runtime•Describe platform separation•Ex: partitioned runtime such as ARINC653•Part of the hardware processor•Ex: Core of multi-core processorsvirtual processor coreend core;virtual processor implementation core.implend core.impl;processor x86end x86;processor implementation x86.dualcoresubcomponents core1 : virtual processor core.impl; core2 : virtual processor core.impl;end implementation x86.dualcore;

Julien Delange <julien dot delange at esa dot int>Bus components•Modeling of physical buses•Specify hardware boundaries (ex: bandwidth)•Binding to connections•Describe connection restrictionsbus ethernetend ethernet;bus serialend serial;bus implementation ethernet.100Mproperties bandwidth => 100 Mbyte;end ethernet.100M;bus implementation ethernet.1Gproperties bandwidth => 1000Mbyte;end ethernet.1G;

Julien Delange <julien dot delange at esa dot int>Virtual Bus components•Protocols modeling•Association with connections/ports (ex: this connection requires TCP)•Protocol layering description (ex: TCP is contained within IP)•Isolation of data traffic•Separate bus resources•Allocation of bus resources to each connectionsvirtual bus ipend ip;virtual bus ip.implsubcomponents tcp : virtual bus tcp.impl; udp : virtual bus udp.impl;end ip.impl;bus implementation ethernet.impl ip_stack : virtual bus ip.impl;end ethernet.impl;

Julien Delange <julien dot delange at esa dot int>Memory components•Describe main memory and its decomposition•Size, Word_Count, … as properties•Ex: memory segments•Associated to processes•Actual_Memory_Binding propertymemory ramend ram;memory segmentproperties Word_Count => 2000;end segment;memory implementation ram.two_segssubcomponents seg1 : memory segment.i {Base_Address => 0; Word_Count => 1000;}; seg2 : memory segment.i {Base_Address => 1000;};end ram.three_segs;

Julien Delange <julien dot delange at esa dot int>Device components•All types of devices (network interface, sensor, etc.)•Potential access to other components usingproperties and components access•Specification of runtime requirements•Driver description with the Device_Driver property•Association with OS using Actual_Processor_Bindingdevice ethernet_interfacefeatures eth_link : requires bus access ethernet.impl;end ethernet_interface;device implementation ethernet_interface.ne2000properties Device_Driver => (mydriver);end ethernet_interface.ne2000;

Julien Delange <julien dot delange at esa dot int>Other components•System•Abstract

Julien Delange <julien dot delange at esa dot int>System components•Root component•At least one processor/process•Potential system of systems•Aggregate system definitions•Modeling of distributed architecturessystem mysystemend mysystem;system implementation mysystem.simplesubcomponents P1 : process myprocess.impl; cpu : processor intel.dualcore; ram : memory ram.impl;properties Actual_Processor_Binding => (reference (cpu)) applies to p1; Actual_Memory_Binding => (reference (ram)) applies to p1;end mysystem.simple;

Julien Delange <julien dot delange at esa dot int>Abstract components•All-purposes modeling•Generic component•Refine to a particular component typeabstract mycompend mycomp;abstract implementation mycomp.implend mycomp.impl;

Julien Delange <julien dot delange at esa dot int>Producer/consumer exampleethernet_busRTEMS/PPCLinux/x86ProcessRAMRAMThreadConsumerProcessThreadProducer

Julien Delange <julien dot delange at esa dot int>One language, two trees•Syntax tree•Flat vision of components specification•No real order •Instance tree•System component as root component•Components hierarchy

Julien Delange <julien dot delange at esa dot int>API for AADL models management•OSATE•Official AADL API•Java-based API•Integration within the Eclipse-based modeling framework•Ocarina library support•Ada-based library (potential use with C)•Used by the TASTE toolset (buildsupport)

Julien Delange <julien dot delange at esa dot int>Modeling tools•OSATE/TOPCASED (SEI/CMU)•Ocarina (TELECOM ParisTech)•TOPCASED (Airbus)•ADELE & STOOD (Ellidiss)•Dia (Gnome)

Julien Delange <julien dot delange at esa dot int>Basic validation: model consistency•Verify components hierarchy•Legality of model composition•Validate basic requirements•Process/processor/memory binding•No application-specific validation•Various basic validation tools•OSATE•Ocarina•STOOD

Julien Delange <julien dot delange at esa dot int>Requirements Enforcement Analysis Language•Check system requirements from AADL models•Verification on the instance tree•Benefit the modeling of hard & soft concerns•Rely on components properties, subcomponents•Used as an annex language•Ensure requirements consistency•Same specification for validation & implementation•Avoid any translation error•Rely on set-theory and theorems•Leverage math theory to AADL•Available in Ocarina

Julien Delange <julien dot delange at esa dot int>REAL, exampletheorem check_memory foreach prs in process_set do threads := {x in Thread_Set | is_subcomponent_of (x, prs)}; mems := { x in Memory_Set | is_bound_to (Prs, x)}; check ((sum (property (threads, "Source_Stack_Size")) + sum (property (threads, "Source_Data_Size" )) + sum (property (threads, "Source_Code_Size"))) < (sum (property (mems, "word_count"))));end check_memory;For each process of the AADL modelWe take the threads of each processWe take the memory bound to the processValidation: the memory required by all threads(properties Source_*_Size of thread components)within the process if lower than the size of thememory allocated to the process (propertyWord_Count of memory components)

Julien Delange <julien dot delange at esa dot int>OSATE based plugins•Use OSATE API•Browse models and inspect components•Use OSATE functions to process components requirements•No specific formalism for requirements specification•Plug-in specific semantics•Have to program new plug-ins•Lot of existing validation programs•Check TOPCASED

Julien Delange <julien dot delange at esa dot int>Scheduling validation•Cheddar•Scheduling validation program•AADL → Cheddar models translation within Ocarina•Check for RMS/EDF/other scheduling algorithms•MAST•Include distribution-specific modeling•AADL → MAST models within Ocarina•TASTE-CV & Marzhin•Scheduling simulation•Detect potential deadlock & execution errors•Need to define components behavior

Julien Delange <julien dot delange at esa dot int>Correctness, Modeling and Performance of Aerospace System (COMPASS)•System dependability analysis•Detect potential faults of system components•Ex: potential failure of a sensor/actuator•Extend the semantics of AADL models•New language derived from AADL: SLIM•Components behavior specification•Error description & fault injection•Rely on the error modeling annex•http://compass.informatik.rwth-aachen.de

Julien Delange <julien dot delange at esa dot int>Code generation & AADL•Generate architecture implementation•Foundation for application execution•Resources & communication handling•Minimal middleware generation•Not restricted to code skels !•Generate complete architecture code•Fit with embedded and real-timerequirements•Open-Source & commercial tools•Ocarina: http://aadl.telecom-paristech.fr•RT-Edge: http://www.edgewater.ca/

Julien Delange <julien dot delange at esa dot int>Code generation process•Similar to traditional compilation process•Translate the AADL-instance tree into Ada/C-syntax tree•Use AADL components requirements and properties•Preserve source language semantics as much as possibleCPUProcessThreadCode generationvoid thread_job { init_thread(); while (1) { application_function(); wait_next_period; }}int main () init_process(); create_thread (thread_job); go_to_sleep ();}ARCH=x86BSP=x86-qemuall: build-applicationConf & deployment codeApplication code integrationRuntime support management

Julien Delange <julien dot delange at esa dot int>Actual state of code generation (Ocarina)•Support of heterogeneous architectures•OS: Linux, RTEMS, ORK•CPU: x86, PPC, SPARC•Protocols management•Ethernet, serial, spacewire•TCP/IP, ACN, ….•Driver integration•Network driver•Embedded-specific driver (ex: arduino)

Julien Delange <julien dot delange at esa dot int>Code generation benefits•Reduce overhead•Avoid traditional useless code introduce by code generation•Generate only required resources•Ensure requirements enforcement•No bug/error related to hand-written code•Strict translation of specs. into code•Predictable code•Functions/behavior deduced from model•Ensure conformity with validation results

Julien Delange <julien dot delange at esa dot int>Conclusion•Modeling language for hardware & software concerns•Hardware and software trade-offs assessment•Precise and extensible•Several syntax for both high-level and fine-grained modelling•Leveraging AADL to other formalisms•Translation of AADL models into other representation•Preserve model requirements•Ease requirements traceability•Lack of graphical support•No tool for graphical modeling

Julien Delange <julien dot delange at esa dot int>Perspectives•Leverage AADL modeling to domain-specific•Model automotive/avionics/aerospace specific aspects•Design dedicated modeling & validation tools•Enhance tool support•Provide graphical model manipulation•Assist developers by providing predefinedcomponent sets•Better integration of software•Specify system behavior•Integration of application models

Julien Delange <julien dot delange at esa dot int>Resources•Official website: http://www.aadl.info•AADL cheat sheet: https://wiki.sei.cmu.edu/aadl/index.php/AADL_in_Education•TOPCASED: http://www.topcased.org•ASSERT methodology and TASTE tools: http://www.assert-project.net•AADL portal at ENST:http://aadl.telecom-paristech.fr

Julien Delange <julien dot delange at esa dot int>Resources (2)•Cheddar: http://beru.univ-brest.fr/~singhoff/cheddar/•COMPASS: http://compass.informatik.rwth-aachen.de•Ellidiss (Stood & TASTE-CV): http://www.ellidiss.com•MAST: http://mast.unican.es/•Edgewater: http://www.edgewater.ca/

architecture analysis & design languagearchitecture analysis & design language julien...

Documents