aadl: architecture analysis and design language
DESCRIPTION
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/. http://www.ivanomalavolta.comTRANSCRIPT
Ivano Malavolta
Lab on AADL
Introduction
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. deadline).
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 Often with temporal constraints n Part of a complete device, often including hardware and
mechanical parts n Limited amount of resources
Real-Time, Critical, Embedded Systems
• Need to handle time. Concurrent applications. • May have dramatic impact on human life, on the
system, ... • Do not allow software maintenance
à difficult to correct erroneous software/bugs
• High implementation cost – temporal constraints verification, safety, dedicated hardware/
software
• Examples : aircraft, satellite, automotive, …
5
Embedded software system arch.
Real-Time, Critical, Embedded Systems
Specific software engineering methods/models/tools to master quality and cost
n Example : early verifications at design step
Advantages of early fault discovery
Objectives of this lecture
• Issues – How to model/design a real-time critical embedded system that
conforms to requirements? – How to verify the solution? – How to prototype/implement it?
• One solution among others: use an architectural language
• to model the system • to run various verification • and to automatically produce the system
• Focus on the AADL2.1 SAE standard (2012)
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 entities : 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
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: Case study – A radar illustrative case study
Basics on AADL
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
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, …
AADL: Architecture Analysis & Design Language
• International standard promoted by SAE, AS-2C committee, released as AS5506 family of standards
• Version 1.0 (2004), version 2 (2009), 2.1 (2012) – Based on feedback from industry users, mostly from the space
and avionics domain
• Annex document to address specific needs – Behavior, data, error modeling, code generation, …
AADL capabilities
AADL for analysis
AADL in the process
AADL: Architecture Analysis & Design Language Based on the component-connector paradigm Key Elements: • Core AADL language standard
– Textual & graphical, precise semantics, extensible
• AADL Meta model & XMI/XML standard – Model interchange & tool interoperability
• Annexes Error Model Annex as standardized extension – Error Model Annex addresses fault/reliability modeling, hazard
analysis
• UML 2.0 profile for AADL – Transition path for UML practitioners community
Different representations of an AADL model
The AADL language in one slide
AADL components
• AADL model : hierarchy/tree of components
• AADL component • Model a software or a hardware entity • May be organized in packages : reusable • Has a type/interface, one or several implementations • May have subcomponents • May combine/extend/refine others • May have properties : valued typed attributes (source code file name,
priority, execution time, memory consumption, …)
• Component interactions – Modeled by component connections – AADL features are connection points
AADL components
• How to declare a component: – Component type:
• name, category, properties, features => interface
– 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 – Software components – Hardware components: execution platform – Systems : bounding box of a system
• Model a deployment
Component type
• AADLv2 distinguished type and implementation Component type = high-level specification of a component
All component type declarations follow the same pattern:
24
<category> foo [extends <bar>]features -- list of features -- interfaceproperties -- list of properties -- e.g. priorityend foo;
Inherit features and properties from parent
Interface of the component:Exchange messages, access to data or call subprograms
Some properties describing non-functional aspect of thecomponent
Component type example
-- model a sequential execution flow subprogram Spg -- Spg represents a C function, features -- in file "foo.c", that takes one in_param : in parameter foo_data; -- parameter as input properties Source_Language => C; Source_Text => ("foo.c"); end Spg;
-- model a schedulable flow of control thread bar_thread -- bar_thread is a sporadic thread : features -- dispatched whenever it in_data : in event data port foo_data; -- receives an event on its “in_data" properties -- port Dispatch_Protocol => Sporadic; end bar_thread;
Standard properties, one candefine its own properties
Component implementation
• Component Implementation completes the interface – Think spec/body package (Ada), interface/class (Java)
<category> implementation foo.i [extends <bar>.i]subcomponents -- internal componentscalls -- called subprograms, -- only for threads or subprogramsconnectionsproperties -- list of properties -- e.g. Deadlineend foo.i;
foo.i implements foo
Component implementation example subprogram Spg -- Spg represents a C function, features -- in file "foo.c", that takes one in_param : in parameter foo_data; -- parameter as input properties Source_Language => C; Source_Text => ("foo.c"); end Spg;
thread bar_thread -- bar_thread is a sporadic thread, features -- it is dispatched whenever it in_data : in event data port foo_data; -- receives an event properties Dispatch_Protocol => Sporadic; end bar_thread;
thread implementation bar_thread.impl -- in this implementation, at each -- dispatch we execute the "C" call
calls -- sequence. We pass the dispatch C : { S : subprogram spg; }; -- parameter to the call sequence
connections P1: parameter in_data -> S.in_param; end bar_thread.impl;
Connect data/parameter
AADL concepts
• AADL introduces many other concepts: – Related to embedded real-time critical systems
• AADL flows: capture high-level data + execution flows • AADL modes: model operational modes in the form
of an alternative set of active components, connections, …
– To ease models design/management • AADL packages (similar to Java, renames, private/
public) • AADL abstract component, component extensions, …
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
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 – this is done 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. 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 : hierarchy of threads
Software components
Example of a process component 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;
Software components
Example of a thread component : 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; . . .
Thread group
A thread group represents an organizational component to logically group threads contained in a process Thread groups can be hierarchically nested
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
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
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;
Ports compatibility
Data connection policies
Immediate receiver thread is immediately awaken, and will read data when emitter finished
Delayed actual transmission is delayed to the next time frame
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 mode transition example
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
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
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. Quick overview 2. AADL key modeling constructs
1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems
3. Tool support
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.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 => 3 .. 4 ms; Deadline => 150 ms ; end receiver; thread implementation receiver.impl properties -- (2) Deadline => 160 ms; Compute_Execution_Time => 4 .. 10 ms; end receiver.impl;
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;
AADL predefined property sets
Measurement units
Properties are typed with units to model physical systems, 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;
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
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
Bindings : model the deployment of components inside the component hierarchy
System
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;
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
86
System instances
Component types and instances 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
System instances 2
System instances are automatically generated by OSATE starting from complet 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
WHY extensions?
– Add elements to a classifier • features, subcomponents, connections, flows, etc.
– Refine existing elements in a component – Add or override properties
Why extension?
Extension example
Extension example 2
Subcomponents array
Feature arrays
Connecting arrays
Connection patterns
Outline
1. AADL a quick overview 2. AADL key modeling constructs
1. AADL components 2. Properties 3. Component connection
3. AADL: tool support
AADL & Tools
• OSATE (SEI/CMU, http://aadl.info) – Eclipse-based tools. Reference implementation. AADLv1 and v2 – Textual 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, …
Case study
Radar case study
Hardware/Software breakdown: components
PACKAGE radar PUBLIC PROCESS processing -- … END processing; DEVICE antenna -- … END antenna; END RADAR;
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;
Radar case study
Hardware/Software breakdown: connections
Logical cnx
Hardware cnx
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;
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;
Radar case study
• Software elements
On flow latency analysis…
On flow latency analysis…
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
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. [Flow latency analysis]
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
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
Contact Ivano Malavolta |
Post-doc researcher Gran Sasso Science Institute
iivanoo
www.ivanomalavolta.com