1. The Emerging SAE AADL Standard: An Architecture Analysis & Design Language for Building Embedded
Real-Time Systems
Society of Automotive Engineers
Avionic Systems Division
Embedded Computing Systems Committee
AS-2C Avionics Architecture Description Language Subcommittee
Software Engineering Institute
Embry-Riddle Aeronautical University

2. Welcome Peter Feiler Bruce Lewis Secretary & Technical Co-editor
Chair, SAE AS-2C Subcommittee
Army AMCOM SED
Peter Feiler
Secretary & Technical Co-editor
Software Engineering Institute
Dave Gluch
Embry-Riddle Aeronautical University &
Software Engineering Institute
John Hudak
Software Engineering Institute
This introduces us and provides contact information for further inquiries.
AADL Tutorial

3. Architecture Analysis & Design Language (AADL)
Specification of computer systems and SoS.
Real-time
Embedded
Fault-tolerant
Securely partitioned
Dynamically configurable
Software task and communication architectures
Component interface and structure, behavior, properties
Bound to
Distributed multiple processor, integrated hardware architectures
Fields of application
Avionics, Automotive, Aerospace, Autonomous systems, …
Context and vocabulary for the integration of System Eng Technology
Capture of Architecture (& driving requirements), Analysis of Integration Impact (through model checking), Automated Integration to specification.
Architecture language with precisely defined semantics for execution under real-time conditions on explicitly modeled distributed execution platform.
Formerly called the Avionics ADL, it is applicable to any performance-critical system such as embedded real-time systems.
AADL Tutorial

4. Typical Software Development Process
Key points (Objectives of the Slide):
Presentation Script:
This defines how things are done today. Sequential (very little iteration); Distinct phases with idiosyncratic (methods, techniques, and notations); manual code development; large scale at the end integration.
Requirements Analysis
Design
Implementation
Integration
manual, paper intensive, error prone, resistant to change
AADL Tutorial

5. Model-Based System Engineering
Model-Based & Architecture-Driven
Requirements
Analysis
System Integration
Key points (Objectives of the Slide):
what is model-based development (process and activities) Analyzable representations (generally some level of formalized models) are the central design representation.
Also known as Model-Driven Architecture by OMG
Slide Content Description:
Presentation Script:
Key points embodied in model-based, architecture-driven development
Design is the principal development activity
Implementation is completely or greatly facilitated by automated translation from design models to implementation (automatic code generation).
Model-based, architecture driven development
analyzable models provide the foundation for the approach
MBD and AADL Advantages and Potential Benefits
Identify the values – potential benefits and cost savings associated with the approach
Explicit Architecture
M. Engineering Models
Use of AADL
Predictable System
Rapid Integration
Upgradeability
Design, Analysis and Implementation
AADL Tutorial

6. Lifecycle Impact
Requirements that impact computer software and hardware architecture modeled early with partial data
System specification refined during design, coding and integration to final system – each change modeled / model checked against multiple analysis approaches.
Specification is used to integrate system, generating middleware to control system execution and communication, generation is done in compliance with the formal analysis on RT O/S
Specification used throughout the development process – not out of date so always ready for the next system evolution and additional analysis capability.
AADL Tutorial

7. AADL-Based System Engineering
System Analysis
Schedulability
Performance
Reliability
Fault Tolerance
Dynamic Configurability
System Construction
AADL Runtime System
Application Software Integration
Software
System
Engineer
SAE AADL
Model the Architecture
Abstract, but Precise
Automatic
Target
Recognition
Application
Software
Execution
Platform
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
We use the term software systems engineering to refer to the person responsible for the systems architecture of the software system. In the slide titles and the rest of the presentation we use the term systems engineer for short. Key to a AADL-based engineering process is an architectural specification that is an abstraction of the system. The architectural specification must be semantically strong enough to reflect relevant aspects of the application domain. In our context it must reflect the fact that we are dealing with embedded real-time systems. Thus, the architectural specification focuses on the task structure and interaction topology of a system and captures both the software architecture and hardware architecture. This real-time architecture model is the basis for various analyses, ranging from schedulability analysis to reliability and safety analysis.In addition, the architectural specification is the basis for automated system generation and component integration. The actual components of a system may be hand-coded software, or components modeled in a domain-specific notation and auto-generated.
Guidance
& Control
Supply
Chain
Mechanized
Application Developer
GPS DB
HTTPS
Ada Runtime
Information
Fusion
Sensor
& Signal
Processing
Ambulatory
Devices
Memory
Bus
Processor
AADL Tutorial

