AADLv2 - An Introduction

AADLv2: an Architecture Description
Language for the Analysis and

Generation of Embedded Systems
Jérôme Hugues*, Frank Singhoff+

*ISAE, France
+University of Brest, Lab-STICC/CNRS UMR 6285, France
Introduction
Goal: to model a simple radar system
Let us suppose we have the following
requirements
1. System implementation is composed by physical devices (Hardware entity):
antenna + processor + memory + bus
2. and software entity : running processes and threads + operating system
functionalities (scheduling) implemented in the processor that represent 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.
5. [..]
page 2
Introduction
Issues
How to model a system that conforms to requirements
How to validate the solution ?
How to prototype it ?
How to go further, down to the implementation ?
Solution, one among others
Use an architecture description language:
to model the system
to run various verification
and actually, to automatically produce the system
page 3
Outline
Goal: introduce model-based analysis of embedded systems using
the AADLv2 Architecture Description Language
Part 1: Introduction to AADLv2 core (about 60’)
Syntax, semantics of the language
Part 2: introducing a case study (about 30’)
A radar illustrative case study
Part 3: Scheduling analysis (about 60’)
Introducing real-time scheduling theory and its use with
AADL
Part 4 : code generation (about 60’)
How to generate code from an AADL model and how to run it
page 4
Presentation of the AADL:
Architecture Analysis and
Design Language
Outline
1. AADL a quick overview

2. AADL key modeling constructs
1. AADL components
2. Properties
3. Component connection
3. AADL: tool support
page 2
Introduction
ADL, Architecture Description Language:
Goal : modeling software and hardware architectures
to master complexity … to perform analysis
Concepts : components, connections, configuration.
Many ADLs : formal/non formal, application domain,
…
ADL for real-time systems: AADL (Architecture

Analysis and Design Language).
page 3
AADL: Architecture Analysis & Design Language
International standard promoted by the SAE (Society of
Automotive Engineers), AS-2C committee, released as AS-
5506A.
Version 1.0 published in 2004, version 2 in 2009
http://aadl.info list all resources around AADL
Public wiki with lot of resources:
https://wiki.sei.cmu.edu/aadl/index.php/Main_Page
Include link to most research activities around AADL
Different representations :
Graphical (high-level view of the system),
Textual (to view all details),
XML (to ease processing by 3rd party tool)
page 4
A is for Analysis
AADL objectives are “to model a system”
With analysis in mind (different analysis)
To ease transition from well-defined
requirements to the final system : code
production
Require semantics => any AADL entity has a

semantics (natural language or formal methods).
page 5
AADL components
AADL model : hierarchy/tree of components
AADL component:
Model a software or a hardware entity
Has a type/interface, one or several implementations
May be organized in packages (reusable)
May have subcomponents
May combine/extend/refine others
May have properties : valued attributes (source code file name,
priority, WCET, memory consumption, …)
Component interactions :
Modeled by component connections
AADL features are connection points
page 6
AADL components
How to declare a component:
Component type: name, category, properties, features.
Component implementation: internal structure (subcomponents),
properties
Component categories: model real-time abstractions,

close to the implementation space (ex : processor, task,
…). Each category has a well-defined semantics/behavior,
refined through the property mechanism
Hardware components: execution platform
Software components
Systems : bounding box of a system. Model a deployment.
page 7
Component type
AADLv2 distinguished type and implementation
Component type = high-level specification of a
component
All component type declarations follow the same
pattern: <category> foo [extends <bar>]
Inherit features and
properties from parent
features
-- list of features
Interface of the component:
-- interface (event) ports, access to data
or subprograms
properties
-- list of properties
Some properties describing
-- e.g. prioritynon-functional aspect of the
component
end foo;
page 8
Component type
Example:
subprogram Spg -- Spg is modelling a
C function, stored
features -- in file "foo.c",
that takes one
in_param : in parameter foo_data; -- parameter
Standard properties, one canas input
properties define its own properties
Source_Language => C;
Source_Text => ("foo.c");
end Spg;
thread bar_thread -- bar_thread is a

