This document introduces the Architecture Analysis and Design Language (AADL) and uses a radar system as an example to demonstrate AADL modeling concepts. It breaks down the radar system into hardware and software components, showing how to model processes, threads, devices, and connections between them. It also models the deployment of software processes onto hardware processors and memories. The example illustrates key AADL concepts like components, features, connections, bindings, and properties.

1. Ivano Malavolta
AADL

2. Introduction

3. Real-Time, Critical, Embedded
Systems
« Real-time systems are defined as those systems in
which the correctness of the system depends not only on
the logical result of computation, but also on the time at
which the results are produced » Stankovic, 1988.
Properties we look for:
– Functions must be predictable: the same data input will
produce the same data output.
– Timing behavior must be predictable: must meet temporal
constraints (e.g. deadlines).

4. Real-Time, Critical, Embedded
Systems
Critical (or hard) real-time systems:temporal constraints
MUST be met, otherwise defects could have a dramatic
impact on human life, on the environment, on the system
Embedded systems:computing system designed for
specific control functions within a larger system
n Part of a complete device, often including hardware and
mechanical parts
n Limited amount of resources

5. Outline of this lecture
Goal: introduce model-based description of embedded real-
time critical systems using the AADLv2 architectural language
• Part 1: Basics on AADLv2 core
– Syntax, semantics of the language
• Part 2: Example
– The radar illustrative example

6. Basics on AADL

7. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support

8. Introduction
AADL: AL for real-time critical embedded systems
(Architecture Analysis and Design Language)
– Goal : modeling software and hardware architectures
• to master complexity
• to perform analysis
• to generate code
• ….
– Concepts : components, connections, deployments.
– Many ALs : formal/non formal, application domain, …

9. AADL for analysis

10. Different representations of an AADL model

11. The AADL language in one slide

12. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support

13. Summary of AADL elements

14. 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
– this is done by the tool

15. 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. Execute
programs
• Data : data placeholder, e.g. C
struct, C++ class, Ada record
• Subprogram : a sequential
execution flow. Associated to a
source code (C, Ada) or a model
(SCADE, Simulink)
• Thread group : hierarchyof
threads

16. Software components
Example: process composed of two threads
thread receiver
end receiver;
thread implementation receiver.impl
end receiver.impl;
thread analyser
end analyser;
thread implementation analyser.impl
end analyser.impl;
process processing
end processing;
process implementation processing.others
subcomponents
receive : thread receiver.impl;
analyse : thread analyser.impl;
. . .
end processing.others;

17. Software components
a thread may call different subprograms
thread receiver
end receiver;
thread implementation receiver.impl
calls CS : {
call1 : subprogram Receiver_Spg;
call2 : subprogram ComputeCRC_Spg;
};
end receiver.impl;
subprogram Receiver_Spg
end Receiver_Spg;
subprogram ComputeCRC_Spg
end ComputeCRC_Spg;
. . .

25. Subprogram
A subprogram component represents an execution entry point in source
text
No component can contain subprogram subcomponents. Instances of
subprogram don't exist
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

26. States of a thread

27. Subprogram local call example

28. Subprogram remote call example

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

30. Example of data

31. Component connection

33. Component connection
Features of subcomponents are connected in the
“connections” subclause of the enclosing component
Example
thread analyser
features
analyser_out : out data port
Target_Position.Impl;
end analyser;
thread display_panel
features
display_in : in data port Target_Position.Impl;
end display_panel;
process implementation processing.others
subcomponents
display : thread display_panel.impl;
analyse : thread analyser.impl;
connections
port analyse.analyser_out -> display.display_in;
end processing.others;

35. Ports compatibility

36. Port groups

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

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

39. Mode example

40. Internal mode
transition
example

41. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support

42. 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
Device Memory bus Processor

50. Software/platform binding
Maps application software elements to execution platform
elements using binding properties

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

52. Bus access
Access to buses is declared
explicitly in AADL

54. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support

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

56. Property types

57. 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.others
subcomponents
receive0 : 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 receiver
properties -- (1)
Compute_Execution_Time => 3ms .. 4ms;
Deadline => 150 ms ;
end receiver;
thread implementation receiver.impl
properties -- (2)
Deadline => 160 ms;
Compute_Execution_Time => 4ms .. 10ms;
end receiver.impl;

58. 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 new analysis as power 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;

59. AADL predefined property sets

60. Measurement units
Properties are typed with units to model physicalsystems,
related to embedded real-time critical systems
property set AADL_Projects is
Time_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 aadlinteger
0ps .. Max_Time units Time_Units;
Time_Range: type range of Time;
Compute_Execution_Time: Time_Range
applies to (thread, device, subprogram,
event port, event data port);
end Timing_Properties;

61. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support

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

63. AADL package example

64. AADL systems
Help structuring an architecture, with its own hierarchyof
subcomponents.
A system can include one or several subsystems
In an AADL specification there is always a root system
component
Bindings : model the deployment of components inside the
component hierarchy
System

