Mismatched assumptions about hardware, software, and their interactions often result in system problems detected too late in the development lifecycle, which is an expensive and potentially dangerous situation for developers and users of mission- and safety-critical technologies. To address this problem, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named the Architecture Analysis & Design Language (AADL). The AADL standard,defines a modeling notation based on a textual and graphic representation used by development organizations to conduct lightweight, rigorous--yet comparatively inexpensive--analyses of critical real-time factors, such as performance, dependability, security, and data integrity.

AADL models capture both software and hardware components, as well as their interactions, including the association of a software process on a processor or the deployment of connection on a bus. The AADL standards committee, led by my colleague, Peter Feiler, who played an instrumental role in the development of AADL, meets regularly with members from around the globe who represent a wide variety of industries, from avionics to aerospace, to discuss evolving elements of the standard and to work together on action items from prior standards meetings. In this post, we present highlights from a series of podcasts that we recorded with Feiler and four members of the standards committee discussing their real-word application and experiences with AADL.

The AADL standard includes abstractions of software, computational hardware, and system components for

• specifying real-time, embedded, and high-dependability systems with their software/hardware concerns and their specific requirements (such as scheduling and bus latency or jitter)
• validating the system and ensuring that stakeholders' requirements can be achieved

Organizations have been using the AADL standard for nearly a decade. An early adopter was the European Space Agency, which leads the ASSERT project, which eventually became The ASSERT Set of Tools for Engineering (TASTE) targeted at the design and implementation of safety-critical systems. This project relied on AADL from its inception, and project members continue to use AADL to model, validate, and produce software. From this early use of AADL, many other projects and communities have adopted the language.

The AADL committee and its members tracked users' experiences and, in response, published a new version of the AADL standard in 2009. The committee also released a minor revision in September 2012. The remainder of this post includes conversations that Feiler had with four committee members representing various industries who have adopted AADL, including aviation and aerospace.

AADL and Aerospace
featuring Myron Hecht and Peter Feiler

Myron Hecht's research at Aerospace focuses on safety, reliability, and model-based system engineering and its application to quantitative and qualitative reliability analysis methods. He has previously worked in the domains of nuclear reactors, air traffic control, and avionics. During the podcast interview, Hecht stated that AADL represents a path for enabling practitioners in the dependability community:

By dependability, I mean reliability, safety, and security, to be able to interchange models and thoughts and analyses in a structured way. The problem with the field at this point is that there are a lot of good ideas, but we don't understand each other because it takes too long to figure out what everybody is doing. The biggest problem that we have in these analyses is the unstated assumptions and unstated limitations. The sooner we get onto a standard platform where we're all speaking the same discipline really, the sooner we can begin to make major progress in building the next generation of computerized systems, in which people's lives may depend even more on the computer itself, without any manual intervention. I have no idea how we're going to do driverless cars. I have no idea how we're going to do home medical devices for critical illnesses unless we really get greater confidence in our ability to do the analyses.

When asked how AADL contributed to helping Aerospace make the transition from unstated to stated assumptions and limitations, Hecht responded as follows:

Well, the most important contribution that AADL made from its origination in the aircraft industry, when it was born out of an earlier project from DARPA, where they really intended to develop real-time systems for avionics applications, simply by specifying them in the design. When you work in that environment, one of the things that you're really worried about is what happens if things go wrong. If your car radiator blows over, you can stop by the side of the road.

Hecht used the first version of AADL's error model annex, which was released in 2006, and extended some of the original tooling work by Ana Rugina to build a tool suite that helps him in his work. Hecht leveraged the AADL notations extended with reliability information to generate safety models and generates safety analysis documents from the architecture, such as failure mode and effect analysis (FMEA) reports.

Well, I think what is more to the point is that they get insight into the failure behavior and the weaknesses of their system and what they might have to do to improve it. Not only that, but the sponsor of their work, who is typically not the designer himself or themselves, is going to know what's going on. Going to be able to monitor that part of the process and program manager...So, that constant feedback between a design and analysis, which now becomes a very tightly coupled loop in a very, very rapid process, is one of the key enablers to enable us to build complex safety-critical, life-critical, and mission-critical systems.

To listen to the complete podcast, AADL and Aerospace, please visithttps://resources.sei.cmu.edu/library/asset-view.cfm?assetid=88335

AADL and Edgewater
featuring Serban Gheorghe and Peter Feiler

Serban Gheorghe, vice-president of technology at Edgewater Computing Systems Inc., explained that he first became involved in AADL as Edgewater prepared to deploy a communication product.

I got more involved in the technology. What we did is an AADL microkernel, basically with the intent on transforming it into a product. We are still working on that product. We have a few pilot trials in different places. The idea is to take AADL designs and convert them to our kernel and do all the static analysis in the same way and to have a very defined way of producing code, which is certified. So, the certification chain would be much easier to accomplish because it is always a constant concern.