sporadic thread,
features -- it is dispatched
Note: standard defines validity of
whenever it
combination of properties. To be complete,
in_data : in event data port foo_data; -- receives an event
a sporadic thread must define a minimal
on its"in_data"
Inter-arrival time
properties -- port
Dispatch_Protocol => Sporadic;
end bar_thread;
page 9
Component implementation
AADLv2 distinguishes type from implementation
Component Implementation complete the interface
Similar to spec/body of Ada, interface/implementation in
Java
<category> implementation foo.i [extends <bar>.i
subcomponents
-- … foo.i implements foo
calls
-- subprogram subcomponents
-- called, only for threads or subprograms
connections
properties
-- list of properties
page 10
-- e.g. priority
end foo.i;
Component implementation
Example:
thread bar_thread -- bar_thread is a spor

features -- it is dispatched whe
in_data : in event data port foo_data; -- receives an event on
properties -- port
Dispatch_Protocol => Sporadic;
end bar_thread;
Connect data flow
thread implementation bar_thread.impl -- in this implementati
calls -- dispatch we execute
C : { S : subprogram spg; }; -- sequence. We pass th
connections -- parameter to the cal
parameter in_data -> S.in_param;
end bar_thread.impl;
page 11
AADL concepts
AADL introduces many other concepts:
Related to embedded real-time distributed systems :
AADL flows: capture high-level data+execution flows
AADL modes: models an operational mode in the form of an alternative set
of active components/connections/…
To ease models design/management:
AADL packages (similar to Ada, renames, private/public)
AADL abstract component, component extension
…
AADL is a rich language :

100 entities in the meta-model
BNF has 185 syntax rules
Around 250 legality rules and more than 500 semantics rules
400 pages core document + various annex documents
page 12
Outline

1. AADL components
2. Properties
page 13
A full AADL system : a tree of component
instances
Component types and
implementations only define a
library of entities (classifiers) Root System
An AADL model is a set of
component instances (of the Sub System Process Processor
classifiers)
System must be instantiated
through a hierarchy of Thread Data
subcomponents, from root
(system) to the leafs Subprogram
(subprograms, ..)
We must choose a system
implementation component as
the root system model !
page 14
Software components categories
thread : schedulable execution flow, Ada or VxWorks task,
Java or POSIX thread. Execute programs
data : data placeholder, e.g. C struct, C++ class, Ada record
process : address space. It must hold at least one thread
subprogram : a sequential execution flow. Associated to a
source code (C, Ada) or a model (SCADE, Simulink)
thread group : hierarchy of threads
Thread data Threadgroup process

subprogram
page 15
Software components
Example of a process component : composed
of two threads
thread receiver process processing

end receiver; end processing;
thread implementation receiver.impl process implementation processing.others

end receiver.impl; subcomponents
receive : thread receiver.impl;
thread analyser analyse : thread analyser.impl;
end analyser; ...
end processing.others;
thread implementation analyser.impl
end analyser.impl;
page 16
Software components
Example of a thread component : a thread
may call different subprograms
subprogram Receiver_Spg thread receiver

end Receiver_Spg; end receiver;
subprogram ComputeCRC_Spg thread implementation receiver.impl

end Compute_CRCSpg; CS : calls {
call1 : subprogram Receiver_Spg;
... call2 : subprogram ComputeCRC_Spg;
};
end receiver.impl;
page 17
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
components
bus Processor
Device Memory
page 18
« system » category
system :
1. Help structuring an architecture, with its own
hierarchy of subcomponents. A system can include
one or several subsystems.
2. Root system component.
3. Model the deployment of components inside the
component hierarchy. Concept of binding.
System
page 19
« system » category
subprogram Receiver_Spg … device antenna
thread receiver … end antenna;
thread implementation receiver.impl processor leon2

… call1 : subprobram Receiver_Spg; … end leon2;
end receiver.impl;
process processing system radar

end processing; end radar;
process implementation processing.others system implementation radar.simple

subcomponents subcomponents
receive : thread receiver.impl; main : process processing.others;
analyse : thread analyser.impl; cpu : processor leon2;
... properties
end processing.others; Actual_Processor_Binding =>
reference cpu applies to main;
page 20
end radar.simple;
About subcomponents
Semantics: 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, virtual processor
memory Memory, bus

system All except subprogram, thread et thread group
page 21
Outline

1. AADL components
2. Properties
page 22
AADL properties
Property:
Typed attribute, associated to one or more components
Property = name + type + associated components
Property association = property name + value.
Allowed types in properties:

aadlboolean, aadlinteger, aadlreal, aadlstring,
enumeration, classifier (component, connection, etc.),
reference (component…), list of …
Can be propagated to subcomponents: inherit

Can override parent’s one, case of extends
page 23
AADL properties
Property sets :
Group property definitions.
Property sets part of the standard, e.g. AADL_Project.
Or user-defined, e.g. for new analysis: power, weight
Example :
property set Thread_Properties is
...
Deadline : aadlinteger applies to (thread, device, …);
Source_Text : inherit list of aadlstring applies to (data, port, thread, …);
...
end Thread_Properties;
page 24
AADL properties
Properties are typed with units to model physical
systems
property set AADL_Projects isproperty set Timing_Properties is

Time_Units: type units (
ps, Time: type aadlinteger
ns => ps * 1000, 0 ps .. Max_Time units Time_Units;
us => ns * 1000,
ms => us * 1000, Time_Range: type range of Time;
sec => ms * 1000,
min => sec * 60, Compute_Execution_Time: Time_Range
hr => min * 60); applies to thread, device, subprogram,
-- … event port, event data port);
end AADL_Projects;
end Timing_Properties;
page 25
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).
thread receiver
properties -- (1)
Compute_Execution_Time => 3 .. 4 ms; process implementation processing.others
subcomponents
Period => 150 ms; receive1 : thread receiver.impl;
end receiver; receive2 : thread receiver.impl
{Deadline => 200 ms;}; -- (3)
thread implementation receiver.impl
properties – (2) properties – (4)
Deadline => 150 ms; Deadline => 300 ms applies to receive1;
Period => 160 ms, end processing.others;
end receiver.impl;
page 26
Outline

1. AADL components
2. Properties
page 27
Component connection
Component connection: model component interactions, control
flow and/or data flow. E.g. exchange of message, remote call (RPC),
features : component point part of the interface. Each feature has a

name, a direction, and a category
Features category: specification of the type of interaction

• event port : event exchange (e.g. alarm, interruption)
• data port/event data port : synchronous/asynchronous exchange of
data/message
• subprogram parameter
• data access : access to a data, possibly shared
• subprogram access : RPC or rendez-vous
Features direction for port and parameter:

• input (in), output (out), both (in out).
page 28
Features of subcomponents are connected in
the “connections” subclause of the enclosing
component
Ex: threads & thread connection on data port
thread analyser
features process implementation processing.others
analyser_out : out data port subcomponents
Target_Position.Impl; display : thread display_panel.impl;
end analyser; analyse : thread analyser.impl;
connections
thread display_panel port analyse.analyser_out -> display.display_in;
features end processing.others;
display_in : in data port Target_Position.Impl;
end display_panel;
page 29
Data connection policies
Multiple policies exist to control production
and consumption of data by threads:
1. Sampling connection: takes the latest value