8. Largest Provider of Avionics Standards
An SAE Standard
Sponsored by
Society of Automotive Engineers (SAE)
Avionics Systems Division (ASD)
Embedded Systems (AS2)
Avionics Architecture Description Language Subcommittee (AS2C)
Contact
Bruce Lewis AS2C chair,
For Information to
Balloted April 2004, expecting Core standard July.
Largest Provider of Avionics Standards
Largest provider, user group at the web site.
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
AADL Tutorial

9. AS-2C ADL Subcommittee Bruce Lewis (AMCOM): Chair, technology user
Peter Feiler (SEI): Secretary, main author, editor, technology user
Steve Vestal (Honeywell): MetaH originator, co-author
Ed Colbert (USC): AADL & UML Mapping
Joyce Tokar (Pyrrhus Software): Ada & C Annex
Members
Boeing, Rockwell, Honeywell, Lockheed Martin, Raytheon, Smith Industries, Airbus, Axlog, Dassault, EADS , Canadair, High Integrity Systems
NAVAir, Open Systems JTF, British MOD, US Army
European Space Agency
Coordination with
NATO, COTRE, OMG-UML
Key players:
Bruce Lewis has co-funded with DARPA and used the base technology (MetaH) since 1990.
Strong interest in Europe. A tutorial and coordination meeting in Sept 2002 drew 80 participants.
The last standard subcommittee meeting in Nashville (Oct 2003) was attended by ~30 participants, 10 from Europe.
AADL Tutorial

10. Priority Processing Systems interested in immediate use
Common Missile (August)
- Eglin AFB Weapons Integration (Toolset SBIRs)
Navy version of BlackHawk (possibly starting training in June with pre-standard toolset)
European Space Agency (expected Fall 2004)
Airbus (prototype tool building started)
FCS and 7E7 (probably too late now but the sooner the better)
Plug and Play (GD Immediate)
SEI Toolset development (started)
TNI Toolset development (started)
UML/OMG RFC – waiting, need to submit ASAP
AADL Tutorial

11. MetaH Case Study at AMCOM
Missile Application reengineered
Missile on-board software and 6DOF environment simulation executing on dual i80960MC, Tartan Ada, VME Boards
Built to Generic Missile Reference Architecture
Specified in MetaH, 12 to 16 concurrent processes
MetaH reduced total re-engineering cost 40% on first project it was used on. Missile prime estimated savings at 66%.
Missile Application ported to a new execution environment
multiple ports to single and dual processor implementations
new processors (Pentium and PowerPC), compilers, O/S
first time executable, flew correctly on each target environment
ports took a few weeks rather than 10 months.
AADL Tutorial

12. AMCOM Effort Saved Using MetaH
Total project savings 50%, re-target savings 90%
8000
Benefit During Platform Retarget
7000
6000
Benefit During Application Rewrite
5000
Man Hours
4000
3000
Traditional
2000
Approach
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
This illustrates the porting of a missile guidance system from Jovial into Ada with a 20 task implementation. The traditional approach represents a basic port into Ada, while the MetaH approach represents use of MetaH to model the runtime system architecture. This led to early timing and performance analysis and corrections in the architecture. The benefit showed when it came to system integration.
In a second phase the Ada implemented system was ported from a single processor platform to a dual processor platform. This retargeting effort (shown as last step in the chart) in case of MetaH involved reconfiguration by changing some properties in the MetaH description and to operationalize platform to platform communication – at a cost savings of ~90% over the traditional porting effort.
1000
Using
MetaH
Review
3-DOF
Trans-
6-DOF
Current
RT-
late
Trans-
Test
MetaH
6DOF
form
RT-
6DOF
Build
Missile
Debug
Debug
Re-target
AADL Tutorial

