Archives

Get monthly notifications of updates to news@sei features and columns

Contact the Editor

SEI Technical Reports

SEI Events

SEI Home

features

AADL Standard Enjoys Continuing Expansion and Transition
John Morley

Under a brilliant, cloudless sky, a late-model, sleek coupé races along the narrow, winding, tree-lined road, verging on being out of control. Its silver-metallic finish flashes almost white as the car zooms behind a grove of lush poplar trees. Inside the car, the driver tries repeatedly to apply the antilock brakes. But the brakes won’t engage. Frantic, the driver bangs forcefully on the steering wheel. Recovering composure, the driver then tries to remove the electronic ignition card. But, again, to no avail: this car cannot be stopped. As the car barrels toward a hairpin turn, the driver braces against. . . .

Is this part of a thrilling scene from Casino Royale, the latest James Bond film? Has some villain tampered with our hero’s brakes?

Well, no. This scene, embellished a bit, actually happened. A driver found that the antilock brakes would not slow the car, and the engine could not be shut down, even after the card was removed from the ignition. The antilock brakes were not able to receive constant data from the wheels because the car’s computer system was overloaded by competing demands. Fortunately, 90 exhilarating minutes later, this driver was able to solve the problem by running the gas tank to empty.

The operation of a car’s braking and ignition systems is largely controlled by embedded systems—that is, software and hardware designed to perform a dedicated function without human intervention. Embedded systems must meet stringent requirements on performance to ensure that the system reliably provides service. Embedded systems need to be self-reliant, too, because, as in the example above, expert human intervention is rarely possible in the event of a failure. In addition, embedded systems compete for limited resources (such as memory, power, and bandwidth).

Throughout each day, we encounter embedded systems—in cell phones, handheld calculators, and MP3 players; at automatic teller machines and traffic lights; in microwave ovens, televisions, thermostats, computer peripherals, and washing machines; and in many other common devices. Embedded systems are also in complex guidance and flight-control systems in missiles and aircraft and in production-plant monitoring.

In all of those examples, problems—such as the resource contention issue that kept both the brakes and the ignition from working in the runaway car—can arise when individual embedded systems are combined to form a system of systems.

“Companies building embedded systems are moving from federated to integrated development,” Peter Feiler of the Software Engineering Institute (SEI) explains. “Like its name implies, federated development means that systems are put together from embedded component software that runs on its own, typically specialized, hardware. In integrated development, off-the-shelf hardware components provide a distributed computing platform that is shared by the integrated embedded component software.”

Consequently, software systems engineers need ways to predict how individual systems will behave in the system-of-systems environment. Traditionally, embedded system engineering practice has been manual, paper intensive, error prone, and resistant to change. It suffers from the lack of a means to precisely analyze system architecture early in and throughout the development process. The result: little or no insight into critical system characteristics—such as performance (e.g., throughput or quality of service), resource utilization, resource contention, safety, reliability, time criticality, security, and fault tolerance. System integration becomes risky, and system evolution (life-cycle support) becomes expensive.

By contrast, improved embedded system engineering practice can be architecture based and model driven—that is, driven by models of components and interactions that can be analyzed by computers and directly implemented. A well-defined computer-system architecture provides a framework in which software and hardware components can be designed and integrated. System models that precisely capture system architecture can provide the basis for predictable embedded-system engineering analysis early in and throughout the development life cycle.

Industry acceptance of and tool-vendor support for the model-driven architecture approach provide evidence of the growing popularity of model-based engineering.1 The Architecture Analysis and Design Language (AADL) is an industry standard designed to support model-based embedded system engineering.

“The AADL is a modeling language with precise semantics that can be processed by computer-based tools,” Feiler says. This standard defines a textual and graphical language for describing the software architecture and execution-platform architectures of performance-critical, embedded, real-time systems. Using an AADL description, a system designer can perform schedulability, sizing, safety, and other analyses to evaluate architectural tradeoffs and changes.

