Ivano Malavolta

AADL

VRIJEUNIVERSITEITAMSTERDAM

Outline of this lecture

• Part 1: Basics on AADLv2 core

– Syntax, semantics of the language

• Part 2: Example

– The radar illustrative example

Basics on AADL

Outline

1. AADL key modeling constructs1. Software components

2. Execution platform components3. Properties4. Modelling large scale systems

2. Tool support

AADL for analysis

Different representations of an AADL model

Summary of AADL elements

Three levels of description

• Category (predefined)

• Type– specification of the external interface

• Implementation– specification of the content

• Instance– instantiation of a type

or an implementation

– you do not model it, it is created by the tool

Software components categories

• Process : address space. It must hold at least one thread

• Thread : schedulable execution flow, Ada or VxWorks task, Java or POSIX thread. Executes programs

• Data : data placeholder, e.g. C struct, C++ class, Ada record

• Subprogram : a sequential execution flow. Associated to a source code (C, Java) or a model (Simulink)

• Thread group : hierarchy of threads

Software components

Example: process composed of two threads

thread receiverend receiver;

thread implementation receiver.implend receiver.impl;

thread analyserend analyser;

thread implementation analyser.implend analyser.impl;

process processingend processing;

process implementation processing.otherssubcomponents

receive : thread receiver.impl;analyse : thread analyser.impl;. . .

end processing.others;

Software components

a thread may call different subprograms

thread receiverend receiver;

thread implementation receiver.implcalls CS : {

call1 : subprogram Receiver_Spg;call2 : subprogram ComputeCRC_Spg;

};end receiver.impl;

subprogram Receiver_Spgend Receiver_Spg;

subprogram ComputeCRC_Spgend ComputeCRC_Spg;

. . .

Subprogram

A subprogram component represents an execution entry point in source text

No component can contain subprogram subcomponents.

A subprogram call in the implementation of a thread or another subprogram may be “seen as” the inclusion of a subprogram subcomponent

A thread can have call sequences for its states:– initialization, finalization, activation, deactivation, computation, and recovery

Each thread dispatch executes the computation call sequence once

States of a thread

Subprogram local call example

Subprogram remote call example

Data

It represents static data (e.g., numerical data or source text) and data types within a system

– (e.g., used as data types on ports and parameters)

Components may have a shared access to a data component

Good practice: to store data definitions in a separate file

Example of data

Component connection

Ports compatibility

Port groups

Modes

A mode represents an operational state of a system

A mode of a component can influence: – property values– activation of specific subcomponents

– existence of connections

Example - Modes of a cruise controller:{initialize, disengaged, engaged}

Modes transitions

Mode transitions represent configuration changes as reaction to events

– Triggered through ports (from outside or from a subcomponent)– Triggered internally by implementation software

– Triggered internally in an execution platform component or a device

• Note: Modes are not intended for modeling detailed internal behavior of threads or subprograms (� AADL Behavior Annex)

Mode example

Internal modetransitionexample

Outline

1. AADL key modeling constructs1. Software components 2. Execution platform components

3. Properties4. Modelling large scale systems

2. Tool support

Hardware components categories

• Processor/virtual processor– schedule component (combined CPU and RTOS scheduler). A

processor may contain multiple virtual processors

• memory– model data storage (memory, hard drive)

• device– component that interacts with the environment.

• internals (e.g. firmware) is not modeled.

• bus/virtual bus– data exchange mechanism between hardware components

Device Memory bus Processor

Software/platform binding

Maps application software elements to execution platform elements using binding properties

Software/platform binding

• Actual_Processor_Binding– Specify which processor schedules and executes a thread or

executes a (kernel mode) device driver

• Actual_Memory_Binding– Specify the memory components in which executable code

(process components) and data (data component) reside

• Actual_Connection_Binding– Specify the communication channels that are used by logical

connections (see next section)

Bus access

Access to buses is declared explicitly in AADL