13. Why AADL Architecture Analysis and Design Language
Concept - Applies systems engineering (analytical) approach to software intensive systems rather than brute force. Early analysis instead of late failure.
Needed – analyzable architecture =>key to sizable decrease in rework, integration and upgrade costs as well as program risk, complexity.
Enables – rapid system evolution for complex, RT, safety critical systems with cross cutting constraints, predictable change to both HW and SW components.
Open – Becoming a Standard, SAE, NATO, UML.
Readiness - 12 years of DARPA investment + experiments
Extendable – good foundation for additional capabilities in analysis, automated system integration, system of systems, distribution, dynamics.
AADL Tutorial

14. An XML-Based AADL Tool Strategy
Graphical
AADL
Textual
AADL
AADL Model
XML
Complete Execution
Platform Binding
AADL Instance
XML
Scheduling
Analysis
AADL Runtime
Generator
Peter, you say we are “trying to” too often.
You can add your internal analysis to commerical toolsets via the XML
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
The tool strategy has two aspects.
First, the standard includes an XML schema definition of AADL models.
The XML provides a common interchange format for AADL models between front-end tools and various backend analysis and generation tools.
Second, the Software Engineering Institute is making available an open source Common AADL Front-end built as a set of extensions to the Open Source Eclipse environment. This provides a platform independent environment with a common user interaction framework and team suport.
Reliability
Analysis
Safety
Analysis
Commercial
Tool like
TimeWiz
Project-Specific
In-House
Filter to Markov
Analysis
AADL Tutorial

15. An Open Source AADL Environment
Java
Development
Tools
(JDT)
Eclipse Platform
Help
Standalone
Generation
Tool
Workbench
JFace
Team
SWT
Debug
Plug-in
Development
Environment
(PDE)
Workspace
Analysis
Tool
Via Java
Platform Runtime
You can build your own standalone toolset and just use the help facility, can use several types of model desciption, xml, or java expression.
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
The Open Source Eclipse framework supports tight integration of tools in form of plug-ins as well as loose integration of standalone tools with data interchange via the file system. A core set of AADL-specific plug-ins are being provided open source from the SEI.
This slide illustrates different AADL specific analysis capabilities as plug-ins to an Eclipse-based AADL environment.
They can be provided by leveraging & interfacing commercial tools (TimeWiz example),
Translation into a different model representation to be fed into a tool (Reliability analysis via Markov models),
Or they can be specialized project specific analysis capabilities that may be developed in-house.
Analysis
Tool
Via XML
Eclipse Environment
AADL
Textual
Editor
AADL
Parser
AADL
Graphical
Editor
AADL
Object
API
XML
Document
Persistence
AADL Environment
AADL Tutorial

