1
AADLArchitectural Analysis and Design Language
Jason Mowry
UW-Platteville Undergraduate Software Engineering
2
Objectives of Presentation
Talk about model-based systems engineering
The need and reason for model-based systems engineering and AADL
Familiarize with AADL syntax to get a good understanding of model-based systems engineering
Talk about benefits and briefly mention tool-support
3
Typical Software Development Process
Requirements Analysis
Design Implementation Integration
manual, paper intensive, error prone, resistant to change
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
4
Real Time Systems Development Concerns Incomplete capture of specification and design Little insight into non-functional system properties until
system integration & testing Performance (e.g., Throughput, Quality of Service) Safety - Reliability Time Critical - Security Schedulability - Fault Tolerance
System Integration - high risk Evolvability – very expensive Life Cycle Support – very expensive Leads to rapidly Outdated Components
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
5
Model-Based System Engineering
RequirementsAnalysis
Design, Analysis and
Implementation
System Integration
Predictable System Rapid Integration Upgradeability
Architecture Analysis Early In Life Cycle
Model-Based & Architecture-Driven
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
6
Ambulatory
InformationFusion
Supply Chain
Mechanized
Sensor& SignalProcessing
System Construction• AADL Runtime System • Application Software Integration
Devices Memory Bus Processor
AADL-Based System Engineering
AutomaticTargetRecognition
Guidance& Control
System Analysis• Schedulability• Performance• Reliability• Fault Tolerance• Dynamic Configurability Model the
ArchitectureAbstract, but
Precise
HTTPSDBGPS Ada Runtime
Execution Platform
. . . . . . . . . .
Application Software
SoftwareSystemEngineer
Application Developer
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
7
Focus Of SAE AADL Component View
Model of system composition & hierarchy Well-defined component interfaces
Concurrency & Interaction View Time ordering of data, messages, and events Dynamic operational behavior Explicit interaction paths & protocols
Execution view Execution platform as resources Binding of application software Specification & analysis of runtime properties
timeliness, throughput, reliability, graceful degradation, …
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
8
Architectural Analysis and Design Language AADL is a specification for
Real-time Embedded Fault-tolerant Securely partitioned Dynamically configurable
AADL is used to Design and analyze software and hardware architecture of real-time systems and their
performance-critical characteristics Describe the structure of systems such as an assembly of software components mapped
onto an execution platform Describe functional interfaces to components (inputs and outputs) Describe performance-critical aspects of components ( timing )
AADL is standardized Fields of application
Avionics, Automotive, Aerospace, Autonomous systems
9
What AADL does
Allows an embedded system to be represented as a component-based system architecture
Can model three component interactions: flow, service calls, and shared access
Can Model task execution and communication with precise time semantics
Model execution platform and specify application binding Represent operational modes and fault tolerant
configurations Support component evolution and large-scale development Accommodate analyses such as reliability &safety-
criticality through extensions
10
Benefits of AADL
Normally runtime characteristics like availability, timeliness, and security can become predictable
System architecture and implementations can be validated
Improved development process through single annotated architecture model
interoperability & integration of commercial and in- house tools
12
Composite Category
SystemA modeled system consists of application
software mapped to an execution platform
System
13
Software Category Software Components model
Souce text Virtual address space Units of concurrent execution
The components that make up this category are Process Thread Thread Group Data Subprogram
process
Thread
data
Subprogram
Thread group
14
Platform Category These components are defined as either
hardware or software that : Can schedule tasks Can enforce specified address space protection
at runtime Can store source text code and data Can perform communication for application
system connections The Components that make up this category
are Processor : Represents a component
responsible for scheduling and executing threads
Memory : Represents RAM or ROM, must have access to bus
Bus : Represents a component capable of exchanging data and control between processors, memories, and devices
Device : Represents physical devices that interface with an external environment, such as sensors and actuators
Processor
Device
Bus
Memory
15 Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
Example
16
Component Description
Category Type
Specification of the external interface Implementation
Specification of the content Instance
Instantiation of a type or an implementation
17
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
18
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
19
AADL Declarations
Component types Features : definition of how one component is
related to another component Port Subprogram Parameter Subcomponent Access
Flow Specification Describes Observable flow of Data through a
component Property Associations
Gives values to properties of the component
20
Features
Ports Types of Ports
Data Port : connection points for transfer of state data, such as sensor value
Event Port : connection points for transfer of control, through raised events that can trigger thread dispatch or mode transition
Data Event Port : connection points for transfer of events with data
Three directions Input port (in) Output port (out) Bidirectional port (in out)
Components
21
Features Subprograms
Data Subprogram Represents entrypoints to code sequences in source
text that are associated with a data type Server Subprogram
Represents connections for synchronous calls/returns between threads
Subprogram Parameters Represent the in and out parameters of a
subprogram
subprog_name : [ refined to ] [ server ] subprogram
<subprogram_component_name>
[ { < property_associations > } ] ;
22
Features Subcomponent access
Data component access represents provided and required access to shared data
Bus component access represents the accessibility of processors, memory, and devices to buses.
Code and Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
23
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
24
Component Implementation
Terms of Component ImplementationSubcomponentsConnections between the features of the
subcomponentsFlows across a sequence of
subcomponentsModes to represents operational statesProperty associations
25
Component Implementation Subcomponent
The specification of a subcomponent is defined by Category (mandatory) Type (optional) Implementation (optional)
Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
26
Component Implementation
Connections : Three type of connections Port connection : transfer of data and control
between two threads or between a thread and a processor or device
Parameter connection : flow of data between parameters of a sequence of subprogram calls
Access connection : access to shared data by a thread or by a subprogram executing within a thread or communication by platform components through a bus
29
Component Implementation Flow specification represents
Flow sources Flow originating from within a component
Flow sinks Flow ending within a component
Flow paths Flow though a component in its input port and then out in
output ports
Flow Implementation Describes the flow specification of a component in the
component implementation End-to-end flow
Specifies a flow between two different subcomponents
30
Flows
Slide from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
31
Example of Flow Implementation
Slide from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
32
Flows in AADLSystem S1
flow path F1
flow path F2
Flow SpecificationF1: flow path pt1 -> pt2F2: flow path pt1 -> pt3
pt2
pt3
pt1
Process P1
System implementation S1.impl
Process P2
Flow ImplementationF1: flow path pt1 -> C1 -> P2.F5
-> C3 -> P1.F7 -> C5 -> pt2
C1
C5C3
flow path F5
flow path F7
pt1
pt2
pt3
Connection
ActuatorController
flow path F1
C2Sensor
C1
flow sink FS1flow source FS1
End-To-End Flow DeclarationSenseControlActuate: end to end flow Sensor.FS1 -> C1 ->
Controller.F1 -> C2 -> Actuator.FS1
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
33
Component Implementation
Modes For each mode a
component Can have different
property values The configuration and
connection of subcomponents may differ
There is always one mode that is the current mode
34
Mode Example
Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
35
Component Implementation
Properties A property provides information for a feature, a
flow, a connection, a component, a mode, or a subprogram call.
A property has a name, a type, and a value Property names and type are defined in a
property set Property associations give value to properties of
components done in the component implementation
36
Example
Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
37
System Type
system GPSfeatures speed_data: in data port metric_speed {arch::miss_rate => 0.001 mps;}; geo_db: requires data access real_time_geoDB; s_control_data: out data port state_control;flows speed_control: flow path
speed_data -> s_control_dataproperties arch::redundancy => 2 X; end GPS;
38
System Implementation
system implementation GPS.securesubcomponents decoder: system PGP_decoder.basic; encoder: system PGP_encoder.basic; receiver: system GPS_receiver.basic;connections c1: data port speed_data -> decoder.in; c2: data port decoder.out -> receiver.in; c3: data port receiver.out -> encoder.in; c4: data port encoder.out -> s_control_data;flows speed_control: flow path speed_data -> c1 -> decoder.fs1 -> c2 -> receiver.fs1 -> c3 -> decoder.fs1 -> c4 -> s_control_data;modes none;properties arch::redundancy_scheme => Primary_Backup; end GPS;
39
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
40
Ports Port Group
Connected Components and/or other Port Groups
Code and Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
41
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
42
Annex
Allows use of declaration written in another language
Annex subclauses : annex-specific sublanguages whose constructs can be used in component types and component implementations
Annex libraries : declarations or reusable annex-specific sublanguage elements that can be referenced in annex subclauses
43
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
44
Packages
Like namespaces Able to organize descriptions
Component type Component implementation Port group types Annex libraries
Combine specific packages for a system specification
Packages can be nested Referenced by utilizing qualified names
45
AADL Specification
AADL Global DeclarationsPackage SpecificationsProperty Set Declarations
AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries
46
Property Set Declarations
Property sets can be pre-declared or defined by the user
Two pre-declared property sets AADL_Properties : common to all AADL
specifications AADL_Project : defines type and enumerated
constants. Each project may have different values for the properties therefore they can be modified by the user
47
Examplesystem system1 end system1; system system1.impl subcomponents p1: process1.impl; p2: process2.impl; connections cn: data port p1.outport -> p2.inport; end system1.impl; process process1 features outport: out data port; end process1; process process1.impl subcomponents t1: thread1.impl; connections cn: data port t1.outport -> outport; end process1.impl;
process process2 features inport: in data port; end process2; process process2.impl subcomponents t2: thread2.impl; connections cn: data port inport -> t2.inport;end process2.impl;
thread thread1 features outport: out data port;end thread1;
thread thread1.implend thread1.impl;
thread thread2 features inport: in data port;end thread2;
thread thread2.implend thread2.impl;
48 Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
Example
49 Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
Example
50
Binding Example
Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)
52
Data Stream Latency Analysis
Potential hazard
Latency calculation & jitter accumulation
Flow specifications in AADL Properties on flows: expected & actual end-to-end
latency Properties on ports: expected incoming & end latency
End-to-end latency contributors Delayed connections result in sampling latency Immediate periodic & aperiodic sequences result in
cumulative execution time latency Phase delay shift & oscillation
Noticeable at flow merge points Variation interpreted as noisy signal to controller Analyzable in AADL
Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee)
and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)
53
Fault Handling
No exception handling in the application language
Unrecoverable threads dealt as error event
AADL provides a fault handling framework
Support for runtime changes to task and communication configurations
54
Summary of AADL AADL abstractions enable application architecture concerns
to be handled before runtime architecture AADL works well for real-time, embedded, fault-tolerant,
securely partitioned, and dynamically configurable systems AADL supports predictable system integration and
deployment through model-based system engineering Model-based systems engineering provides predictable
runtime characteristics early and throughout the lifecycle of the system, which greatly reduces integration and maintenance efforts
AADL is standardized, which provide confidence to developers that it is a stable language, has common semantic and syntactic definitions, a broad adoption, and strong tool support
Tool-Support for Performance (e.g., Throughput, Quality of Service) Safety Reliability Time Critical Security Schedulability Fault Tolerance
55
Conclusion
More Information on aadl.info What I didn’t talk about
Tool support Support for UML Support for XML Open Source tool environment
56
References
http://aadl.info/ www.laas.fr/FERIA/SVF/WADL04/slides/CONC
ORDE2-27-0900-LEWIS/AADLtutorial.ppt PowerPoint presentation by Bruce Lewis
“Overview of AADL Syntax” by Jean-Pierre Rosen at aadl.info
“AADL Concepts” by Bruce Lewis at aadl.info “AADL for Analysis” by Peter Feiler at aadl.info