Blog

Julien Delange and I will give a tutorial on AADLv2 at MODELS Conference, scheduled on September 28, 2015.

See the following link for more details MODELS’15 site, and of course register.

Tutorial materials are at the end of the page

Abstract

The Architecture Analysis and Design Language (AADL) is an SAE International Standard dedicated to the precise modeling of complex real-time embedded systems, covering both hardware and software concerns. Its definition relies on a precise set of concepts inherited from industry and academics best practice: clear separation of concerns among layers, rich set of properties to document system metrics and support for many kind of analysis: scheduling, safety and reliability, performance, but also code generation. In this tutorial, we provide an overview of AADLv2 and illustrate how several analyses can be combined on an illustrative example: an ADIRU system. In this tutorial, we focus on safety analyses and also demonstrate the use of AADL to both verify and implement automatically a real-time embedded systems.

Materials

• Part 0: Outline
• Part 1: Introduction to AADL
• Part 2: Case Study
• Part 3: ARINC653, Data and Code generation annexes
• Part 4: Complexity analysis
• Part 5: Safety Analysis
• Part 5: Conclusion

The SEI blog has a series of post on AADL. Joint research activites on leveraging Ocarina code generation facilities targetting ARINC653 APEX got featured in the post “AADL Code Generation for Avionics Systems”. See the following link for more details: SEI blog post

Ocarina licence has been update to GPLv3 plus runtime exception. This update retains the principle of the GMGPL, while being more readable to partners.

Ocarina is part of the TASTE project since its inspection http://taste.tuxfamily.org/. The project helped defining first its Ada runtime, then its C variant.

As part of the SOCIS initiative, we propose the following projects:

• Performance analysis of the PolyORB-HI/C runtime. The objective is to propose relevant benchmarks to exercise the runtime, in particular memory footprint, performance, useless copies of data, etc.

• Code quality review of the PolyORB-HI/C runtime. Apply code quality analysis tool to detect dangerous conditions (inconsistent usage of pointers) or bad quality style.

• Provide improvements in the general architecture of the PolyORB-HI/C runtime to ease the support of new Operating System, without neglecting code quality.

These projects require advanced knowledge in C and RTOS, and the will to learn AADL, the core of the TASTE toolchain.

If you are interested in participating as a student, please contact: hugues ( dot ) jerome ( at ) gmail ( dot ) com

Ocarina’s documentation is now hosted on readthedocs.org, see http://ocarina.readthedocs.org/ for details.

The SEI blog has a series of post on AADL. Joint research activites on leveraging both SPARK2014 and AADL got featured in the post “Code Generation with AADL: A State-of-the-Art Report”, see the following link for more details: SEI blog post

Frank Singhoff and I will give a tutorial on AADLv2 at MODELS Conference, scheduled on September 28, 2014.

See the following link for more details MODELS’14 site, and of course register.

NEW Tutorial materials are at the end of the page

Abstract

The Architecture Analysis and Design Language (AADL) is an SAE International Standard dedicated to the precise modeling of complex real - time embedded systems, covering both hardware and software concerns. Its definition relies on a precise set of concepts inherited from industry and academics best practices: clear separation of concerns among layers, rich set of properties to docu-ment system metrics and support for many kind of analysis: scheduling, safety and reliability, perfor-mance, but also code generation.

In this tutorial, we provide an overview of AADLv2 and illustrate how several analyses can be combi-ned on an illustrative example: a radar platform. In this tutorial, we also present Model-based engi-neering process allowed by AADL to both verify and implement automatically areal-time embedded system.

The tutorial will be composed of four parts.

Part 1 will be an introduction to AADLv2 core. In this part we will present the syntax and semantics of the AADL.

Part 2 will introduce the radar case study to illustrate the use of AADL.

Part 3 will address scheduling analysis. We will introduce real-time scheduling theory and who it can be used to access schedulability of AADL models.Finally,

Part 4 will be dedicated to code generation. We will present how to generate code from an AADL model and how it can be run

Materials NEW

• Part 0: Outline
• Part 1: Introduction to AADL
• Part 2: Case Study
• Part 3: Scheduling Analysis
• Part 4: Code generation
• Part 5: Conclusion

