When a system fails, engineers too often focus on the physical components, but pay scant attention to the software. In software-reliant systems ignoring or deemphasizing the importance of software failures can be a recipe for disaster. This blog post is the first in a series on recent developments with the Architecture Analysis Design Language (AADL) standard. Future posts will explore recent tools and projects associated with AADL, which provides formal modeling concepts for the description and analysis of application systems architecture in terms of distinct components and their interactions. As this series will demonstrate, the use of AADL helps alleviate mismatched assumptions between the hardware, software, and their interactions that can lead to system failures.

There are many well-documented examples of problems in software-reliant systems:

• In December, Ford Motor Company announced that it would be making software updates to the cooling systems of its hybrid 2013 Ford Escape and Ford Fusion because problems with the original cooling system design caused the vehicle to catch fire while the engine was running.
• A recent study of a popular automatic external defibrillator (AED) found security flaws in the embedded software and the commercial off-the-shelf (COTS) update mechanism.
• A cluster of ships attached to the Ariane 5 rocket were lost when the rocket failed to achieve orbit on its maiden voyage. The failure was attributed to an "error in software design" and resulted in a loss of more than $370 million.

These types of incidents demonstrate the need to make software more safe and reliable, which motivates our focus on AADL in this series of blog posts.

Addressing Software (as well as Hardware)

Mismatched assumptions between hardware, software, and their interactions often result in system problems that are caught too late, which is an expensive and potentially dangerous situation to 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 & DesignLanguage (AADL). The AADL standard, which was authored by my colleague, Peter Feiler, defines a modeling notation based on a textual and graphic representation that is 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 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, bus latency or jitter) systems
• validating system and ensuring that stakeholders requirements can be achieved

While initial AADL efforts were experimental, organizations have been using the AADL standard for nearly a decade. An early adopter was the European Space Agency, which leads the ASSERT project for the design and implementation of safety-critical systems. This project relied on AADL since its inception and project members continue to use it to model, validate, and produce software. From this early use of the system other projects and communities have shown a strong interest in adopting and applying the language.

The AADL committee and its members tracked users experiences and, in response, published a new version of the AADL standard in 2009, with a minor revision in September 2012.

A Global Proof of Concept In 2008, the Aerospace Vehicle Systems Institute (AVSI), a global cooperative of aerospace companies, government organizations, and academic institutions, launched an international, industry-wide program called System Architecture Virtual Integration (SAVI) to reduce cost/cycle time and rework risk by using early (and frequent) virtual integrations. In addition to the SEI, major players of the SAVI project include Boeing, Airbus, Lockheed Martin, BAE Systems, Rockwell Collins, GE Aviation, federal aviation administration, the U. S. Department of Defense (DoD), Honeywell, Goodrich, United Technologies, and NASA.

SAVI was created in response to the realization by aircraft manufacturers that the source lines of code (SLOC) in software-reliant systems was increasing exponentially. Over the past 20 years the size of aircraft software, measured in SLOC, has doubled every four years. For the next decade, the projected 27.5 million lines of code required are estimated to cost in excess of $10 billion. In addition to the increased software cost, the latest generation of aircraft, such as the Boeing 787s, will be highly interconnected and are projected to produce half of terabyte of data per flight.

Coupled with that increasing complexity is a growing reliance on embedded software to meet requirements for key features, such as greater range and comfort on fewer, more economical flights. The intent of SAVI was to pilot a new technology and a new acquisition process based on architectural models rather than paper documentation with multiple dimensions of analysis used throughout the lifecycle.

A key tenet of virtual integration is the use of an annotated architecture model as the single source for analysis. For the SAVI proof of concept, an aircraft system architecture was modeled using the AADL standard. This process allowed AVSI to capture integration faults earlier in the development process, and meet increasing demands for safety and economy.

As indicated in the graphic below, the National Institute of Standards & Technology estimated in the report The Economic Impacts of Inadequate Infrastructure for Software Testing that more than 70 percent of all system defects are introduced prior to code development, while only a small fraction are detected during that time. The remaining errors are detected in the testing phase when it's most expensive to fix. The ability to detect errors and defects prior to implementation efforts therefore reduced development costs and efforts, while enhancing overall system robustness and reliability.

The SEI technical report, System Architecture Virtual Integration: An Industrial Case Study, details the SAVI proof of concept and results, which include

• multi-tier modeling and analysis of an aircraft and its subsystems
• support for the needs of both system engineers and embedded software system engineers
• propagation of changes to the model across multiple analysis dimensions
• maintenance of multiple model representations in a model repository
• auto-generation of analytical models
• interfacing of multiple tools
• distributed team development via a model repository

New Directions for AADL

A number of organizations actively use AADL in their modeling and analysis efforts. While AADL was originally developed for aerospace and avionics, it is now being used in many other fields, including automotive and medicine. In particular, as more medical devices are adopted and connected together, there is a growing interest in analyzing and verifying them, especially because issues may have a catastrophic impact on patients.

The Food & Drug Administration (FDA), in partnership with the Penn Research in Embedded Computing and Integrated Systems Engineering program, plans to use AADL to support the architecture of modeling concerns for the Generic Infusion Pump. One example of a generic infusion pump would be a model for a Patient-Controlled Analgesia Pump. AADL is used to specify system devices, the underlying software artifacts (in terms of tasks, subprograms), their interaction in terms of events or data and the inherent deployment over the execution platform (association with processors, buses, etc.). The language was also used to capture and analyze system behavior (dependencies among events, conditional execution of system functions according to received data, etc.)

We are also working to connect the AADL technology to other technologies being developed at the SEI. For example, SEI researchers are creating cost assessments of different iterations of system architectures. This work will explore questions including

• When you have a defined and established architecture, what is the cost for a new iteration?
• What is the cost and impact involved in changing an architecture?
• By describing the runtime aspects of the system's deployment, can AADL help evaluate the potential impact of a modification of the execution runtime (for example, when upgrading a device)?

Future posts in this series on AADL will highlight real-world applications of AADL, which are presented by users during the AADL standard meetings. At every meeting we include user days where users reflect on their experiences with AADL and tool sets that they have developed. Please let us know your experiences applying ADDL in the comment section below.

Additional Resources

In September 2012, Peter Feiler co-authored with David P. Gluch the book, Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis & Design Language. For more information, please visit
https://resources.sei.cmu.edu/library/

With our user community, the SEI maintains a wiki with all of our research on AADL that is accessible to the public. To access the wiki, please visit
https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=191439

To access a site that maintains source code for AADL, where people can come and freely contribute to the OSATE tool set that is supporting AADL, please visit
https://github.com/osate

To read the SEI technical report, System Architectural Virtual Integration: An Industrial Case Study, please visit
http://www.sei.cmu.edu/library/abstracts/reports/09tr017.cfm

Julien Delange and Peter Feiler will present Design and Analysis of Cyber-Physical Systems: AADL and Avionics Systems, at SATURN 2013. For more information, please visit
http://www.sei.cmu.edu/saturn/2013/program/abstracts.cfm