AADL in Practice – Book and Interview with Julien Delange

Julien Delange has a new book on AADL (Architecture Analysis and Design Language) in Practice.  Today, we sit down with him to learn more about this language, its origins, why should you care about it and how it compares with other languages. As he puts it, keep reading to become an expert of software architecture modeling and analysis.

Can you briefly introduce yourself and how did you get involved with AADL?

My name is Julien Delange. I lived in France, got my PhD in Paris, lived in The Netherlands (where I worked at the European Space Agency) and I am now currently living in Seattle, WA and working for Amazon Web Services. I am a software engineer and enjoys playing/hacking with computers since I am a kid.

When I started my PhD in 2008, I met Peter Feiler while he was visiting my lab in Paris. He invited me to work at the Software Engineering Institute and I started to contribute to the standard quickly. After my PhD defense, I got a position at the European Space Agency to work on their AADL tools and moved to the USA to work with Peter on the OSATE tools (OSATE is an Eclipse-based AADL modeling platform). I worked for 8 years on AADL and its related tools. That is the reason I wrote this book – I wanted to share the knowledge I accumulated through all these years.

Can you briefly describe what is AADL? Who is behind the language?

The Architecture Analysis and Design Language (AADL) is a modeling language to capture the architecture of a software system (e.g. a pace-maker, a self-driving car) and the interactions of that software with the physical aspects of a system (e.g. sensors in the body, signals and lights in the street).

The language was initially designed towards avionics systems but it quickly became popular in other domains (medical, aerospace, etc). The language is originally designed by Peter Feiler at the Software Engineering Institute, which took some concepts from other languages (Meta-H).

The language semantics is well defined and not ambiguous. There is a single model to capture the system, so, you avoid defining the same thing twice, which is one of the major issues with others languages (like UML).

The standard defines a textual (easy to process by tools) and graphical notations (easy to visualize by humans). For example, the following picture shows a graphical model of two processes (process_producer and process_consumer) communicating a value through a shared network (ethernet_bus) (a similar example is detailed in the book, you can even have the corresponding textual version inside the book :-). You can use such a model to perform latency analysis (how long does it take to transport the data from the sender to the receiver according to network protocols, traffic congestion, scheduling mechanism, etc.), safety analysis (e.g. what is the impact of an error on the ethernet_bus over the consumer process?), etc.

AADL is an international standard from SAE. The committee is actually composed of people from different industries all over the world.

 

Who (or in what scenarios) should use AADL? What are the main applications?

AADL primarily targets safety-critical applications. The goal is to support the whole development lifecycle, from requirements specification to system production and certification. This is clearly not a language for designing the next trendy web-service or even the architecture of your next computing farm. AADL is a language to design and analyze real-time, embedded systems that needs to be carefully reviewed and analyzed.

The big advantage of AADL is its precise and consistent semantics: the component behavior is defined by the standard and there is a single model, which avoids ambiguity of multiple definitions (like we can have with UML).

The same model can be used to document your software architecture (generating spreadsheets/tables for system review for example), verify the system (using static checker, export some aspects of the architecture to formal notations), simulate its behavior (by generating simulation code) or produce it (automatic generation of certified code).

All these aspects have been explored in several projects and some are used in operational projects. For example, ISPRAS (a Russian research institute) uses AADL to auto-generate configuration code for avionics architectures. The European Space Agency (ESA) invests in the TASTE toolchain that produces certified C code from AADL model (https://essr.esa.int/project/taste ). The US Army and DoD, invested a lot on AADL too, using it for various projects, such as SMACCM (https://github.com/smaccm/smaccm) which aims at producing secure drone and generating their code from models.

What can you about the popularity of AADL in the industry? Do you use it at Amazon?

AADL is popular in the safety-critical, embedded systems domains. If you work in avionics, medical, aerospace or automotive domains, there is a fair chance you heard something about the language. While working at the European Space Agency (ESA) or at the Software Engineering Institute, I always had requests to learn and use AADL. It was hard to satisfy all requests – this is also why I started to write the book and make the technology accessible to everybody. The work I am doing at Amazon is totally different, I am working on AWS EBS and we are not using such technologies.

Any tool you’d recommend to get started with AADL?

There are plenty of tools! Let’s start with the tools that are open source. The first one is OSATE (http://www.osate.org), the Eclipse-based AADL modeling environment which supports both graphical and textual notations. The second project that comes to my mind is Ocarina, a command line AADL tool used to generate Ada and C code from AADL models (http://www.openaadl.org). The third one is MASIW (http://forge.ispras.ru/projects/masiw-oss) another Eclipse-based modeling platform developed by ISPRAS, a Russian research institute. It includes several model analysis tools and supports both graphical and textual notations.

On the commercial side, Elilidiss (http://www.ellidiss.com/) offers AADL inspector, an AADL-based system analysis tool (with many scheduling analysis functions). Also recently, ANSYS started to support AADL in their SCADE architect tool suite. This shows how people are getting serious about this technology (SCADE is the technology used to produce many software components or Airbus airplanes).

How AADL relates to other languages like UML? Or to enterprise architecture modeling frameworks like TOGAF?

AADL complements these technologies. I see UML mostly as a (or even the) technology to document your software, communicate between teams, not for doing a formal description of your software architecture and perform critical analysis (or even generate the code). The AADL committee had several discussions with members of the Open Group and we strongly believe we complement many of these technologies. They mostly define a framework to conduct your project while AADL is the technical solution to use to specify your architecture, analyze its correctness with regard to your requirements and ultimately generate certified code that will run on the target platform.

Following up on the previous question, what are the main competitors of AADL? Why is AADL better?

The main competitor is obviously SysML, which was the tentative to address UML limitations when it comes to capturing a software architecture. However, SysML inherits the defects of UML – ambiguous semantics, no standardized behavior, lack of tool interoperability. AADL does not have these issues.

Many people use SysML because they can use the same tooling (editors, etc.) they use for UML. It lowers the acquisition cost (no more learning or license to purchase) but at the end of the day, limits what you can do with your models (limited validation, no code generation, etc.) unless you restrict/tailor the language yourself.

You can represent all aspects of SysML with AADL – except the requirements notation – the committee is actually working on it. In fact, except the training/license costs, I do not see any reason to use SysML

What is the roadmap or the vision ahead for AADL?

The committee is working on the third version of the language.

This new version should remove some useless artifacts and improve some aspects (such as resource binding, which is currently done using standard properties). The committee is also working on a requirement notation to associate requirements with the software architecture. That would provide the foundation to trace requirements to the software architecture and automatically validate requirements from the software architecture.

What will people find in your book?

AADL In Practice is a practical, accessible guide to learn AADL. It starts with an introduction to the language and explains most of the constructs you need (components, connections, flows). It also details how to use existing analysis capabilities of OSATE: latency and safety (the book explains how to capture safety information in an AADL and generate safety analysis documents, such as Failure Mode and Effect Analysis or Fault-Tree Analysis). The last part explains how to extend the language for your own needs and how you can start writing your own analysis tools.

It targets students, professors, and professional willing to learn and apply the technology. I tried to make is accessible with the information required to start using the technology. The book relies on OSATE, an open-source tool available online and all the code of the book is available on github. Readers can start importing the models and try the tool quickly.

Any other resource to learn about AADL?

I would recommend first the AADL wiki (http://aadl.info/wiki) and Open AADL (http://www.openaadl.org). And keep in touch with the latest updates about the book on http://www.aadl-book.com