When life- and safety-critical systems fail (and this happens in many domains), the results can be dire, including loss of property and life. These types of systems are increasingly prevalent, and can be found in the altitude and control systems of a satellite, the software-reliant systems of a car (such as its cruise control and anti-lock braking system), or medical devices that emit radiation. When developing such systems, software and systems architects must balance the need for stability and safety with stakeholder demands and time-to-market constraints. The Architectural Analysis & Design Language (AADL) helps software and system architects address the challenges of designing life- and safety-critical systems by providing a modeling notation with well-defined real-time and architectural semantics that employ textual and graphic representations. This blog posting, part of an ongoing series on AADL, focuses on the initial foundations of AADL.

The SEI's Work on AADL

The SEI has been one of the lead developers of AADL and has participated on the AADL standardization committee since its inception. SEI researchers also developed the Open Source AADL Tool Environment (OSATE), which is the reference implementation for supporting AADL within the Eclipse environment and a number of AADL-based analysis capabilities. The SEI and other researchers and developers have used AADL as a foundation to design and analyze life- and safety-critical systems. Likewise, several projects have used AADL to design software architecture and analyze, validate, or improve various quality attributes, such as reliability, latency/performance, or security.

While AADL was initially conceived for use in avionics, this blog series has demonstrated its applicability in other domains that rely on life- and/or safety-critical systems, including the medical domain. Likewise, AADL tools have been developed by organizations such as Rockwell Collins, the European Space Agency, Honeywell, and Ellidiss Software to 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.

Software with Reuse: AADL Beginnings

Bruce Lewis, an experienced software practitioner working for the U.S. Army Aviation & Missile Research at the Development & Engineering Center (AMRDEC) in Huntsville Alabama, is a key player in the development and evolution of AADL. Lewis, who formed the AADL Standards Committee and co-drafted the first-ever requirements document for the standard, attended a standards committee meeting at the SEI's Pittsburgh headquarters in July 2013 and described his purpose in the standardization of AADL:

Originally, we were working on different reuse techniques and ways to build software with reuse. This was in the early '90s. We found that the different reuse approaches weren't really effective without an architecture description where we could actually analyze how components would fit together and also analyze the effect of putting them together. DARPA [the Defense Advanced Research Projects Agency] also was not satisfied with the current state-of-the-art for domain specific sets of components. They also wanted an architecture approach. So, I went to DARPA to talk to them about a possible solution. They pointed me to the Domain-Specific Software Architecture (DSSA) project, which was inventing the concept of an architecture description language. We began to experiment with architecture description languages for real-time, mission-, and safety-critical systems. That's how I met Peter [Feiler], who also was working on the DSSA project.

DARPA offered me the opportunity to lead the research projects for the Honeywell MetaH language over several DARPA programs. MetaH became the foundation for AADL. Our primary project involved essentially reengineering then enhancing a missile system using a reference architecture that we had developed. We then developed and hosted the missile system to multiple targets on single and distributed multi-processor platforms. We verified the system flew correctly by running the environment simulation and the tactical code on the embedded processors for each processor target. In each case, the missile flew correctly after rapid ports to the new processing environment. MetaH was so effective in our army experiments that I felt like it was very important to move it to a standard and push it forward in the industry as a more powerful, more effective means for real-time system building and evolution.

Lewis and Feiler shepherded AADL into a language that could be used to ensure the reliability of other safety-critical systems in other industries including aerospace, telecommunications, and medical equipment. For these industries, the exponential growth and increasing complexity of software and systems development had become a major area of concern. A team of SEI researchers led by Feiler detailed the exponential growth and complexity involved in developing safety-critical systems in the technical report, System Architecture Virtual Integration: An Industrial Case Study.

In that technical report, the authors described how aerospace software-reliant systems have experienced exponential growth in size and complexity, and also unfortunately in errors, rework, and cost, primarily due to integration issues that are detectable through architecture-centric analysis. New development of safe aircraft is reaching the limit of affordability. They also noted that the size of software systems, measured in source lines of code (SLOC), had doubled every four years since the mid-1990s and reached around 27 million SLOC of software by 2010. Rework costs were in the multi-billions of dollars. Discovering even a small percentage (10 percent) of these issues would yield a major payoff.

A key challenge faced by developers and testers of aerospace software systems resides in the integration of industrial and commercial off-the-shelf (COTS) components from multiple suppliers. Developers increase produce systems by integrating new and existing components rather than starting from scratch. This approach allows some benefits, such as reuse of existing development efforts, ease in the creation of product lines, and the reduction of component production costs. There are, however, some drawbacks to this approach:

• Components are loosely related and never intended to work together in the new context. Assumptions constraining usability may not be documented.
• Newly assembled artifacts have different and potentially conflicting requirements.
• From an OEM's perspective, multiple alternative components need to be evaluated for architectural effects.
• Existing components were validated and tested in one system but could not work in other environments (e.g. deploying a function on different processors, different timelines, messaging infrastructures, scheduling, error handling environments, or execution runtime)
• All other integration and/or deployment issues engineers had already experienced during operational projects, such as memory, bus, processor utilization, data integrity, safety and security requirements, shared resource contention, end-to-end latency, jitter sensitivity, fault-tolerance requirements, execution behavior, definitions of data, functional integration correctness, and underlying assumptions internal/external to the component.

These errors are likely discovered during the integration test phase, late in the development process. As a result, they increase the need for testing, introduce the need for rework and new development, increase costs, and postpone product delivery.

To address the problem of integration, AADL needed to represent the architecture early and incrementally to find problems typically reported during the system integration phase. When this approach is applied during the requirements and design phase, it will result in errors that can be repaired at a time when they are less costly to fix. Lewis described the evolution of AADL to address system integration:

The DARPA/Honeywell MetaH language provided very powerful concepts for architecture analysis and rapid generative integration driven by the analytical models, but the language was limited in flexibility and scope. We had 30 extensions from DARPA experiments that we knew we wanted to make plus industry and academic input on the committee. Based on his wealth of experience, Feiler became the primary AADL language architect. We knew that the AADL needed to support common analysis and integration of specifications across contractors based on precise core standard semantics for real-time systems. AADL also needed to provide flexibility for language extension for properties and annexes for specialized domains and tools. Since architectures must support evaluation of many quality attributes and requirements, AADL was developed for multi-domain analysis from a centralized model so we could detect side effects across these domains through a centralized, shared architecture model. It was also developed to support ease of incremental component refinement through extension mechanisms and to support analysis of incomplete specifications. Throughout the development process, we verify the integration of components into the virtual real-time system.

During our DARPA years, we moved into the more complex and challenging aviation domain. We wanted a domain that was really challenging where we could exploit the power of architecture expression to demonstrate many emerging architectural qualities in complex systems. This proved to be well targeted and timely. The aviation industry, at the same time, was beginning to recognize that they were suffering from what were essentially failures to effectively integrate the software system architecture. Costs were extremely high, and there were many expensive programs that demonstrated the fact that we need some kind of an architectural approach that was quantitative and qualitative. This approach would help us understand the architecture as early as possible, do virtual integration, and then ultimately build the system.

Our next post in this series will describe the use of AADL to improve safety and reliability in the aerospace industry as part of the System Architecture Virtual Integration (SAVI) project.

Additional Resources

To view the AADL Wiki, please visit https://resources.sei.cmu.edu/aadl-wiki.cfm

For more information about AADL, please visit http://www.aadl.info

To read the SEI technical report, System Architecture Virtual Integration: An Industrial Case Study, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9145