Software and systems architects face many challenges when designing life- and safety-critical systems, such as the altitude and control systems of a satellite, the auto pilot system of a car, or the injection system of a medical infusion pump. Architects in software and systems answer to an expanding group of stakeholders and often must balance the need to design a stable system with time-to-market constraints. Moreover, no matter what programming language architects choose, they cannot design a complete system without an appropriate tool environment that targets user requirements. A promising tool environment is the Architecture Analysis and Design Language (AADL), which is a modeling notation that employs both textual and graphical representations. This post, the second in a series on AADL, provides an overview of existing AADL tools and highlights the experience of researchers and practitioners who are developing and applying AADL tools to production projects.

Improving Software Development with Tools

According to the IEEE Software article, The Impact of Tools on Software Productivity, "Tools have long been recognized as an effective way to improve software development variables such as productivity and product quality." System engineers use different notations and tools that are hard to integrate due to different representation methods and semantics gaps between notations. For that reason, tools must interoperate to help engineers bridge the gap between different specifications.

A number of AADL tools have been developed by organizations, such as Rockwell Collins, the European Space Agency, Honeywell, and Ellidiss Software. These tools provide modeling concepts that describe the runtime architecture of application systems in terms of concurrent tasks, their interactions, and their mapping onto an execution platform. To support AADL for the design of life-/safety-critical systems, SEI researchers--in conjunction with members of the AADL ecosystem--have developed various tools that help define specifications with modeling capabilities, implementations with automatic code generation, and validation and/or verification with analysis plug-ins that check architecture issues from corresponding models.

Examples of AADL Tools

Popular AADL tools include the Open-Source AADL Toolset Environment (OSATE), which supports AADL within the Eclipse environment, and Ocarina, which is a command-line tool for expert AADL users.

OSATE. The SEI developed OSATE to support the AADL language within Eclipse, which is popular in the software development community and offers built-in support for many languages including Java, C, and C++. Adding support for AADL thus also facilitates connections with existing tools and avoids dedicated training on Eclipse. OSATE supports the core AADL language, as well as several annex languages (such as the error or behavior annex language for designing specific aspects of the system) and several plug-ins for validating system requirements (such as latency or dependability).

OSATE is released under the open-source Eclipse Public License (EPL) and available for most platforms (including Windows, Mac OS X, and Linux). Two versions of OSATE are available:

• The stable version is updated every two to three months after each AADL committee meeting. This version has a set of supported functionalities that are considered "stable," but it does not include all the latest functionality.
• The testing version is evolving constantly and rebuilt every night with the latest patches and bug fixes. This version is considered "unstable," however, because it is continually under development.

The OSATE source code is available on github, which is a social platform for code-sharing that allows users to contribute, potentially learn, and reuse OSATE-based functions for their own projects. As with most active, open-source projects, a dedicated bugtracker lists existing bugs and planned improvements.

OSATE extensions allow users to develop their own AADL tool on top of OSATE without having to re-design everything from scratch. Many users created OSATE extensions for research projects, such as the System Architecture Virtual Integration (SAVI) program, which was undertaken by the Aerospace Vehicle Systems Institute, or the Refinement of AADL Models for Synthesis of Embedded Systems (RAMSES), a code generation framework that targets avionics and automotive systems.
The most widely-used plug-ins for OSATE include

• The Requirements Definition and Analysis Language Tool Environment (RDALTE), which connects AADL models with requirements documents.
• The Instance Model Viewer (IMV), which provides a graphical visualization of AADL models.
• RC Meta, an Eclipse-based toolset built by Rockwell Collins, which assists with the design and validation of cyber-physical systems. RC Meta includes an AADL /SysML translator and helps engineers track the consistency of models when using both notations.
• The LUTE constraint language also developed by Rockwell Collins, which queries and validates a model by associating constraints (such as properties to be declared, required composition, etc.) with model components.