16. Some MetaH History MetaH - Precursor 1991 DARPA DSSA program begins
to AADL
1991 DARPA DSSA program begins
1992 Partitioned PFP target (Tartan MAR/i960MC)
1994 Multi-processor target (VME i960MC)
1995 Slack stealing scheduler
1998 Portable Ada 95 and POSIX middleware configurations
1999 Hybrid automata verification of core middleware modules
Numerous evaluation and demonstration projects, e.g.
Missile G&C reference architecture, demos, others (AMCOM SED)
Hybrid automata formal verification (AFOSR, Honeywell)
Missile defense (Boeing)
Fighter guidance SW fault tolerance (DARPA, CMU, Lockheed-Martin)
Incremental Upgrade of Legacy Systems (AFRL, Boeing, Honeywell)
Comanche study (AMCOM, Comanche PO, Boeing, Honeywell)
Tactical Mobile Robotics (DARPA, Honeywell, Georgia Tech)
Advanced Intercept Technology CWE (BMDO, MaxTech)
Adaptive Computer Systems (DARPA, Honeywell)
Avionics System Performance Management (AFRL, Honeywell)
Ada Software Integrated Development/Verification (AFRL, Honeywell)
FMS reference architecture (Honeywell)
JSF vehicle control (Honeywell)
IFMU reengineering (Honeywell)
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
The roots of the AADL are in MetaH an architecture description language and toolset for embedded real-time systems.
In the process of developing the AADL standard improvements were made to the language to accommodate extensibility and evolutionary development of system architectures.
The MetaH experience provided the confidence for turning the AADL into a success.
AADL Tutorial

17. DARPA Funded Research since 1990
AADL in Context
DARPA Funded Research since 1990
Research ADLs
MetaH
Real-time, modal, system family
Analysis & generation
RMA based scheduling
Rapide, Wright, ..
Behavioral validation
ADL Interchange
ACME, xADL
ADML (MCC/Open Group, TOGAF)
Industrial Strength
UML 2.0, UML-RT
HOOD/STOOD
SDL
Basis
AADL
Extensible
Real-time
Dependable
Extension
Influence
Alignment
The AADL was based on the MetaH language as its starting point but was influenced by a number of Architecture Description Languages developed by DARPA. MetaH provided …. Rapide and Wright both had different competing approaches to internal component behavior modeling which has caused us to leave this level of behavior modeling out of the core, leaving it open to annex extension. ACME component modeling influenced the common component description in chapter four to make component type and implementation more regular as well as provided a model for extension. xADL and ADML are both ACME with XML definitions, which influenced us to use XML/XMI as a toolset integration mechanism.
The architectural specification with integrated modeling tools and automated system generation is key to rapidly developing and evolving real-time systems.
It provides the framework for continuous system level analysis from various perspectives such as schedulability, throughput, reliability, safety.
Automation of the process of component generation, and automatic generation of executive code that reflects the intricacies of a real-time system task and communication architecture eliminate human errors introduced through manual translation. By validating these component and architectural models and the translation process the quality of the resulting is improved.
Given such a framework in place, changes can be made quite effectively. The trick is separation of concerns.
The architectural model focuses on information relating to the real-time task and communication architecture. It supports accommodation of specialized hardware. The structure of the run-time architecture into which the auto generation occurs supports portability to different hardware platforms.
The mechanisms for integrating components into this architecture simplify the upgrade of components and reduce their impact on the rest of the system.
Enhancement
Airbus & ESA
AADL Tutorial

18. AADL/UML Relationship
To Be submitted to OMG for Adoption
Extensible AADL Annexes
UML Working Groups
AADL
Core
UML 2.0
AADL
UML Profile
UML 1.4
Detailed design
Security
UML-RT
Performance
Timeliness
SYSML – describes relationships of physical systems that include wheels to axles, AADL relates to computer hardware and software, the physical part of the computer system.
The AADL provides a richer set of semantics and greater runtime architecture analysis and binding capability than UML. It was designed from the beginning to support precise architectural modeling and system building. UML 2.0 was modeled on ACME which is a metaADL, for describing other ADLs and translating between them. For instance, you can describe in ACME the AADL. Our UML profile is a description of the AADL in UML 2.0 and So the UML 2.0 approach is a level of abstraction higher, the AADL provides a profile that is specifically designed as a ADL for real-time performance critical systems. UML 1.4 was not designed as an ADL and had poor support, UML 2.0 was designed for Model Based Development but again at a higher level, more generalized approach. As UML has special working groups to extend it in Security and Dependability, so also the AADL and its UML profile will be extended or will leverage the analysis provided by UML. By providing a UML profile, UML modelers will gain the domain specific advantage of a langauge designed to capture, analyse and integrate rt performance critical architecture and the specialized toolsets to analyse architecture.. The AADL will gain a broad base of potential toolsets based on the profile and interested users.
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
During the development process the AADL has been strategically aligned with UML in order to be of interest to the practiioner community that has embraced UML as their design notation and methodology.
This is achieved through the development of a UML profile of the AADL.
The chart illustrates the overlap in capabilities.
Dependability
AADL Tutorial