The SEI blog has a series of post on AADL. Some of the teaching activites at ISAE using AADL got featured in the post “Architecture Analysis Using AADL: A Beginner’s Perspective”, see the following link for more details: SEI blog post

Nightly builds for Windows and OS X are now available, see the Downloads area for more details.

Ocarina now uses Sphinx as rendering engine for documentation, see doc for the new look.

Frank Singhoff and I will give a tutorial on AADLv2 at Embedded System Week 2013 in Montreal, scheduled on September 29, 2013.

See the following link for more details ESWeek Web site, and of course register.

NEW Tutorial materials are at the end of the page

Abstract

The Architecture Analysis and Design Language (AADL) is an SAE International Standard dedicated to the precise modeling of complex embedded systems, covering both hardware and software concerns. Its definition relies on a precise set of concepts inherited from industry and academics best practice: clear separation of concerns among layers, rich set of properties to document system metrics and support for many kind of analysis: scheduling, safety and reliability, performance, but also code generation.

In this tutorial, we will provide an overview of AADLv2 and illustrate how several analyses can be combined on an illustrative example: a radar platform.

The tutorial will illustrate the two key dimensions of AADL:

1. a modeling process, following a system engineering approach: elicitation of high-level requirements and corresponding architecture, refinements and then full implementation,

2. connection with various analysis down and up the traditional engineering V-cycle.

The tutorial will cover both language and state-of-the-art tools: OSATE2, Cheddar and Ocarina and connections with other modeling frameworks and tools like Simulink, SCADE or OpenFTA.

We will illustrate how to merge various modeling and analysis concerns using AADL: validation of mission-level objectives, high-level system validation, verification of schedulability and reliability and then discuss alternatives to generate part of the system. Motivation for the tutorial

AADL is notation which is part of the model-based families, along with OMG SysML, MARTE or AutoSAR. It has been defined with a strong focus on analysis capabilities from its inception, while being versatile enough to be applied to a wide set of embedded systems. European projects (FP5-ASSERT, TASTE, Flex-eWare), but also US projects (SAVI, Meta) demonstrated that AADL could help engineers in their design effort in the space, avionics and embedded domains.

In the mean time, the academic community adopted AADL as a conveyor to bind numerous tools, covering model checking, scheduling, power evaluation or simulation capabilities to name a few. The AADL committee pages list more than 200 publications around AADL illustrating the variety of analysis being implemented.

The motivation of the tutorial is two-fold: 1) to underline the value of model-based as a viable solution to support design activities of embedded systems, but also 2) to illustrate how to extend AADL capabilities to meet specific project requirements.

List of topics to be covered

The tutorial will cover the following topics: 1. Introduction to the AADL, history and key concepts (1 hour) 2. Presentation of the case study, analysis challenges (30 minutes) 3. How to map AADL concepts onto an analysis domain, illustrations on a scheduling analysis (45 minutes) 4. From model to code: code generation strategies, connection with external behavioral models (Simulink) and code (45 minutes)

All topics will be illustrated through demonstration of tools; the models and the tools will be made available to participants and on author’s pages. Form of the tutorial

The tutorial will have the form of a lecture, with hand-outs and tools made available to participants. We will not ask participants to run the tools, but instead rely on interactive discussion while enriching the various models.

Materials NEW

• Part 0: Outline
• Part 1: Introduction to AADL
• Part 2: Case Study
• Part 3: Scheduling Analysis
• Part 4: Code generation
• Part 5: Conclusion

Note: updated on September 29 2013

About tool support

AADL, as a modeling language is backed by several analysis tools, we list some of them in this post.

OSATE2

OSATE2 is the reference implementation of AADLv2 done by the SEI. It support the core language, and can be completed with additional plug-ins to extend its modeling and analysis capabilities:

• OSATE 2 Validation plug-ins
• OSATE 2 ARINC653 framework
• Instance Model Viewer
• The Lute Constraint Language
• Error Model Annex V2

Tools integrated to OSATE2

Some tools are directly integrated as OSTE2 plug-ins

• Behavioral-Annex by Telecom-ParisTech
• RAMSES code generation by Telecom-ParisTech
• BLESS toolset

AADLInspector

AADL Inspector is a lightweight standalone model processing framework for AADL, see , with full customer support for industrial users