AADL provided a means for reducing evidence from a chain of certified components from the model into the kernel into the actual code.

The whole value proposition of our product was that--independent of the models on the project where our tools are used and independent of the targets and how the targets are used--the same chain of tools tends to be used.

Gheorghe added that Edgewater is working with several international organizations to build a constraints annex, which adds a standard set of analysis tools within the OSATE tool environment, which is open source.

But, you know, there will always be more analysis, which is project specific, and constraints, which are project specific, which have to be enforced. What we are providing here is kind of a generic sub-language to be able to express those concerns and constraints.

The ability to express those concerns and constraints serves as a catalyst for facilitating the evolution of a component.

So, you can now create AADL components and fully characterize them in what you expect to get from them in terms of assumptions and guarantees. Secondly, I think it facilitates this concept of integrating multiple tools with multiple formalisms from the same repository. There are no different assumptions made by different tools.

Feiler noted that this ability also enables architects to write specialized constraints for a project without implementing a new tool to enforce those constraints. Work on the constraints annex tries to leverage existing notations. For example, there is a standardized notation called Property Specification Language (PSL) that is used as one basis and then used to look at what elements need to be added to be useful in this context.

To listen to the complete podcast, AADL and Edgewater, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=298692.

AADL and Télécom Paris Tech
featuring Etienne Borde and Peter Feiler

Etienne Borde, an assistant professor and researcher at Télécom ParisTech, explained that the technical university became interested in AADL because the embedded systems industry is growing at a robust pace, especially in Europe. Borde's research focuses on software engineering for real-time, embedded systems.

We use it as a teaching tool and as a research tool, and both parts are a little bit challenging. The research, of course, is because we have to face new problems. The teaching is because AADL is typically the kind of language that you can use for very advanced software engineering methods. We tried to teach it to students that physically did very little software in the labs. So, there is this kind of gap between what they're able to understand about software engineering challenges and what AADL is meant to answer.

AADL has helped systems engineers understand how software affects their decisions or how their decisions affect software performance.

This is typically why we are interested in AADL as well. It's because it's a very good language for us, in our opinion, to tackle the issues that you have in safety-critical, embedded systems. So, those [systems] for which you need to have very strong guarantees in the behavior of your software applications.

Borde added that his team is mainly using AADL in its research to make the prediction of the software applications or the configuration of the operating systems that will host the software applications.

The operating systems in safety-critical, embedded systems have very different characteristics than in standard computer systems. Of course, you can't accept that your operating system fails the same way that your home operating system could fail...You can't have delays of tasks. You need to have specific operating systems. Those are quite difficult to configure. You have to be careful in the configuration process of those and the type of guarantees that you can manage by this configuration process.

Feiler added that Borde's team at Télécom Paris Tech is working on code generation capabilities that automatically create the complete execution runtime from the model. This generated code integrates also the functional code written by potentially different suppliers. The individual pieces of application code may be written in either Simulink or another modeling language, Feiler added, but AADL provides the glue that interconnects them.

To listen to the complete podcast, AADL and Telecom Paris Tech, please visit http://www.etienneborde.fr/ramses-project/updates/seipodcast-aadlandtelecomparistech

AADL and Dassault Aviation
Featuring Thierry Cornilleau and Peter Feiler

At Dassault Aviation, Thierry Cornilleau contributes to a number of real-time and avionics software studies and projects focused on avionics and aerospace mechanics and aviation. As an engineer working in the avionics domain, Cornilleau is also interested in another standard, ARINC 653, and the connection between AADL and ARINC 653.

Feiler noted that Cornilleau's experience helps the AADL committee define the standard in ways that ensure it meets the needs of the avionics industry. Cornilleau provided inputs and insights to the committee when working on the AADL ARINC653 annex, a document that details how to represent ARINC653 architectures with AADL. Thanks to his contributions, the document has been considered mature enough to be published as an official SAE standard.

Dassault is very progressive in its use of formal methods, including AltaRica, a language used for system fault modeling and analysis, which ties in to the error model annex. Cornilleau remarked that two important recent developments with AADL have been with the error modeling annex and the maturity of OSATE, a tooling environment that helps users implement AADL within the Eclipse open-source environment.

Cornilleau added that other members of his team at Dassault serve on the ARINC 653 committee. In addition to laying out a partitioned architecture, regular interaction with members of the ARINC 653 committee provided guidance for monitoring the health of the avionics systems, Feiler said and added the following:

With our now more formalized notation, one could get into a discussion with them about how we can provide more formalized guidance on how we can express this health monitoring architecture that they are suggesting to people. So, what we get into is that the AADL Committee cooperates with other committees to put AADL to use in other settings as well.

To listen to the complete podcast, AADL and Dassault Aviation, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=433479.

Additional Resources

For more information about the Architecture Analysis & Design Language (AADL) please visit
http://www.aadl.info/aadl/currentsite/.

To view a recent webinar, Architecture Analysis with AADL, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=424907.