19. What Is Involved In Using The AADL?
Specify software & hardware system architectures
Specify component interfaces and implementation properties
Analyze system timing, reliability, partition isolation
Tool-supported software and system integration
Verify source code compliance & middleware behavior
Key points (Objectives of the Slide):
Convey the essential characteristics of the AADL.
Slide Content Description:
Specify software + hardware system architectures
Specify component interfaces and implementation properties
Analyze system timing, reliability, partition isolation
Tool-supported software and system integration
Verify source code compliance, middleware behavior
Presentation Script:
We provide an overview of the capabilities of the AADL in the context of a representative real-world system. In the tutorial we describe the design of an existing avionics system; create an AADL representation of it; and define and analyze alternative design choices for the system. In particular, we demonstrate the value of the AADL in model-based, architecture-driven systems (software) engineering (MBSE) practices.
Model and analyze early and throughout product life cycle
AADL Tutorial

20. A Control Engineer PerspectiveK1
K2s + -
Tune parameters
Continuous
feedback
in a controller
Simulink
Component Analysis
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
Matlab
Application Code
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
As controllers operate with continuous feedback, control engineers continuously refine their control models through feedback from simulation runs and from execution of actual software on actual hardware.
Validate simulation
Continuous feedback for
a control engineer
AADL Tutorial

21. A Software System Engineer Perspective
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
Application
Components
Continuous feedback for
software system engineer
Execution
Platform
AADL Tools
package Dispatcher is
A.p1 := B.p2;
Case 10ms:
dispatch(a);
dispatch(b);
AADL Runtime
Runtime
Data
Timing analysis
T1 T2 T3 T4
R1 R2 R3 R4
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
The same applies to a software system engineer. Early and throughout the development life cycle the architecture models can a analyzed and refined as appropriate, identifying shortcomings in non-functional (para-functional) properties such as timing, reliability, responsiveness well before system integration time.
Reliability analysis
T1 T2 T3 T4
R1 R2 R3 R4
T1 T2 T3 T4
Refine properties
AADL-based
Architecture Model
AADL Tutorial

22. A Combined PerspectiveK1
K2s + -
Tune parameters
Simulink
Component Analysis
Matlab
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
with Text_IO;
package Main is
begin
type real is digits 14;
type flag is boolean;
x : real := 0.0;
ready : flag := TRUE;
Application Code
Continuous interaction
between
Control engineer
& system engineer
AADL Tools
AADL Runtime
package Dispatcher is
A.p1 := B.p2;
Case 10ms:
dispatch(a);
dispatch(b);
T1 T2 T3 T4
Timing analysis
Reliability analysis
R1 R2 R3 R4
Runtime
Data
Refine properties
Validate simulation
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
Application developers of control systems develop models run analyses and simulations to refine model parameters to meet their expectations.
They also generate application code and validate it against the model results.
The same way software systems engineers analyze their architecture models, generate implementations, and execute them.
Runtime data regarding timing, faults, etc. are reported back to compare against analysis results and to refine architecture component properties.
AADL-based
Architecture Models
AADL Tutorial