• Import of AADL textual specifications (individual files or projects)
• Syntactic analysis (aadlrev) for AADL v2.1 (AS-5506B), AADL Behavior Annex (AS-5506/2 Annex D + errata), AADL v1 and v2.0 upwards compatibility
• Static rules analysis
• Architectural metrics
• Schedulability analysis through CHEDDAR v3
• Dynamic simulation of AADL models, integration of the MARZIN Multi-Agents simulation engine
• Command line options for batch processing

Ocarina suite

Ocarina and its companion plug-ins and runtimes are also available in this web site, supporting:

• Parser: support both AADL1.0 and AADLv2 syntaxes;
• Code generation: targetting C real-time operating systems: RT-POSIX, Xenomai, RTEMS; and Ada using GNAT for native and Ravenscar targets;
• Model checking: mapping of AADL models onto Petri Nets, timed (TINA) or colored (CPN-AMI);
• Schedulability analysis: mapping of AADL models onto Cheddar or MAST models
• Model Analysis: using the REAL language, one can analyse an AADL model for particular patterns or compute metrics.

The SEI blog is introducing a series of post on AADL. Ocarina and related activities like ASSERT/TASTE gets featured in the post “AADL Tools: Leveraging the Ecosystem”, see the following link for more details: SEI blog post

A commented example

The following example is a complete AADLv2 model. It exhibits a full hierarchy of component types, and component implementations.

You’ll note we do not provide implementations for subprograms and threads: these are fully determined using properties.

AADL being a textual language, it follows many conventions from other languages: packages, declarations of types and implementations. Let us review the first set of elements:

--  This small example is a basic AADL model, with a full hierarchy of components

package Hello_World
  -- Entities are attached to a package

public

  subprogram Hello_Spg_1
    --  Simple subprogram: actual behavior, not modeled in AADL
  properties
    Source_Language => (C);                                  --  Implementation language is C
    Source_Name     => "user_hello_spg_1";                   --  Name of the corresponding C function
    Source_Text     => ("hello.c");                          --  Implementation file
  end Hello_Spg_1;

  thread Task
    --  A task: a concurrent flow of execution
  properties
    Priority                => 1;                            --  Priority, interpretation given by the processor
    Dispatch_Protocol       => Periodic;                     --  Periodic
    Period                  => 1000 ms;                      --  Period of the task
    Compute_Execution_Time  => 0 ms .. 3 ms;                 --  Execution time
    Compute_Entrypoint      => classifier (Hello_Spg_1);    --  Hello_Spg_1 is executed at each dispatch
  end Task;

  process node_a
    --  A process, gathers several threads as subcomponents
  end node_a;

  process implementation node_a.impl
  subcomponents
    Task1 : thread Task;
  end node_a.impl;

  processor cpu
    --  A processor provides execution resources
  properties
    Scheduling_Protocol => (RMS);                             -- How thread are given access to the CPU
  end cpu;

  system rma
     --  A system combines both hardware and software elements
  end rma;

  system implementation rma.impl
  subcomponents
    node_a : process node_a.impl;
    cpu	   : processor cpu;
  properties
    Actual_Processor_Binding                                  -- Binding relations between hardware and software
       => (reference (cpu)) applies to node_a;             -- node_a is allocated resources on cpu
  end rma.impl;

end Hello_World;
 

A new book covering SysML, UML/MARTE and AADL is available at Wiley, and Hermes (French Version).

This book presents how a common case study (Pacemaker specifications from the pacemaker challenge) can be modeled and analyzed using SysML, UML/MARTE and AADL. It is a joint effort of the french MDE community to compare the different approaches. For each formalism, we propose an introduction to the notation, and then how to model, analyze and generate code from these specifications. Analysis focuses on model checking of the system.

Hence, interested readers can build their own opinion on the value of each approach.

About AADLv2

The “Architecture Analysis and Design Language” AADL is a textual and graphical language for model-based engineering of embedded real-time systems. It has been published as an SAE Standard AS5506B. AADL is used to design and analyze the software and hardware architectures of embedded real-time systems.