The Society of Automotive Engineers (SAE) issued the AADL standard in November 2004. Now, the AADL standard is positioned for continuing adoption, fueled by an ongoing effort to extend and enhance the language, and backed by growing efforts to develop more targeted training and guidance.

Foundation of the AADL

Although the AADL standard was issued in 2004, its roots go back about 15 years. At that time, researchers started to look at software architecture with the aims of improving software-system development, supporting product lines and software reuse, and providing a new approach to system integration.

Under the sponsorship of the Defense Advanced Research Projects Agency (DARPA) and the U.S. Army, Honeywell Labs developed MetaH, the first domain-specific architecture description language in 1993. MetaH was dedicated to avionics systems and offered the first comprehensive toolset for integrated modeling, analysis, system integration, and verification.2

By 2001, the AADL had begun to be developed from MetaH, largely due to the efforts of Bruce Lewis of the U.S. Army Aviation and Missile Research, Development, and Engineering Center (AMRDEC) in Huntsville, Ala. Lewis was involved in two key groups: He was the DARPA technical agent for MetaH technology through several programs and a DARPA principal investigator conducting experiments with MetaH. Lewis also participated in an SAE subcommittee on real-time operating systems.

“Through our experiments with reference architecture and the reengineering and porting of a real-time missile-flight-control system across multiple hardware architectures, it became apparent that we had a valuable technology for the reduction of system development and upgrade costs and risks,” Lewis says. “To provide a common platform for computer-system analysis and integration, we needed a well-defined standard.”

Meanwhile, at the SEI, Feiler was tracking DARPA-funded projects. He also built a mapping between MetaH and ACME, a language and tool library for the interchange of architecture descriptions. Through his work, Feiler saw what should be included in a new language based on foundational concepts in MetaH.

Lewis knew that moving the AADL through a standardization process would also encourage support by industry—the key to its adoption into practical use. In addition, the early adopters would spur further development of the standard and demonstrate a need for analysis tools, which in turn would accelerate work by tool vendors. Accordingly, Lewis formed the subcommittee within the SAE in 2000 to develop the AADL standard.

By 2003, there were 20 member organizations in the group; and by the time of the AADL balloting in 2004, there were 23 member organizations from around the world with voting rights. Along with the U.S. Army, Airbus, the SEI, and the European Space Agency (ESA), organizations that have been involved in this global standardization effort include Rockwell-Collins, Axlog, ElliDiss, Honeywell, Smith Industries, and Dassault Aviation, among others.

Lewis chairs the SAE AS-2 Embedded Computing Systems subcommittee team that includes

AADL Standard

The AADL standard3 provides

Because it is not possible to foresee all possible architecture analyses, the standard’s core language is extensible. Extensions can take the form of new properties and analysis-specific notations, defined by users or tool vendors.

In addition, users can propose extension sets for addition to the standard as annexes, sublanguages that have been approved by the subcommittee’s voting members. Four annexes have been added to the standard for error modeling, graphical notation, programming-language compliance and application-program interface, and meta model and interchange formats.4

The voting members are now deciding on the addition of a UML 2.0 profile for the standard that will enable users to incorporate their UML tools in AADL modeling. In the longer term, the AADL subcommittee is developing other enhancements as a result of user feedback and needs, including improvements to subprogram and system-family modeling and new annexes for behavior modeling and ARINC 653 (a standard for partitioned avionics systems architectures).

AADL Adoption and Support

The AADL is intended for use in avionics and flight-management systems; space, automotive, and robotics applications; industrial-process-control equipment; and certain medical devices. Since 2004, the AADL has been used to model and analyze the architecture of flight-control systems, the reference architecture of the EuroFighter, and the architecture of a high-speed network switch for workload distribution. Also, the ESA has used this standard to model the architecture of two families of satellite systems for high reliability.

From its start in avionics and aerospace, the AADL has attracted interest from users in the automotive industry. (Ford and Toyota are voting members in the standardization effort). Reflecting that interest, the subcommittee held one of its 2006 meetings at the SAE Automotive World Congress.