23. Application Components as Plug-ins
Application Software
Component
Application Software
Component
Application Software
Component
Application Software
Component
AADL Runtime System
Real-Time Operating System
Embedded Hardware Target
We should talk about a very simple interface to the underlying real time system.
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
Key to successful embedded systems is a layered runtime architecture that supports partitioning.
The major driver for partitioning is the dramatic reduction in initial and upgrade V&V effort that can be achieved. You only need to re-verify and re-validate partitions that have changed or depend on partitions that have changed; and then only to the level of criticality needed for a particular partition. Partitioning methods have been fielded and their use is spreading rapidly for civil aviation, the use of partitioning methods to reduce certification effort is recognized in DO-178B and several ARINC standards and by the FAA and JAA.
The real-time OS, against which the runtime executive is generated, is assumed to provide runtime enforcement of address space protection and timing enforcement as appropriate and necessary.
The layer runtime architecture facilitates interoperability and portability. The runtime executive is generated against a common real-time OS and communication API. It takes advantage of efficient local communication schemes such as communication by shared buffers where appropriate. Different real-time OS can be accommodated on different platforms within the same system. Application components are portable as they contain only application functionality and are plugged into a generated runtime executive that implements a standardized task and communication framework. The runtime executive is portable as it is generated against an established set of OS functionality such as POSIX, allowing for variation in platform real-time OS implementations.
Strong Partitioning
Timing Protection
OS Call Restrictions
Memory Protection
Interoperability/Portability
Tailored Runtime Executive
Standard RTOS API
Application Components
AADL Tutorial

24. Predictable System Integration
Required, predicted, and actual runtime properties
Application components designed against functional and non-functional properties
Application code separated from task dispatch & communication code
Consistency between task & communication model and implementation through generation
Feedback into model parameters: refinement of estimated performance values
A review slide, did not spend much time on except for first bullet.
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
Requirements expressed as properties, initial predictions by engineers, and actual numbers as prototypes are developed and the implementation proceeds.
Properties are recorded as part of the AADL model specification. Components can be developed against these functional and para-functional properties.
Application component code does not include tasking & communication service calls, making it reusable under a variety of task & communications configurations.
Through a runtime system generation approach otherwise hand-coded service calls to task dispatching and message communication do not have to be validated. Focus is on validating the generator itself.
AADL Tutorial

25. Airbus ESA Rockwell Collins Lockheed Martin Smith Industries Raytheon
Potential Users
New System Engineering Approach based on AADL
Airbus
ESA
Rockwell Collins
Lockheed Martin
Smith Industries
Raytheon
Boeing FCS
Automotive OEPs
Common Missile
RT Plug and Play
Modeling of Satellite Systems, proposed ASSERT with AADL
Modeling of Helicopter Avionics Software System
New System Engineering tools using AADL.
Leading Candidate for system of systems modeling, analysis
Adopted for system integration analysis to support standard
AADL Tutorial

26. AADL Components - Graphical
Application Software
Execution Platform
data A
ADL
device
process
Thread
memory
bus
The next slides use the graphical notation for the AADL components shown here. Additional graphical detail is also added on the following of the slides for connections, bindings, ports, etc. These are the component categories.
The modeling vocabulary of AADL supports modeling of the application systems executing on executing platform with focus on runtime properties of the embedded system.
Application systems can be modeled in terms of concurrently executing components that interact and access data. These components have precise execution semantics. They can be composed into hierarchical systems.
The execution platform consists of processors (for executing threads), memory (for holding code and data), buses, to provide connectivity of execution platform components, and devices to interface with the external environment.
System Composition
System A
ADL
processor
AADL Tutorial

27. Modeling Vocabulary Execution Platform Extension Application System
Thread
Thread Group
Process
System
Package
Subprogram
Data (shared/message)
Data Port
Event
Event Port
Event Data Port
Connection
Mode
Execution Platform
Processor
Memory
Device
Bus
System
Extension
Inheritance
Properties
Sublanguages (safety, flow, user defined, … component behavior ….)
Domain Specific Annexes
AADL Tutorial