AADL allows for the description of both software and hardware parts of a system. It focuses on the definition of clear block interfaces, and separates the implementations from these interfaces. It can be expressed using both a graphical and a textual syntax. From the description of these blocks, one can build an assembly of blocks that represent the full system. To take into account the multiple ways to connect components, the AADL defines different connection patterns: subcomponent, connection, and binding.

An AADL model can incorporate non-architectural elements: embedded or real-time characteristics of the components (such as execution time, memory footprint), behavioral descriptions. Hence it is possible to use AADL as a back- bone to describe all the aspects of a system. Let us review all these elements:

An AADL description is made of components. The AADL standard defines software components (data, thread, thread group, subprogram, process) and execution plat- form components (memory, bus, processor, device, virtual processor, virtual bus) and hybrid components (system). Each Component category describe well identified elements of the actual architecture, using the same vocabulary of system or software engineering:

• Subprograms model procedures like in C or Ada.

• Threads model the active part of an application (such as POSIX threads). AADL threads may have multiple operational modes. Each mode may describe a different behavior and property values for the thread.

• Processes are memory spaces that contain the threads. Thread groups are used to create a hierarchy among threads.

• Processors model microprocessors and a minimal operating system (mainly a scheduler).

• Memories model hard disks, RAMs, buses model all kinds of networks, wires, devices model sensors, … 


• Virtual bus and Virtual processor models “virtual” hardware components. A virtual bus is a communication channel on top of a physical bus (e.g. TCP/IP over Ethernet); a virtual processor denotes a dedicated scheduling domain inside a processor (e.g. an ARINC653 partition running on a processor).

Unlike other components, Systems do not represent anything concrete; they combine building blocks to help structure the description as a set of nested components.

Packages add the notion of namespaces to help structuring the models. Abstracts model partially defined components, to be refined during the modeling process.

Component declarations have to be instantiated into subcomponents of other components in order to model system architecture. At the top-level, a system contains all the component instances. Most components can have subcomponents, so that an AADL description is hierarchical. A complete AADL description must provide a top-most level system that will contain certain kind of components (processor, process, bus, device, abstract and memory), thus providing the root of the architecture tree. The architecture in itself is the instantiation of this system, which is called the root system.

The interface of a component is called component type. It provides features (e.g. communication ports). Components communicate one with another by connecting their features. To a given component type correspond zero or several implementations. Each of them describes the internals of the components: subcomponents, connections between those subcomponents, etc.

An implementation of a thread or a subprogram can specify call sequences to other subprograms, thus describing the execution flows in the architecture. Since there can be different implementations of a given component type, it is possible to select the actual components to put into the architecture, without having to change the other components, thus providing a convenient approach to configure applications.

The AADL defines the notion of properties that can be attached to most elements (components, connections, features, etc.). Properties are typed attributes that specify constraints or characteristics that apply to the elements of the architecture: clock frequency of a processor, execution time of a thread, bandwidth of a bus, . . . Some standard properties are defined, e.g. for timing aspects; but it is possible to define new properties for different analysis (e.g. to define particular security policies).

AADL is a language, with different representations. A textual representation provides a comprehensive view of all details of a system, and graphical if one want to hide some details, and allow for a quick navigation in multiple dimensions. In the following, we illustrate both notations. Let us note that AADL can also be expressed as a UML model following the MARTE profile.

The concepts behind AADL are those typical to the construction of embedded systems, following a component- based approach: blocks with clear interfaces and properties are defined, and compose to form the complete system. Besides, the language is defined by a companion standard document that documents legality rules for component assemblies, its static and execution semantics.

The following figure illustrates a complete space system, used as a demonstrator during the ASSERT project. It illustrates how software and hardware concerns can be separately developed and then combined in a complete model.

Welcome aboard OpenAADL website !

I (Jerome Hugues) operate this website as part of my commitment to the AADL standard. I’m member of the AADL standardization committee since 2006, and part of the steering board since 2011.

The objective of this website is to provide resources around the SAE AADL architecture description language, and links to tools and projects I’m involved in either directly, or as part of the AADL community.

This site is divided as follows

• Home is the welcome page;

• The Projects menu provides access to tools that support AADL features, bring specific analysis capabilities, or some utility packages.

• Download provides direct links to downloadable resources,

• Blog provides access to blog archives, providing tutorials on AADL and updated on the standard.

All contents on this website is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.