OCARINA. Jerome Hugues from the Institut Superieur de l'Aeronautique et de l'Espace (ISAE) developed Ocarina to provide the following capabilities for command-line driven use of AADL:

• Model parsing and analysis, which allows users to check that AADL models are syntactically and semantically correct.
• Model validation and verification, which allows users to check model properties and consistency. For example, Ocarina can check whether a model contains a given amount of memory component or that the processor associated with some software components has enough processing capacity to process data on time.
• Code generation, which targets embedded platforms, including the generation of code that implements the system described by the model. The code-generation features of Ocarina target embedded platforms and operating systems, such as Real Time Operating Systems (RTEMS), which are common in the aerospace industry; ARINC653-compliant systems, which are common in avionics; and other mainstream platforms, such as Linux and its real-time variants.

Ocarina is now part of the TASTE framework, which is supported by the European Space Agency to automate the design and implementation of their life-/safety-critical projects. For example, the European IST-ASSERT project enabled the automated production of system implementation from models--a major achievement. In particular, it generates and manages the configuration code of embedded systems, which is challenging because life-/safety-critical systems have specific configuration and deployment requirements. For example, they often need to set the polling period for obtaining sensor data and the need to ensure a task's completion at a specific pace.

Leveraging the AADL Ecosystem to Extend Its Power and Reach

One of the strengths of AADL is the expertise and passion of technologists in its ecosystem. To glean insights from some of them, we interviewed the following AADL researchers, developers, and users at the January 2013 AADL Committee Meeting:

• Steven Miller and Darren Cofer work at the Rockwell Collins Advanced Technology Center, which develops innovative solutions for both its commercial and military business units. They work in the Trusted Systems group where they develop and apply advanced analysis tools, including formal methods that can be used by the center's business units to build and verify software components in high-integrity systems, such as avionics flight and mission computers.
• Jerome Hugues is an associate professor at ISAE, the reference engineering school in Aeronautics and Space Engineering. He is also co-head of the Advanced Master on Embedded Systems (MS EMS) program and the last-year computer science curriculum. Hugues specializes in the teaching of software architecture. His research is focused on embedded systems architecture with a strong focus on the AADL, as evidenced by his work on the Ocarina command-line-driven AADL tool described earlier. He has been part of the AADL standardization committee since 2006, and a member of its steering committee since 2011.

Miller and Cofer have been applying AADL and OSATE for modeling distributed real-time and embedded systems that are of interest to their company. As they described it

We began serious investigation of AADL as part of our DARPA-funded META project in 2010. We used AADL to model portions of an avionics system architecture. Our objective was to use AADL to support compositional reasoning about the system-level behavior of an architectural model in which the behaviors of individual components are specified by means of assume-guarantee contracts.

Under the META project, Rockwell Collins implemented a new constraint language, Lute, on top of OSATE to verify the model characteristics according to design requirements and/or contracts. For example, Lute can be used to check that a collection of tasks, such as those computing statistics from a sensor, are all executing at the required rate. Engineers use these tools to check integration consistency.

Hugues began investigating the use of AADL in 2006 while working on the IST ASSERT Project, which was led by the European Space Agency to study the design of on-board software that is integrated in launchers or satellites. In our discussion, Hugues described his development of Ocarina:

Relying on complex, object-oriented frameworks was a blocking factor, as those cannot be easily qualified. Switching to AADL was appealing: I could separate the modeling of the configuration of my system from the actual logic, and have a tool that generates automatically for me the application-specific middleware, instead of using object-orientation. This was one of the first contributions I made to AADL through the Ocarina toolset.

The AADL ecosystem integrates well with and offers many connections to other tools used for designing life-/safety-critical systems, as Hugues reported:

During my last projects, and as an academic, I tested (or reviewed) most AADL tools: OSATE, STOOD, but also gateways to other analysis tools (formal methods such as timed automata, petri nets; scheduling analysis; model transformation). It is fascinating to see the diversity of analysis supported from one single description language. I also contribute to the implementation of some of them through the Ocarina toolset.