Problem: stability of control/command algorithm
page 30
Data connection policies
2. Immediate: receiver thread is immediately
awaken, and will read data when emitter finished
3. Delayed: actual transmission is delayed to the
next time frame
1. These two policies allow for deterministic
communication, hence stability of the computation
page 31
Thread & subprogram connection
subprogram Receiver_Spg
features
spg_out : out parameter
calls {
Target_Distance;
RS: subprogram Receiver_Spg;
spg_in : in parameter
};
Target_Distance;
connections
end Receiver_Spg;
parameter RS.spg_out -> receiver_out;
parameter receiver_in -> RS.spg_in;
end receiver.impl; thread receiver
features
receiver_out : out data port
Target_Distance;
receiver_in : in data port
Target_Distance;
end receiver;
page 32
Connecting threads and shared data:
data shared_var;
end shared_var;
process implementation processing.others data implementation shared_var.impl

subcomponents end shared_var.impl;
analyse : thread analyser.impl;
display : thread display_panel.impl; thread analyser
a_data : data shared_var.impl; features
connections share : requires data access shared_var.impl;
data a_data -> display.share; end analyser;
data a_data -> analyse.share;
end processing.others; thread display_panel
features
share : requires data access shared_var.impl;
page 33
end display_panel;
Thread & thread : RPC, rendez vous
thread Remote
features
MyCalc: provides subprogram access Calc;
end Remote;
thread caller
features
MyCalc: requires subprogram access Calc;
end caller;
page 34
Outline

1. AADL components
2. Properties
page 35
AADL & Tools
Tools are mandatory to exploit any models
Otherwise, resort to traditional engineering, no value added
OSATE (SEI/CMU), http://aadl.info