The buildup of AADL use has been accompanied by several support initiatives. For instance, the SEI offers a two-day course on model-based engineering with the AADL. In the course, software systems engineers use AADL to

In 2007, the SEI will offer its Model-Based Engineering with SAE AADL course at the SEI Pittsburgh, Pa., office. That course is the forerunner of a model-based engineering for embedded systems curriculum, according to Carol Sledge, curriculum designer for the SEI AADL working team. “The curriculum will feature AADL and define a number of role-based certificates and certifications,” Sledge says.

In addition, the SEI publishes reports on the AADL core language and business-use-case examples5 and maintains the AADL Web site as a source for information about the development of the standard. This Web site includes links to Wikis and forums for users and tool developers. By discussing their needs in these forums and at AADL subcommittee meetings, users are convincing tool vendors that there is a market need to fill. “A language standard needs to be supported by tools, but tool vendors need to see a customer base,” Feiler points out.

The SEI also is developing two books on AADL. “One of our books will focus on how validating quality attributes (performance, dependability, security, and the like) with model-based engineering and AADL assists the system architect or designer in evaluating architectural decisions,” says Jorgen Hansson, a leader of the SEI AADL publishing effort. “Our other book will be a guide to AADL constructs and mechanisms—the essentials needed when building AADL models.”

To encourage tool development, the AADL subcommittee follows a two-part tool-development strategy. One aspect is the Open-Source AADL Tool Environment (OSATE) that includes an AADL front end and architecture-analysis capabilities as plug-ins to the open-source Eclipse environment. OSATE provides an interface to allow users to bring their own tools into an AADL environment. Airbus provides an open-source graphical editor under the TOPCASED initiative; this editor is integrated with OSATE.

Because the SEI provides it at no cost, OSATE offers a low-entry-cost option for tool development, which enables universities to work with AADL and OSATE; the first PhD dissertation with AADL, in fact, was recently completed.

The second aspect is the standard’s inclusion of XMI specification and XML schema definition as part of AADL models. XML provides a common interchange format that allows users to model and validate with AADL and use their in-house analysis tools, commercially provided tools, and research prototypes. Commercial tool sets like STOOD from ElliDiss (in use at Airbus and ESA) include AADL support.

Predictable Runtime Behavior

The AADL standard and the tool support it encourages have been and will continue to be developed in response to user needs. Consequently, organizations can view adoption of the AADL standard as a good investment. By adopting a model-based engineering environment in which the AADL is used to specify embedded-system architecture, organizations create the basis for predicting the runtime behavior of system-level critical qualities such as performance, safety, reliability, time criticality, security, and fault tolerance.

Analyzing runtime behavior of embedded software is important, whether that behavior determines the guidance of a missile or an aircraft . . . or the ability of the antilock brakes on your family sedan to operate under all conditions.

For more information, contact—

Peter Feiler
Phone: 412-268-7790
Email: phf at sei.cmu.edu

Bruce Lewis
Email: bruce.a.lewis at us.army.mil

Listen to more about the AADL at http://www.ddj.com/dept/architect/184411266.

1 Model-driven architecture (MDA) and model-based engineering (MBE) are considered to be synonymous. For more information on model-driven architecture OMG Model Driven Architecture Web site.

2 A Honeywell Laboratories data sheet titled The MetaH AADL Toolset lists the features and benefits of this language. Go to http://www.honeywell.com/sites/docs/DKRHVMR134XK8DQRHFA5JVOVUZQ23EN0K.pdf.

3 The SAE AADL standard document is available at http://www.sae.org/servlets/productDetail?PROD_TYP=STD&PROD_CD=AS5506.

4 The four annexes are available from the SAE at http://www.sae.org/technical/standards/AS5506/1.

5 Read more about the language introduction at http://www.sei.cmu.edu/publications/documents/06.reports/06tn011.html.

Return to FEATURES list


Terms of Use
Copyright © 2007 Carnegie Mellon University