Outline

1. AADL key modeling constructs1. Software components

2. Execution platform components3. Properties

4. Modelling large scale systems

2. Tool support

Property sets

Property sets :– Group property definitions– They can be either

• part of the standard, e.g. Thread_Properties• or user-defined, e.g. for a new analysis

Example :

property set Thread_Properties is. . .Priority : aadlinteger applies to (thread, device, …); Source_Text : inherit list of aadlstring applies to (data, port, thread, …);. . .

end Thread_Properties;

AADL predefined property sets

AADL properties

Property: – Typed attribute, associated to one or more components

– Property = name + type + allowed components– Property association = property name + value

Allowed types in properties:– aadlboolean, aadlinteger, aadlreal, aadlstring, enumeration, many others …

Can be propagated to subcomponents: inherit

Can override parent’s one, case of extends

Property types

AADL properties

Properties are associated to a component type (1) or implementation (2), as part of a subcomponent instance (3), or a contained property association (4).

process implementation processing.otherssubcomponentsreceive0 : thread receiver.impl;receive1 : thread receiver.impl;receive2 : thread receiver.impl

{Deadline => 200 ms;}; -- (3)properties -- (4)

Deadline => 300 ms applies to receive1;end processing.others;

thread receiverproperties -- (1)Compute_Execution_Time => 3ms .. 4ms;Deadline => 150 ms ;

end receiver;

thread implementation receiver.implproperties -- (2)

Deadline => 160 ms;Compute_Execution_Time => 4ms .. 10ms;

end receiver.impl;

Measurement units

Properties are typed with units to model physical systems, related to embedded real-time critical systems

property set AADL_Projects isTime_Units: type units (

ps, ns => ps * 1000, us => ns * 1000, ms => us * 1000,sec => ms * 1000, min => sec * 60, hr => min * 60);

-- …end AADL_Projects;

property set Timing_Properties is

Time: type aadlinteger0ps .. Max_Time units Time_Units;

Time_Range: type range of Time;

Compute_Execution_Time: Time_Rangeapplies to (thread, device, subprogram,

event port, event data port);

end Timing_Properties;

Outline

1. AADL key modeling constructs1. Software components

2. Execution platform components3. Properties4. Modelling large scale systems

2. Tool support

AADL packages

A package provides a means to organize the descriptions by the use of namespaces

A package can contain: – component types

– component implementations– port group types– annex libraries

AADL package example

AADL systems

Help structuring an architecture, with its own hierarchy of subcomponents.

A system can include one or several subsystems

In an AADL specification there is always a root system component

System

subprogram Receiver_Spg …thread receiver …

thread implementation receiver.impl … call1 : subprobram Receiver_Spg; …end receiver.impl;

process processingend processing;

process implementation processing.otherssubcomponentsreceive : thread receiver.impl;analyse : thread analyser.impl;. . .

end processing.others;

AADL systems

system radarend radar;

system implementation radar.simplesubcomponents

main : process processing.others;cpu : processor leon2;

propertiesActual_Processor_Binding =>

reference cpu applies to main;end radar.simple;

device antenna end antenna;

processor leon2end leon2;

A full AADL system : a tree of component instances

• Component types and implementations only define a library of entities (classifiers)

• An AADL model is a set of component instances (of the classifiers)

• System must be instantiated through a hierarchy of subcomponents, from root (system) to the leafs (subprograms, ..)

• We must choose a system implementation component as the root system model !

Root System

Sub System

Process Processor

Thread Data

Subprogram

About subcomponents

Some restrictions apply on subcomponents– A hardware cannot contain software, etc

data data, subprogram

thread data, subprogram

thread group

data, thread, thread group, subprogram

process thread, thread group, data

processor Memory, virtual processor, bus

memory Memory, bus

system ALL except subprogram, thread, and thread group

60

System instances

Component types and implementations are “only” blueprints

A system instance represents the runtime architecture of an operational physical system