Eclipse-based tools
Supports the textual syntax, reference implementation
Supports syntactic and semantic checks
Some plug-ins integrated (ARINC653 patterns)
Support for reliability analysis (Error Modeling annex)
OSATE2 meta-model as a UML2 meta-model, to ease writing
your own analysis or transformation plug-ins
page 36
AADL & Tools
STOOD, ADELE (Ellidiss) http://www.ellidiss.com
Graphical editors for AADLv1 et v2, code/documentation
generation
page 37
AADL & Tools
Cheddar (UBO/Lab-STICC) http://beru.univ-brest.fr/~singhoff/cheddar/
Import of AADLV1 models
Performance analysis, dimensioning
Based on real-time scheduling theory, and queueing theory
page 38
AADL & Tools
AADLInspector (Ellidiss) http://www.ellidiss.com
Lightweight tool to inspect AADL models, in text form
Connection with Cheddar, Simulation Engine,
AADLv2 only
page 39
AADL & Tools
Ocarina (ISAE -- http://www.openaadl.org)
Command line tool, library to manipulate AADL models
AADLv1 & v2 parser, analyzer
Code generation for High-Integrity system, in C and Ada
Support for native, RTOS (RTEMS, RT-Linux), bare boards
Mapping to colored or timed Petri Nets, WCET, …
page 40
AADL : a radar case study
Back to radar case study
Goal: to model a simple radar system
Let us suppose we have the following
requirements
1. System implementation is composed by physical devices (Hardware entity):
antenna + processor + memory + bus
2. and software entity : running processes and threads + operating system
functionalities (scheduling) implemented in the processor that represent 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.
5. [..]
page 2
Tools used for modeling
AADL syntax is both textual and graphical, with
several editors available
Modes exist for emacs, vi
OSATE2 provides a comprehensive IDE on top of
Eclipse, and additional plug-ins
IMV : Instance Model Viewer
Consistency checkers, statistics, etc.
Adele: graphical editor for Eclipse
In the following, we will use OSATE2 and IMV

page 3
Radar case study
Hardware/Software breakdown: components
PACKAGE radar
PUBLIC
PROCESS processing
-- …
END processing;
DEVICE antenna
-- …
END antenna;
END RADAR;
page 4
page 4
Radar case study
Hardware/Software breakdown: features
PROCESS processing in/out ports
FEATURES
to_screen : OUT EVENT PORT;
send_pulse : OUT EVENT PORT;
receive_pulse : IN DATA PORT;
get_angle : IN DATA PORT;
END processing;
DEVICE antenna
FEATURES
antenna_in : IN EVENT PORT; bus access
VME : REQUIRES BUS ACCESS VME;
END antenna;
page 5
page 5
Radar case study
Hardware/Software breakdown: connections
Logical cnx
Hardware cnx
page 6
page 6
Radar case study
Hardware/Software breakdown: connections
SYSTEM IMPLEMENTATION radar.simple
SUBCOMPONENTS
aerial : DEVICE antenna;
rotor : DEVICE motor;
monitor : DEVICE screen;
main : PROCESS processing.others;
cpu : PROCESSOR leon2;
VME : BUS VME;
RAM : MEMORY RAM;
CONNECTIONS
PORT 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;
page 7 BUS ACCESS VME -> RAM.VME;
Radar case study
Hardware/Software breakdown: bindings
PROPERTIES
Actual_Memory_Binding => reference (ram) applies to main;
Actual_Processor_Binding => reference (cpu) applies to main;
END radar.simple;
Bindings
page 8
page 8
Radar case study
Software elements
page 9
A few words on AADL usage
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

For now, it is just a high-level view of the design
In the next sections, we will complete the models with

Properties to support schedulability analysis
Elements to generate actual implementation
page 10
AADL : about scheduling
analysis
Summary
1. Issues about real-time scheduling : AADL to the

rescue
2. Focus on fixed-priority scheduling:
Basics on uniprocessor
3. AADL components/properties to scheduling
analysis
4. An example with Cheddar
page 2
Real-Time scheduling theory
1. A set of tasks models (to model functions of the system)
2. A set of analytical methods (feasibility tests)
E.g. Worst Case Response Time
 Ri 
Ri ≤ Deadline Ri = Ci + ∑   ⋅ C j
j∈hp ( i )  Pj 
3. A set of scheduling algorithms: build the full

scheduling/GANTT diagram
page 3
Real-Time scheduling theory is hard to apply
Real-Time scheduling theory
Theoretical results defined from 1974 to 1994:
feasibility tests exist for uniprocessor, periodic tasks,
shared resources
Extension through simulation for other cases
Now supported at a decent level by POSIX 1003
RTOS, ARINC653, …
Industry demanding
Yet, hard to use
page 4
Real-Time scheduling theory is hard to apply
Feasibility tests not always exist for modern architectures
Multi-cores, distributed, asynchronous, hierarchical
Requires strong theoretical knowledge
Numerous theoretical results: how to choose the right one ?
Numerous assumptions for each result.
How to abstract/model a system to access schedulability ? (e.g.
task dependency)
How to integrate scheduling analysis in the process ?
When to apply it ? What about tools ?
It is the role of an ADL to hide those details
page 5
AADL to the rescue ?
AADL helps modeling a full system, including hardware,
task sets, connections, RTOS features, …
All of these elements are mandatory to apply real-time
scheduling theory
Example: an AADL model can include periodic tasks and usual
scheduling policies
Worst case execution time (or WCET), period, deadline
Fixed priority scheduling
However, in many cases, the models stay too complex

Dependent tasks, shared buffers or buses, …
page 6
Summary

rescue
analysis
page 7
Real-time scheduling theory : models of task
Task: sequence of statements + data + state.
Usual task types:

Independent tasks or dependent tasks.
Periodic and sporadic tasks (critical functions).
Aperiodic tasks (non critical functions).
page 8
Usual parameters of a periodic task i:

Period: Pi (duration between two periodic release times). A task
starts a job for each release time.
Deadline to meet: Di, timing constraint to meet, relative to the
period/job.
First task release time (first job): Si.
Worst case execution time of each job: Ci (or capacity or WCET).
Priority: allows the scheduler to choose the task to run.
page 9
page 10
Uniprocessor usual real-time scheduling
policies
On-line/off-line scheduling: the scheduling is
computed before or at execution time?
Fixed/dynamic priority scheduler: priorities may
change at execution time?
Preemptive or non preemptive scheduling: can we
stop a task during its execution ?
Online, preemptive, fixed priority scheduler with Rate

Monotonic priority assignment (RM, RMS, RMA).
page 11
Uniprocessor fixed priority scheduling
Fixed priority scheduling :
Scheduling based on fixed priority => critical
applications.
Priorities are assigned at design time (off-line).
Efficient and simple feasibility tests.
Scheduler easy to implement into real-time operating
systems.
Rate Monotonic priority assignment :
Optimal assignment in the case of fixed priority
scheduling and uniprocessor.
Periodic tasks only.
page 12
Two steps:
1. Rate monotonic priority assignment:
the highest priority tasks have the smallest periods. Priorities
are assigned off-line (e.g. at design time, before execution).
2. Fixed priority scheduling:

at any time, run the ready task which has the highest priority
level.
page 13
Rate Monotonic assignment and preemptive
fixed priority scheduling:
Assuming VxWorks priority levels (high=0 ; low=255)

T1 : C1=6, P1=10, Prio1=0
page 14
T2 : C2=9, P2=30, Prio2=1
Feasibility/Schedulability tests:
1. Run simulations on hyperperiod = [0,LCM(Pi)].
Sufficient and necessary (exact result). Any priority
assignment and preemptive/non preemptive scheduling.
2. Processor utilization factor test:
=∑ / ≤ . (2 -1)
Rate Monotonic assignment and preemptive scheduling.
Sufficient but not necessary. Does not compute an exact
result.
3. Task worst case response time, noted ri : delay
between task release time and task end time. Sometime
an exact result. Any priority assignment but preemptive
scheduling.
page 15
Compute ri, task i worst case response time:
Assumptions: preemptive scheduling, synchronous
periodic tasks.
Task i response time = task i capacity + delay the task i

has to wait for higher priority task j. Or:
 Ri 
Ri = Ci + ∑ waiting time due to j or Ri = Ci + ∑   ⋅ C j
j∈hp ( i ) j∈hp ( i )  Pj 
hp(i) is the set of tasks which have a higher priority than

task i. returns the smallest integer not smaller than x.
page 16
page 17
Example: T1(P1=7, C1=3), T2 (P2=12, C2=2), T3 (P3=20, C3=5)
1 = 1 = 3 ⇒ "1 = 3
2 = 2=2
2 2
2 = C2 + . 1=2+ .3 = 5
1 7
2 5
2 = C2 + . 1=2+ . 3 = 5 ⇒ "2 = 5
1 7
3 = 3=5
3 3
3 = C3 + . 1+ . 2 = 10
1 2
3 3
3 = C3 + . 1+ . 2 = 13
1 2
3 3
3 = C3 + . 1+ . 2 = 15
1 2
3 3
3 = C3 + . 1+ . 2 = 18
1 2
3 3
3 = C3 + . 1+ . 2 = 18 ⇒ "3 = 18
1 2
page 18
Example with the AADL case study:
“display_panel” thread which displays data. P=100, C=20.
“receiver” thread which sends data. P=250, C=50.
“analyser” thread which analyzes data. P=500, C=150.
Processor utilization factor test:

U=20/100+150/500+50/250=0.7
Bound=3.(2$ − 1)=0.779
U≤Bound => deadlines will be met.
Task response time: R_analyser=330, R_display_panel=20,

R_receiver=70.
Run simulations on hyperperiod: [0,LCM(Pi)] = [0,500].
page 19
page 20
Fixed priority and shared resources
Previous tasks were independent … does not
really exist in true life.
Task dependencies :
Shared resources.
E.g. with AADL: threads may wait for AADL protected data
component access.
Precedencies between tasks.
E.g with AADL: threads exchange data by data port
connections.
page 21
Shared resources are usually modeled by semaphores.
We use specific semaphores implementing inheritance protocols:
To take care of priority inversion.
To compute worst case task blocking time for the access to a
shared resource. Blocking time Bi.
Inheritance protocols:
PIP (Priority inheritance protocol), can not be used with more than
one shared resource due to deadlock.
PCP (Priority Ceiling Protocol) , implemented in most of real-time
operating systems (e.g. VxWorks).
Several implementations of PCP exists: OPCP, ICPP, …
page 22
What is Priority inversion: a low priority task blocks a
high priority task
Bi = worst case on the shared resource waiting time.

page 23
ICPP (Immediate Ceiling Priority Protocol):

Ceiling priority of a resource = maximum static priority of the tasks
which use it.
Dynamic task priority = maximum of its own static priority and the
ceiling priorities of any resources it has locked.
Bi=longest critical section ; prevent deadlocks
page 24
How to take into account the waiting time Bi:
Processor utilization factor test :

*+ * -.
∀ ,1 ≤ ≤ ∶ ∑+/ + ≤ . (2 0 − 1)
,+ ,
Worst case response time :
 Ri 
Ri = Bi + Ci + ∑   ⋅ C j
j∈hp ( i )  Pj 
page 25
To conclude on scheduling analysis
Many feasibility tests: depending on task, processor, scheduler, shared
resource parameters or dependencies. What about uniprocessor or
multiprocessor or hierarchical or distributed?
 Ri 
Ri = Ci + ∑   ⋅ C j
j∈hp ( i )  Pj 
Many assumptions : require preemptive and fixed priority scheduling,

synchronous periodic independent tasks with deadlines on requests …
Many feasibility tests …. Many assumptions …

How to choose them?
page 26
Summary

rescue
analysis
page 27
AADL to the rescue ?
Issues:
Ensure all required model elements are given for the analysis
Ensure model elements are compliant with analysis
requirements
AADL helps because:

AADL as a pivot language between tools. International
standard.
Close to the real-time scheduling theory: real-time scheduling
concepts can be found. Ex:
Component categories: thread, data, processor
Property sets: Thread_Properties,
Timing_Properties, Communication_Properties,
page 28 AADL_Project
Property sets for scheduling analysis
Properties related to processor:
Preemptive_Scheduler : aadlboolean applies to (processor);
Scheduling_Protocol:
inherit list of Supported_Scheduling_Protocols
applies to (virtual processor, processor);
-- RATE_MONOTONIC_PROTOCOL,
-- POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL, ..
page 29
Properties related to the threads/data:
Compute_Execution_Time: Time_Range
applies to (thread, subprogram, …);
Deadline: inherit Time => Period applies to (thread, …);
Period: inherit Time applies to (thread, …);
Dispatch_Protocol: Supported_Dispatch_Protocols
applies to (thread);
-- Periodic, Sporadic, Timed, Hybrid, Aperiodic, Background,
...
Priority: inherit aadlinteger applies to (thread, …, data
Concurrency_Control_Protocol:
Supported_Concurrency_Control_Protocols applies to (data);
page 30
-- None, PCP, ICPP, …
Example:
properties subcomponents
receiver : thread receiver.impl;
Dispatch_Protocol => Periodic; analyzer : thread analyzer.impl;
Compute_Execution_Time => 31 ms .. 50 ms; target : data target_position.impl;
Deadline => 250 ms; ...
Period => 250 ms; processor implementation leon2
end receiver.impl; properties
Scheduling_Protocol =>
data implementation target_position.impl RATE_MONOTONIC_PROTOCOL;
properties Preemptive_Scheduler => true;
Concurrency_Control_Protocol end leon2;
=> PRIORITY_CEILING_PROTOCOL; system implementation radar.simple
end target_position.impl; subcomponents
main : process processing.others;
cpu : processor leon2;
page 31 ...
Summary

rescue
analysis
page 32
Cheddar : a framework to access
schedulability
Cheddar tool =
analysis framework (queueing system theory & real-time scheduling theory)
+ internal ADL (architecture description language)
+ various standard ADL parsers (AADL, MARTE UML)
+ simple model editor.
Two versions :
Open source (Cheddar) : educational and research.
Industrial (AADLInspector) : Ellidiss Tech product.
Supports : Ellidiss Tech., Conseil régional de Bretagne, BMO,
EGIDE/Campus France, Thales Communication
AADL is a rich language : Cheddar proposes design patterns to

help engineers to select relevant feasibility tests
page 33
A “design pattern” approach to increase
real-time scheduling usability
Define a set of AADL design patterns of real-time systems.

= models a typical thread communication or synchronization.
= set of constraints on entities of the AADL model.
For each design pattern, define feasibility tests that can be

applied according to their applicability assumptions.
Schedulability analysis of a AADL model:

1. Checks compliancy of the AADL model with one of the design-
patterns … which then gives which feasibility tests can be applied.
2. Compute these feasibility tests.
page 34
A “design pattern” approach to increase
real-time scheduling usability
Specification of various design patterns:
• Time-triggered : time triggered architecture (data port
connection)
• Ravenscar : shared data and PCP (data component).
• Black board : readers/writers synchronization
• Queued buffer : producer/consumer synchronization
• …
• Compositions of design patterns.
Example of the Ravenscar design-pattern.
page 35
The «Ravenscar» design pattern
Ravenscar:
Part of the Ada 1995 standard
A set of guidelines/constraints to enable efficient and deterministic task
scheduling of Ada programs
Later extended to Java RTSJ, C/POSIX, and AADL
Objective: remove all that prevent Ada programs analysis

1. All Ada tasks are either periodic or sporadic
2. Communication through shared data, no Ada rendez-vous
3. Shared data protected by PCP
4. Static, no dynamic creation of Ada tasks
5. Fixed priority preemptive scheduling similar to POSIX 1003
Feasibility test to compute: worst case thread response time + thread

blocking time due to data component access.
page 36
Radar Example:
properties subcomponents
receiver : thread receiver.impl;
Dispatch_Protocol => Periodic; analyzer : thread analyzer.impl;
Compute_Execution_Time => 31 ms .. 50 ms; target : data target_position.impl;
Deadline => 250 ms; ...
Period => 250 ms; processor implementation leon2
end receiver.impl; properties
Scheduling_Protocol =>
data implementation target_position.impl RATE_MONOTONIC_PROTOCOL;
properties Preemptive_Scheduler => true;
Concurrency_Control_Protocol end leon2;
=> PRIORITY_CEILING_PROTOCOL; system implementation radar.simple
end target_position.impl; subcomponents
main : process processing.others;
cpu : processor leon2;
page 37 ...
Demos:
Scheduling analysis of the radar example with Cheddar
.. And with AADLInspector also
page 38
AADL : about code generation
AADL objectives
AADL requirements document (SAE ARD 5296)
Analysis and Generation of systems
Generation can encompasses many dimensions
1. Generation of skeletons from AADL components
Like from UML class diagrams
2. Generation of system archetypes
Tasks, types, runtime configuration parameters, etc.
In the following, we consider option #2

Supported by Ocarina, see http://www.openaadl.org
2
AADL and code generation
AADL has a full execution semantics
Allow for full analysis:
Scheduling, security, error, behavior
Issue: what about the implementation ?

How to go to code?
While preserving both the semantics and non
functional properties ?
Solution: enrich AADL with annexes documents
To describe application data
To detail how to bind code to AADL models
3
About AS5506/2 (Jan. 2011)
This document consists of three annexes to the
SAE AADL standard that
The Data Modeling Annex provides guidance on a
standard way of associating data models expressed
in other data modeling notations such as UML or
ASN.1 with architecture models expressed in AADL,
The Behavior Annex enables modeling of
component and component interaction behavior in a
state-machine based annex sublanguage, and
The ARINC653 Annex provides guidance on a
standard way of representing ARINC653 standard
compliant partitioned embedded system architectures 4
in AADL models.
About data modeling annex
Allow one to clarify actual representation of data
Integer, floats, etc. with Data_Representation
Actual size of data
16/32/64 bits integers with Source_Data_Size
Admissible range, precision
Patterns for composite types, unions, etc.
Based on a dedicated property set Data_Model
5
AADL: modeling data types
Solution: enhance definition of types
One step closer to source code
Note: irrelevant for scheduling analysis
features
receiver_out : out parameter Target_Distance;
receiver_in : in parameter Target_Distance;
end Receiver_Spg;
data Target_Distance
properties
Data_Model::Data_Representation => integer;
end Target_Distance;
6
AADL and subprograms
Issue: how to bind user code ?
Solution: use default AADLv2 properties
features
properties
Source_Language => (Ada95); -- defined in AADL_Project
Source_Name => "radar.receiver";
end Receiver_Spg;
7
AADL and programming languages
Issue: how to map source code ?
Solution: guidelines provided in the
programming language annex document
Mapping rules from AADL and the target language
Similarly OMG IDL mappings for CORBA
features
end Receiver_Spg; procedure Receiver -- Ada
(Receiver_Out : out Target_Distance;
Receiver_In : Target_Distance);
void receiver /* C99 */
(target_distance *receiver_out,
target_distance receiver_in); 8
About AADL_Project
AADL_Project is a property set, project specific
Enumerators for particular configuration
Defined w.r.t. model processing tools
Supported_Scheduling_Protocols: type enumeration

(SporadicServer, RMS, FixedTimeline, EDF, …
Supported_Concurrency_Control_Protocols: type enumeration

(None_Specified, Priority_Inheritance, Priority_Ceiling, ..
Supported_Source_Languages: type enumeration

(Ada95,C, Scade, Simulink, …
9
Attaching code to components
Connecting subprograms to threads
thread receiver
features
receiver_out : out data port radar_types::Target_Distance;
receiver_in : in data port radar_types::Target_Distance;
end receiver;

properties
Dispatch_Protocol => Periodic;
Compute_Entrypoint_Source_Text => « radar.transmitter » ;
-- Attaching subprogram to thread, executed at each dispatch
end receiver.impl;
Early specifications, for referring to a symbol

10
Connecting subprograms to threads
thread receiver
features
receiver_in : in event data port radar_types::Target_Distance
{Compute_Entrypoint_Source_Text => « radar.transmitter » ;
-- Attaching subprogram to port, executed at each dispatch
};
end receiver;
thread receiver2
features
receiver_in : in data port radar_types::Target_Distance
{Compute_Entrypoint => classifier (transmitter_spg);
-- Attaching subprogram to port, more precise
};
end receiver2;
11
Related properties
Activate_Entrypoint: upon thread activation
Compute_Entrypoint: dispatch
Finalize_Entrypoint: finalization
Initialize_Entrypoint: initialization of component
Recover_Entrypoint: in case of error
Exist for both textual symbols (<x>_Source_Text
property) or subprograms classifiers
Applied to thread, device, subprogram, event port, event
data port entities
12
AADL and code generation
Issue: How much code should we write ? Tasks
? Queues ?
Answer: the architecture says all
One can define a full framework and use it
Limited value
Generate as much things as possible
Reduce as much as possible error-prone and tedious tasks
Ocarina: massive code generation

Take advantage of global knowledge to optimize
code, and generate only what is required 13
Building process for HI-DRE systems using
Ocarina
14
Benefits of code generation ?
Is it worth a try ?
Of course yes !
One pivot notation based on a unique notation
A-priori validation, using Cheddar, BIP, TINA ..
Optimized code generation
Measures show a difference of 6% in size
Part of the promise of MBSE

One binary, no source code written for the most
difficult part: the architecture, buffer, concurrency
Could be combined with other code generators like 15
SCADE or Simulink to achieve zero-coding paradigm
Radar demo: code generation
walkthrough
16
The Radar case study v1
Model done with OSATE2
IMV for graphical view
Text-based to have full

control on properties
Ocarina for code

generation
17
Deployment on native target
AADL Processor: execution platform
processor cpu_leon2
properties
Scheduling_Protocol => (RMS);
-- Configuration of scheduler
Deployment::Execution_Platform => Native;
-- Target platform
end cpu_leon2;
+ simulation code for devices
page 18
Generating Cheddar + code
Result from Cheddar Traces from
execution./radar_v1/main/main
macbookair-hugues%
2) Feasibility test based on [ 0] Transmitter
worst case task response time : [ 0] Controller, motor is at angular position 1
[ 1] Analyser: target is at distance: 0 at angular
[ 1] Display_Panel: target is at ( 0, 0)
- Bound on task response time : [ 1] Receiver, target is at distance 1
main_analyse => 130 [ 500] Transmitter
main_display => 70 [ 1001] Transmitter
main_receive => 40 [ 1500] Transmitter
main_control_angle => 20 [ 1500] Receiver, target is at distance 2
main_transmit => 10 [ 1500] Controller, motor is at angular position 2
- All task deadlines will be met : [ 2000] Display_Panel: target is at ( 0, 0)
[ 2001] Transmitter
the task set is schedulable. [ 2500] Transmitter
[ 3000] Transmitter
[ 3000] Receiver, target is at distance 3
[ 3000] Controller, motor is at angular position 3
[ 3500] Transmitter
[ 4000] Transmitter
[ page
4000] Display_Panel: target is at ( 19
0, 0)
Assessment
It works ;)
Execution traces meet scheduling simulation
And expected behavior
Initial models use event ports
For each thread: one mutex + PCP is used
page 20
The Radar case study v2
Change port communication with shared
variable
21
Generating Cheddar + code
Result from Cheddar Traces from
execution./radar_v2/main/main
macbookair-hugues%
2) Feasibility test based on [ 0] Transmitter
worst case task response time : [ 0] Controller, motor is at angular position 1
[ 1] Analyser: target is at distance: 0 at angular
[ 1] Display_Panel: target is at ( 0, 0)
- Bound on task response time : [ 1] Receiver, target is at distance 1
main_analyse => 130 [ 500] Transmitter
main_display => 70 [ 1001] Transmitter
main_receive => 40 [ 1500] Transmitter
main_control_angle => 20 [ 1500] Receiver, target is at distance 2
main_transmit => 10 [ 1500] Controller, motor is at angular position 2
- All task deadlines will be met : [ 2000] Display_Panel: target is at ( 0, 0)
[ 2001] Transmitter
the task set is schedulable. [ 2500] Transmitter
[ 3000] Transmitter
[ 3000] Receiver, target is at distance 3
[ 3000] Controller, motor is at angular position 3
[ 3500] Transmitter
[ 4000] Transmitter
[ page
4000] Display_Panel: target is at ( 22
0, 0)
Assessment
It still works ;)
We can exploit models a little more
data PO_Target_Distance
features
-- …
properties
Concurrency_Control_Protocol => Priority_Ceiling;
-- Priority is not set, will use default value
-- of maximum priority
end PO_Target_Distance;
Scheduling simulation, processor cpu :

Cheddar indicates that - Number of preemptions : 0
- Number of context switches : 4
We can change protocol to none safely

page 23
AADL & Analysis: scheduling
analysis strikes back
What about WCET?
Issue: Cheddar can evaluate schedulability of
an AADL model, extracting all relevant
information
What about figures for WCET ?
Usually relies on user-provided inputs, possibly wrong
Yet, we have code generated provided by AADL-to-
code + user-code
Solution: integrate a WCET tool in the toolchain
In Ocarina, use of Bound-T (Tidorum LtD)
Others exist: AbsInt, Rapita, …
25
WCET computation
Three-step process
• Code generation: Ocarina / PolyORB-HI/Ada
• Analysis binary with Bound-T, retrofit to AADL models
• Evaluation using Cheddar
26
WCET computation
Three-step process
27
WCET computation
Three-step process
28
Integration to Ocarina
Issue: Bound-T walks through

all execution paths, including
useless (exception, drivers), or
unbounded (periodic task body)
Solution: assertion file to guide
the analysis
RTOS-dependent
Copyrigh Tidorum Ltd.

AADL runtime specific
Generated from model
Bound-T can now analyze
safely the whole system, user
code is “just” sequential page 29
AADL & other MDE frameworks
Integration with Simulink, SCADE et al.
AADL and other modeling notations
AADL helps modeling architectures
Capture key aspects of design: hardware/software
Expression of some non functional properties: priority,
resource consumption, latency, jitter, …
Enables: scheduling analysis, resource dimensioning,
mapping to formal methods, fault analysis, …
Functional notations (Simulink, SCADE, ..)
describes precisely system behavior
Provides a high-level behavioral/computational view
mapped onto hardware/software elements
Natural complement to ADLs 31
”Zero coding” paradigm
Code generation from models is now a reality
Proposed by many tools
Functional models
kcg: SCADE’s certified code generation
Simulink Coder
Architectural models
Ocarina: AADL code generator for HIsystems
Foundations for a “zero coding” approach
Model, then integrate code generated from each view
Issue: which integration process ?
32
Two approaches, driven by user demand
Code generation patterns
Each functional framework relies on same foundations
Synchronous: discrete computation cycles
Asynchronous: function calls
SCADE/Simulink/Esterel: a 3-step process
Fetch in parameters from AADL subprograms
Call the reaction function to compute output values
Send the output as out parameters of the AADL subprogram
Architectural blocks are mapped onto programming
language equivalent constructs
Ocarina relies on stringent coding guidelines to meet
requirements for High-Integrity systems, validated though test
harness by ESA, Thales, SEI, and their partners
33
From AADL + X tocode
Ocarina handles all code integration aspects

How to map AADL concepts to source code artefacts
(POSIX threads, Ada tasks, mutexes, ...)
Handle portability concerns to several platforms, from
bare to native
+ some knowledge on how a SCADE or Simulink
models is mapped onto C code
So that integration is done by the code generator
No manual intervention required
Supports “zero coding” approach
34
Application-driven process
Functions may be defined first, then refined to
be bound to an existing architecture”
35
Architecture-driven process
Reverse option: architecture is defined first, then
a skeleton of the functional model is deduced,
then implemented
subprogram spg_scade
features
input: in parameter integer {Source_Name => "add_input";};
output: out parameter integer {Source_Name => "add_output";};
properties
source_name => "inc";
source_language => Scade;
source_location => "/path/to/scade-code/";
end spg_scade;
36
How to bind to AADL models ?
In both cases, we rely on standard AADLv2
patterns
Source_Language <-> SCADE or Simulink
Source_Name <-> SCADE node or Simulink block
Source_Location <-> path to kcg orSimulink Coder
generated code
Smooth integration of AADL and other functional

modeling
Providing only required information
While remaining 100% automatic 37
The ASSERT ESA demonstrator (2008)
38
Conclusion
System are heterogeneous, so are models

AADL separates architecture from functional models
Allows reference from the architecture to function blocks
Integration of AADL and SCADE or Simulink in to
perform full generation of systems is desirable
Advantages
“Zero coding” paradigm to ease integration work
Quality of code generated for both functions and
architecture
Opens the path towards qualification/certification of
39
complex embedded systems at model-level
Conclusion
To summarize
We introduced the concepts of AADL
Architectural description
Patterns for scheduling analysis and code generation
Not covered today:

Reliability analysis using Error Modeling Annex
Modeling of IMA systems + code generation
Behavioral modeling + model checking
and much more !
page 2
Materials for this tutorial
All materials can be found in
http://www.aadl.info : updates on AADL standard
http://www.openaadl.org : resources around Ocarina
http://beru.univ-brest.fr/~singhoff/cheddar/: Cheddar
and real-time scheduling
Materials for this tutorial (slides, examples, etc.)

are on http://www.openaadl.org
Feel free to contact us for more details

12/11/2008 3/24

AADLv2 - An Introduction

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AADLv2 - An Introduction

Uploaded by

Copyright:

Available Formats

AADLv2: an Architecture Description

Language for the Analysis and

Jérôme Hugues*, Frank Singhoff+

1. AADL a quick overview

ADL for real-time systems: AADL (Architecture

Require semantics => any AADL entity has a

Component categories: model real-time abstractions,

thread bar_thread -- bar_thread is a

thread bar_thread -- bar_thread is a spor

AADL is a rich language :

1. AADL a quick overview

Thread data Threadgroup process

thread receiver process processing

thread implementation receiver.impl process implementation processing.others

subprogram Receiver_Spg thread receiver

subprogram ComputeCRC_Spg thread implementation receiver.impl

thread implementation receiver.impl processor leon2

process processing system radar

process implementation processing.others system implementation radar.simple

process thread, thread group, data

memory Memory, bus

1. AADL a quick overview

Allowed types in properties:

Can be propagated to subcomponents: inherit

property set AADL_Projects isproperty set Timing_Properties is

1. AADL a quick overview

features : component point part of the interface. Each feature has a

Features category: specification of the type of interaction

Features direction for port and parameter:

1. Sampling connection: takes the latest value

process implementation processing.others data implementation shared_var.impl

1. AADL a quick overview

OSATE (SEI/CMU), http://aadl.info

In the following, we will use OSATE2 and IMV

Keep in mind models support an objective

In the next sections, we will complete the models with

1. Issues about real-time scheduling : AADL to the

3. A set of scheduling algorithms: build the full

It is the role of an ADL to hide those details

However, in many cases, the models stay too complex

1. Issues about real-time scheduling : AADL to the

Usual task types:

Usual parameters of a periodic task i:

Online, preemptive, fixed priority scheduler with Rate

2. Fixed priority scheduling:

Assuming VxWorks priority levels (high=0 ; low=255)

Task i response time = task i capacity + delay the task i

hp(i) is the set of tasks which have a higher priority than

Processor utilization factor test:

Task response time: R_analyser=330, R_display_panel=20,

Bi = worst case on the shared resource waiting time.

ICPP (Immediate Ceiling Priority Protocol):

Processor utilization factor test :

Worst case response time :

Many assumptions : require preemptive and fixed priority scheduling,

Many feasibility tests …. Many assumptions …

1. Issues about real-time scheduling : AADL to the

AADL helps because:

Properties related to processor:

Preemptive_Scheduler : aadlboolean applies to (processor);

Deadline: inherit Time => Period applies to (thread, …);

Period: inherit Time applies to (thread, …);

Priority: inherit aadlinteger applies to (thread, …, data