In that context, AADL is a good candidate to connect different notations. Likewise, Miller and Cofer highlight how AADL's well-defined semantics and description of both hardware and software concerns help bridge the gap between different notations and avoid usual issues such as semantics inconsistency and notational differences:

Some of our engineers are using SysML to model system architectures and requirements and we expect SysML to be the dominant modeling language in our product divisions. However, the SysML language does not provide sufficiently formal semantics to support the kinds of analysis that we want to do. We have tried to resolve this problem by developing translators from SysML to/from AADL.

Having used AADL as an underlying language to connect different representations, Miller and Cofer reported promising feedback:

There are a number of tools and efforts aimed at system-level modeling of complex embedded systems. We would like to see AADL used as a common underlying language for these systems that could be used for both synthesis and analysis.

This feedback is also shared by Hugues, who described using AADL with other languages on his projects:

In parallel, I investigated the use of other formalisms (such as Simulink, SCADE or SysML) in conjunction with the AADL. My main motivation to keep using AADL for my future projects and research is that AADL acts truly as a "backbone" for your system: it nicely federates all the blocks of your systems, but also lets you use external models when needed. Such adaptability makes AADL appealing: I can focus on the architecture using one formalism, and bind it to another one for requirements engineering, control/command, etc.

The Future of AADL Tools

SEI researchers have been developing new tools and functions in OSATE for many years. We are now developing features to support the specification of faults in the system architecture and provide analysis tools so that users may document their impact. For example, in the medical domain, a fault with a pump infusion system on the patient device should not propagate to the injection subsystem nor alter the quantity of drugs being injected. On the other hand, new functions motivate new needs, as Miller and Cofer highlighted:

The lack of a stable graphical environment has been a limitation both in communication (demonstrating results to others) and in quickly/accurately modeling new systems. It is often difficult to figure out how to use some of the more advanced features of AADL when we need them. The correct syntax is difficult to deduce from the reference manual and the examples available often do not illustrate what we want to do.

To address some of these needs, the Instance Model Viewer (IMV), a graphical viewer, has been added to OSATE. The graphical edition is more convenient than the textual version and will make OSATE more accessible to the user community. Convenience is also one of the reasons that engineers use other modeling frameworks that support a user-friendly graphical notation, even if they do not support analysis or validation capabilities. As Hugues reported:

The main challenge I've seen is human-related: convincing people to invest on a new language instead of relying on the (presumably) known UML derivatives. When people caught on to AADL, they understood how much they can benefit from it.

The existing IMV modeling framework motivates the need for new research projects and opens new possibilities. Users want to experiment with new features and additions in the latest version of AADL, including the new components and language annexes (such as ARINC653 or the Error-Model). Miller and Cofer described a similar experience with respect to the DARPA META program:

We are continuing the work on compositional verification that we started in META in DARPA's HACMS project, as well as in projects funded by AFRL and NASA. In the HACMS project, we are using AADL to model a UAV system and developing new tools to verify that it is robust against cyber attacks.

This blog post presents an overview of existing AADL tools, highlighting two key tools developed and used by the community. Many other tools exist, however, that are either open-source or commercial. Users who are interested in learning more about these tools can visit the AADL community wiki, which provides an extensive list of the tools that support AADL.

The next post in this series will highlight the use of AADL in the medical domain, including reports from researchers that use AADL for specifying and validating medical devices/domains.

Additional Resources

• OSATE https://resources.sei.cmu.edu/aadl-wiki.cfm
• OSATE2 download: https://wiki.sei.cmu.edu/aadl/index.phptitle=OSATE_2_download_page&redirect=no
• OSATE2 source code: https://github.com/osate/
• IST-ASSERT: http://www.assert-project.net/
• META project: https://resources.sei.cmu.edu/aadl-wiki.cfm
• AADL latency analysis https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8229
• AADL dependability https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8277
• AADL wiki: https://resources.sei.cmu.edu/aadl-wiki.cfm