28. Graphical & Textual Notation
system Data_Acquisition
provides
speed_data: in data metric_speed;
GPS_data: in data position_carthesian;
user_input_data: in data user_input;
s_control_data:out data state_control;
end Data_Acquisition;
data port
data type of port
speed
_data
user
input
data
GPS
Data_Acquisition
s_control_data
AADL provides both textual and graphical notations.
The notation is strongly typed and supports consistency checking between components and their interconnections.
data port
AADL Tutorial

29. AADL Component Interaction
1553
Unidirectional data & event flow
Synchronous call/return
Managed shared data access A
ADL
Flight Mgr
data A
ADL
Weapons Mgr A
ADL
MFD Pilot
AADL provides for different forms of components interactions with precisely defined interaction semantics A
ADL
Warnings
Annunciations A
ADL
MFD Copilot
AADL Tutorial

30. Application System & Execution Platform
ADL
1553
Application system binding to execution platform A
ADL
Weapons Mgr A
ADL
Flight Mgr A
ADL
MFD Pilot A
ADL
Warnings
Annunciations
data A
ADL
MFD Copilot
The AADL addresses runtime quality attributes key to embedded systems such as performance, timing, reliability.
To support such analyses it provides for representation of both the application system and the execution platform and the binding of one to the other.
High speed network
Mission
Processor
Display
Processor
Display
Processor
Pilot Display
CoPilot Display
1553 bus
AADL Tutorial

31. Thread Properties Dispatch_Protocol => Periodic;
Period => 100 ms;
Compute_Deadline => Period;
Compute_Execution_Time => 20 ms;
Initialize_Deadline => 10 ms;
Initialize_Execution_Time => 1 ms;
Compute_Entrypoint => “Calculate_Trajectory”;
Source_Text => “waypoint.java”;
Source_Code_Size => 1.2 KB;
Source_Data_Size => .5 KB;
Dispatch execution properties
Code function to be executed on dispatch
Properties related to the execution, storage of related code and data in memory.
File containing the application code
AADL Tutorial

32. Thread Hybrid Automata
The standard itslef documents the thread, process, and system states using a hybrid automata notation to provide precise timing semantics.
AADL Tutorial

33. Task & Interaction Architecture
Thread Dispatch Protocols
Periodic
Aperiodic
Sporatic
Background
Client - Server
System System1
Typed and constrained data streams
Immediate and delayed communication
System Subsystem1
Process Prc1
Data1:
Pos
Data1:
Pos
Process Prc2 E1
Shared data
Thread T3
Data1:
Pos
Thread T1
Data1
Server Thread T2 E1
SP1
Thread T1
Thread T2
RSP1
SP2
Subprogr E1
SP3
Directional
Data, event, message ports
Queued and unqueued xfer
Call/Return
Local subprogram
Client/server subprogram
Shared Access
Persistent, shareable data
Access coordination
AADL Tutorial

34. Application Source Entrypoints
Thread States
Uninitialized
Thread
Initialize
Active
Member of current mode
InitializeComplete:
InactiveInInitMode:
Initialized Thread
ActiveInInitMode:
Inactive
Not member of current mode
Activate
ActivateComplete:
Active
ActiveIn
NewMode:
Dispatch:
Suspended
Inactive
Complete:
Compute
Recovered:
Repaired:
Fault:
Recover
DeactivateComplete:
Deactivate
InactiveInNewMode:
Terminate:
Thread State
Thread State with Source Code Execution
Finalize
Terminated Thread
FinalizeComplete:
Application Source Entrypoints
Application as Plug-in
AADL Tutorial

35. Mode as Alternative Configuration Application Source Internal Mode
Hierarchical Modes
System System1
Mode as Alternative Configuration
System Subsystem1 E1 A
Initial Mode A: Prc1, Prc2;
Mode B: Prc1, Prc3;
Process Prc3
Process Prc1
Initial Mode A: T1, T2, T3;
Mode B: T1, T2; E1 A
Data1:
Pos
Process Prc2
Shared data
Data1:
Pos E1
Thread T3
Data1:
Pos
Thread T1
Data1
Server Thread T2 E1
SP1
Thread T1
Subprog
Thread T2
RSP1
SP2 E1 A E1
SP3
Application Source Internal Mode
Conditional code
AADL Tutorial