Composed of software components + execution platform

XML for storing system instances

System instances 2

System instances are automatically generated by OSATE starting from complete system implementations

Components extension & refinement

Extension: to define a new extended classifier based on an existing classifier

Allows incremental refinement of a model• Component extension

– Component types – Component implementations

Extension example

Subcomponents array

Feature arrays

Connecting arrays

Connection patterns

Outline

1. AADL key modeling constructs1. AADL components

2. Properties3. Component connection

2. AADL: tool support

AADL & Tools

• OSATE (SEI/CMU, http://osate.org)

– Eclipse-based tool. Reference implementation. AADL v1 and v2

– Textual + graphical editors + various plug-ins

• STOOD, ADELE (Ellidiss, http://www.ellidiss.com )– Graphical editors for AADLv1 and v2, code/documentation generation

• Cheddar (UBO/Lab-STICC, http://beru.univ-brest.fr/~singhoff/cheddar/ )– Performance analysis, AADLv1 only

• AADLInspector (Ellidiss, http://www.ellidiss.com)– Lightweight tool to inspect AADL models. AADLv1 and v2– Industrial version of Cheddar + Simulation Engine

• Ocarina (ISAE, http://www.openaadl.org)– Command line tool, library to manipulate models. AADLV1 and V2– AADL parser + code generation + analysis (Petri Net, WCET, …)

• Others: RAMSES, PolyChrony, ASSIST, MASIW, MDCF, TASTE, …

Example

Example

Goal: to model a simple radar system

Let us suppose we have the following requirements:

1. System implementation is composed of physical devices (Hardware entity): antenna + processor + memory + bus

2. and software entities : running processes and threads + operating system functionalities (scheduling) implemented in the processor that represents a part of execution platform and physical devices in the same time

3. The main process is responsible for signals processing : general pattern: transmitter -> antenna -> receiver -> analyzer -> display

4. Analyzer is a periodic thread that compares transmitted and received signals to perform detection, localization and identification

Radar case study

Hardware/Software breakdown: components

PACKAGE radarPUBLIC

PROCESS processing-- …END processing;DEVICE antenna-- …END antenna;

END RADAR;

Radar case study

Hardware/Software breakdown: features

in/out ports

bus access

PROCESS processingFEATURESto_screen : OUT EVENT PORT;send_pulse : OUT EVENT PORT;receive_pulse : IN DATA PORT;get_angle : IN DATA PORT;

END processing;

DEVICE antennaFEATURESantenna_in : IN EVENT PORT;VME : REQUIRES BUS ACCESS VME;

END antenna;

Radar case study

Hardware/Software breakdown: connections

Logical cnx

Hardware cnx

Radar case study

Hardware/Software breakdown: connections

SYSTEM IMPLEMENTATION radar.simpleSUBCOMPONENTSaerial : DEVICE antenna;rotor : DEVICE motor;monitor : DEVICE screen;main : PROCESS processing.others;cpu : PROCESSOR leon2;VME : BUS VME;RAM : MEMORY RAM;

CONNECTIONSPORT aerial.antenna_out -> main.receive_pulse;PORT rotor.motor_out -> main.get_angle;PORT main.send_pulse -> aerial.antenna_in;PORT main.to_screen -> monitor.screen_in;BUS ACCESS VME -> aerial.VME;BUS ACCESS VME -> rotor.VME;BUS ACCESS VME -> monitor.VME;BUS ACCESS VME -> cpu.VME;BUS ACCESS VME -> RAM.VME;

Radar case study

• Hardware/Software breakdown: bindings

Bindings

PROPERTIESActual_Memory_Binding => reference (ram) applies to main;Actual_Processor_Binding => reference (cpu) applies to main;

END radar.simple;

Radar case study

• Software elements

Radar case study

• Software elements

PROCESS IMPLEMENTATION processing.othersSUBCOMPONENTSreceive : THREAD receiver.impl;analyse : THREAD analyser.impl; display : THREAD display_panel.impl; transmit : THREAD transmitter.impl; control_angle : THREAD controller.impl;

CONNECTIONS A10:PORT receive_pulse -> receive.receiver_in; A11:PORT display.display_out -> to_screen; A12:PORT transmit.transmitter_out -> send_pulse; A13:PORT get_angle -> control_angle.controller_in; A14:PORT receive.receiver_out -> analyse.from_receiver; A15:PORT analyse.analyser_out -> display.display_in; A16:PORT transmit.transmitter_out -> analyse.from_transmitter; A17:PORT control_angle.controller_out -> analyse.from_controller;

END processing.others;

Radar case study

• Software elements

PROCESS IMPLEMENTATION processing.othersSUBCOMPONENTSreceive : THREAD receiver.impl;analyse : THREAD analyser.impl; display : THREAD display_panel.impl; transmit : THREAD transmitter.impl; control_angle : THREAD controller.impl;

CONNECTIONS A10:PORT receive_pulse -> receive.receiver_in; A11:PORT display.display_out -> to_screen; A12:PORT transmit.transmitter_out -> send_pulse; A13:PORT get_angle -> control_angle.controller_in; A14:PORT receive.receiver_out -> analyse.from_receiver; A15:PORT analyse.analyser_out -> display.display_in; A16:PORT transmit.transmitter_out -> analyse.from_transmitter; A17:PORT control_angle.controller_out -> analyse.from_controller;

END processing.others;

THREAD IMPLEMENTATION receiver.implCALLS CS : { RS : SUBPROGRAM Receiver_Spg;

};CONNECTIONS A18:PARAMETER RS.receiver_out -> receiver_out; A19:PARAMETER receiver_in -> RS.receiver_in;

PROPERTIES Priority => 63; Dispatch_Protocol => Periodic; Compute_Execution_Time => 10 ms .. 20 ms; Deadline => 150 ms; Period => 1500 ms;

END receiver.impl;

What this lecture means to you?

AADL = Architecture Analysis & Design Language

AADL is for architectural description, period.à Not to be compared with UML suites

– Behavior, types, link with source code is not required

Keep in mind models support an objective

What is not covered by this lecture: flows, annexes, multidimensional arrays, virtual processors/buses, analyses with external tools

Suggested readings

1. The SAE Architecture Analysis & Design Language (AADL) Standard.Peter H. Feiler, January 2008. [Introduction to the language]

2. The Architecture Analysis & Design Language (AADL): AnIntroduction, Peter H. Feiler David P. Gluch John J. Hudak, February2006. [Use this as reference manual]

3. OSATE plugin: SEI validation plugins. SEI. [AADL analysis in general]

4. Developing AADL Models for Control Systems: A Practitioner’sGuide. John Hudak Peter Feiler. July 2007. [Flow latency analysis]

5. http://www.informit.com/articles/article.aspx?p=1959953[Simple running example]

Links

Tool:

• http://osate.org– examples have been tested on OSATE v2.2.1

Example projects (other than the ones on Schoology):1. https://github.com/yoogx/AADLib2. https://github.com/osate/examples3. http://www.santoslab.org/pub/high-assurance/module-

aadl/slides/AADL-Isolette.pdf

Acknowledgements

Parts of this lecture have been elaborated from:

• AADLv2, a Domain Specific Language for the Modeling, the Analysisand the Generation of Real-Time Embedded Systems. Frank Singhoffand Jerome Hugues, MODELS 2014 tutorial.

• SAE AADL V2: An Overview. Peter Feiler. © 2010 Carnegie MellonUniversity.

• Overview of AADL Syntax. J-P. Rosen, J-F. Tilman. AADL Workshop2005.

ContactIvano Malavolta |

Assistant professorVrije Universiteit Amsterdam

iivanoo

i.malavolta@vu.nl

www.ivanomalavolta.com