65. subprogram Receiver_Spg …
thread receiver …
thread implementation receiver.impl
… call1 : subprobram Receiver_Spg; …
end receiver.impl;
process processing
end processing;
process implementation processing.others
subcomponents
receive : thread receiver.impl;
analyse : thread analyser.impl;
. . .
end processing.others;
AADL systems
system radar
end radar;
system implementation radar.simple
subcomponents
main : process processing.others;
cpu : processor leon2;
properties
Actual_Processor_Binding =>
reference cpu applies to main;
end radar.simple;
device antenna
end antenna;
processor leon2
end leon2;

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

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

68. System instances
Component types and implementations are “only” blueprints
System instances represents the runtime architecture of an
operational physical system
Composed of software components + execution platform
XML for storing system instances

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

70. 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
WHY extensions?
– Add elements to a classifier
• features, subcomponents, connections, flows, etc.
– Refine existing elements in a component
– Add or override properties

71. Why extension?

72. Extension example

73. Subcomponents array

74. Feature arrays

75. Connecting arrays

76. Connection patterns

77. Outline
1. AADL a quick overview
2. AADL key modeling constructs
1. AADL components
2. Properties
3. Component connection
3. AADL: tool support

78. AADL & Tools
• OSATE (SEI/CMU, http://aadl.info)
– Eclipse-based tools. Reference implementation. AADLv1 and v2
– Textualeditors + various plug-ins
• STOOD, ADELE (Ellidiss, http://www.ellidiss.com )
– Graphical editors for AADLv1 and v2, code/documentationgeneration
• Cheddar (UBO/Lab-STICC, http://beru.univ-brest.fr/~singhoff/cheddar/ )
– Performance analysis, AADLv1 only
• AADLInspector (Ellidiss, http://www.ellidiss.com)
– Lightweight toolto inspect AADL models. AADLv1 and v2
– Industrialversion of Cheddar + SimulationEngine
• 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, …

79. Example

80. Example
Goal: to model a simple radar system
Let us suppose we have the following requirements:
1. Systemimplementation is composed of physicaldevices (Hardware
entity):antenna + processor + memory + bus
2. and software entities : running processes and threads + operating system
functionalities (scheduling) implemented in the processor that represent a
part of executionplatform and physicaldevices 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, localizationand identification

81. Radar case study
Hardware/Software breakdown: components
PACKAGE radar
PUBLIC
PROCESS processing
-- …
END processing;
DEVICE antenna
-- …
END antenna;
END RADAR;

82. Radar case study
Hardware/Software breakdown: features
in/out ports
bus access
PROCESS processing
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;
VME : REQUIRES BUS ACCESS VME;
END antenna;

83. Radar case study
Hardware/Software breakdown: connections
Logical cnx
Hardware cnx

84. 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;
BUS ACCESS VME -> RAM.VME;

85. Radar case study
• Hardware/Software breakdown: bindings
Bindings
PROPERTIES
Actual_Memory_Binding => reference (ram) applies to main;
Actual_Processor_Binding => reference (cpu) applies to main;
END radar.simple;

86. Radar case study
• Software elements

87. Radar case study
• Software elements
PROCESS IMPLEMENTATION processing.others
SUBCOMPONENTS
receive : 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;

88. Radar case study
• Software elements
PROCESS IMPLEMENTATION processing.others
SUBCOMPONENTS
receive : 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.impl
CALLS 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;

89. 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
– In this lecture, it is just a high-level view of the design
What is not covered by this lecture:
flows, annexes, multidimensional arrays, virtual
processors/buses, analyses with external tools

90. 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): An
Introduction, Peter H. Feiler David P. Gluch John J. Hudak, February
2006. [Use this as reference manual]
3. OSATE plugin: SEI validation plugins. SEI. [Analysis in general]
4. Developing AADL Models for Control Systems: A Practitioner’s
Guide. John Hudak Peter Feiler. July 2007. [Flowlatency analysis]
5. http://www.informit.com/articles/article.aspx?p=1959953
[Simple running example]

91. Links
Tool:
• http://www.aadl.info/aadl/osate/stable/2.0.8/products/
Example projects (other than the ones on Lore):
1. https://github.com/yoogx/AADLib
2. https://github.com/osate/examples
3. http://www.santoslab.org/pub/high-assurance/module-
aadl/slides/AADL-Isolette.pdf

92. Acknowledgements
Parts of this lecture have been elaborated from:
• AADLv2, a Domain Specific Language for the Modeling, the Analysis
and the Generation of Real-Time Embedded Systems. Frank Singhoff
and Jérôme Hugues, MODELS 2014 tutorial.
• SAE AADL V2: An Overview. Peter Feiler. © 2010 Carnegie Mellon
University.
• Overview of AADL Syntax. J-P. Rosen, J-F. Tilman. AADL Workshop
2005.

93. Contact
Ivano Malavolta |
Post-doc researcher
Gran Sasso Science Institute
iivanoo
ivano.malavolta@gssi.infn.it
www.ivanomalavolta.com