36. Systems & Execution Platforms
Processors, buses, memory, and devices as Virtual Machines
System System1
System LinuxNet
System Subsystem1
System LinuxBox
Memory
Process Prc1
Process Prc2
Processor PC1
Bus
Thread T3
Thread T3
Memory
Processor PC2
Threads as logical unit of concurrency
AADL Tutorial

37. AADL and Scheduling
AADL provides precise dispatch & communication semantics via hybrid automata
AADL task & communication abstraction does not prescribe scheduling protocols
Cyclic executive can be supported
Specific scheduling protocols may require additional properties
Predefined properties support rate-monotonic fixed priority preemptive scheduling
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
AADL provides a precise specification of execution characteristics of threads and processes. At the same time it does not prescribe a particular scheduling protocol.
This scheduling protocol is analyzable, requires small runtime footprint, provides flexible runtime architecture
AADL Tutorial

38. Faults and Modes
AADL provides a fault handling framework with precisely defined actions
AADL supports runtime changes to task & communication configurations
AADL defines timing semantics for task coordination on mode switching
AADL supports specification of mode transition actions
System initialization & termination are explicitly modeled
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
AADL Tutorial

39. Protocol verification
Behavior Modeling
Operational modes (in core AADL)
Runtime reconfiguration (in core AADL)
End-to-end flows (in core AADL)
Interaction behavior (extension)
Port interaction pattern of component
Interaction protocol of connection
Error models & reliability analysis (extension)
State reachability
Flow traceability
Protocol verification
Model checking
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
The AADL core has several concepts to characterize behavior in a system.
They include modeling of operational modes, dynamic reconfiguration, end-to-end flows.
Additional behavioral modeling capabilities can be added to address a range of behavioral analyses that are not addressed by the core language.
AADL Tutorial

40. System Safety Engineering
Capture the results of
hazard analysis
component failure modes & effects analysis
Specify and analyze
fault trees
Markov models
partition isolation/event independence
Integration of system safety with architectural design
enables cross-checking between models
insures safety models and design architecture are consistent
reduces specification and verification effort
Supported by Error Model Annex
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
An Error Model Annex has been included in the initial standard for several reasons:
To illustrate the capability to extend the Core AADL to support additional analysis approaches
To provide a basis for reliability analysis for both hardware and software – a key characteristic of embedded systems.
To demonstrate the ability to integrate with established analysis methods
AADL Tutorial

41. AADL Version 2 Research Ideas
1. Dynamic Reconfigurable Real-Time Fault-Tolerant Asynchronous Architectures
2. Additional trackable automated modeling and analysis methods for architectural specs (composition, pattern recognition to reduce state space)
3. Rigorous links/relations between multiple engineering modeling approaches – Simulink/VHDL – AADL, SDL – AADL, compositional scheduling
4. Architectural verification -(is the Architecture spec correct and do components comply with their specs, stronger plug and play )
5. Mode transition modeling, state space reduction for mode analysis/scheduling
6. Modeling of specific system building approaches/patterns – example RT CORBA that can be applied as abstractions at a higher level but used to generate an implementation.
7. Modeling sublanguages and properties to support special areas of analysis for high integrity systems – Current Error modeling annex, safety and security annex, component behavior annex etc.
AADL Tutorial

42. AADL Status Requirements document SAE ARD 5296
Input from aerospace industry
Balloted and approved in 2000
SAE AADL document SAE AS 5506
Core language: In ballot April 2004, July availability
UML profile, XML schema, Error Model Annex, Ada and C Annex in review, to be balloted in June 2004
Key points (Objectives of the Slide):
Slide Content Description:
Presentation Script:
AADL Tutorial