Architecture Analysis and Design Language

Architecture Analysis and Design Language:

An Overview

Drew Gardner

CSC 532

October 19, 2011

Objective

The purpose of this report is to provide an overview of the Architecture Analysis and Design Language (AADL) including but not limited to descriptions of the following: its history, its purpose, its design, its usage, and its application.

AADL

Background

The design and production of a large software application is a long and complicated process involving many people. A standard way to communicate product design and architecture is needed to maximize understanding and limit the cost incurred by implementation errors. For example, in 2002 a National Institute of Standards and Technology study found that “software errors cost the U.S. economy $59.5 billion” per year. [1] Even though errors cannot be guaranteed to be completely eliminated, their occurrences can me mitigated through the use of architecture modeling methods. UML, or Unified Machine Language, provides a diagrams framework for modeling generic system interaction and function. AADL is similar to UML, but with a more focused application area and different usage scheme.

“SAE [Society of Automotive Engineers] AADL is an international standard for predictable model-based engineering of real-time and embedded computer systems.” [7] A real-time system is one where operations must be completed in a certain amount of time to avoid product failure or some external consequence. An embedded system is one that is contained within the hardware and is not immediately obvious to a user. Many medical devices, vehicles, and household appliances hold real-time embedded systems. [8] Unlike UML, AADL does not work primarily as a set of diagrams, but rather as a programming language. As a result, it is less ambiguous than UML and when written correctly, easier to understand. Originally called the Avionics Architecture Description Language (its original application area), AADL was derived from a similar modeling language called MetaH. [1] As a programming language (though probably not Turing complete) AADL can be compiled to check for correctness and then automatically converted into diagram form or source code. One such open source compiler is the Ocarina compiler for Windows, Linux, and Mac.

Hence the original name, AADL is widely used in the design of avionics systems [9] around the world. It is especially useful in modeling error control and recovery. [1] Basically, any constrained computing environment could benefit from the use of AADL in the early design workflow. [5]

Design

AADL appears and functions like a program, except one that is primarily limited to prototype and class declarations. Included in its semantics are representations of both software and hardware components. In addition, annex libraries provide extensions to the core language. [5] One such annex is the error annex, which provides features relevant to system dependability evaluation and error handling. [6] There are three categories of abstraction elements in the standard AADL: software, hardware, and a composite category. The remainder of this section comes from the introductory guide to AADL, reference 4.

The five software abstractions are thread, thread group, process, data, and subprogram. The software components are rather straightforward. A thread corresponds to a typical thread in a program, a concurrently executing component. A process corresponds to an actual process, with an emphasis on the encapsulation of the process in a protected address space. A data component represents a data field or type in the source code. A thread group organizes threads and data into a single component contained within a process. A subprogram represents an executable function or method.

The hardware components are as follows: processor, memory, device, and bus. Again, these correspond fairly straightforwardly to their physical namesakes. The processor component is an abstraction that schedules and executes threads. The memory abstraction stores code and data. The device abstraction represents peripheral components that interact with the external environment, such as sensors or keyboards. The bus component provides connections between processors, memory, and devices.

There is only one composite component. A system is an early abstraction used to generalize a conglomeration of software and hardware components (and other systems). For example, a database server might be represented externally as a system. Figure 1 provides the diagrammatic forms of the AADL components outlined above.

Figure 1. The three categories of AADL abstractions and their subcomponents. [4]

In addition to the components described thus far, Figure 1 implies at least one more component; namely, a package. A package acts as a namespace to bundle multiple components into a single abstraction and allow components in different packages to share the same name.

Figure 2 gives the standard form for the declaration of a component type.

Figure 2. The form for declaring a component type.

Component_category is a placeholder for one of the component abstractions given above, such as device or process. All but the first and last bold clauses are either optional or dependent upon the component type. The extends keyword provides functionality for inheritance and superclass/subclass relationships. Type_identifier is the name of the component, such as mergeSort if the component is a subprogram. Features is followed by a list that indicates which components this component interacts with, including specifications for input and output. Flows provide steps in a control flow through this component, such as where control came from and where it will go. Properties specifies component wide properties (like class properties) that apply to all components of this type (objects) unless overridden. This is all followed by the end keyword, terminating this component declaration. Figure 2 provided, in effect, the AADL specification of a component’s interface.

Figure 3 provides the AADL specification of a component’s implementation.

Figure 3. The form for declaring a component implementation.

Implementation_name is formed by appending a period followed by the name of the implementation to the name of the component to be implemented. Again, everything but the first and last clauses is optional. The clause refines type “can be used to add or modify feature property associations of an implementation’s type.” In other words, it is used to modify the properties from the type declaration. Subcomponents refer to other implementations that comprise this one. Calls, connections, and flows each specify ways that this implementation interacts with others. Modes specify alternate states of operation, such as startup, snoozing, and active for a computer system. In effect, implementations are like objects and component types are like classes.

The information presented so far barely scratches the surface of AADL capabilities and specification. For more detailed and omitted information, please refer to [4].

Application

This section will present examples of standard AADL code as well as corresponding explanations and interpretations. Bold words identify a subject that is restricted to the AADL context of the example. Words are only bolded once per paragraph on their first occurrence.

Example 1 provides a simple example of AADL, implementing a process control mechanism (purely software). Not all aspects of this system are present, but it does provide a good demonstration of interacting components. Initially, a component of type control_processing is declared. It is a standalone type that does not extend any others and contains two features of component types sensor_data and command_data, which it respectively gets and sends as its input and output through data ports. Both features are declared at the bottom as data components. So, they are the input and output data of control_processing.

A specific implementation of control_processing is below and is given the name speed_control. Its two subcomponents are threads, meaning that they are part of the process that takes action in some way. In this case, they are again implementations, and they handle the input and output outlined in the type declaration. This indicates that implementations interact with implementations, and types interact with types.

The threads, like the data, have empty type declarations. Since the thread types are not explicitly used anywhere, this indicates that a type declaration is required before an implementation declaration.

Of course, this is all rather straightforward from a basic understanding of object oriented programming. The novel thing is that AADL is not object oriented programming, but descriptions of software and its interaction with disparate system parts. If the example were extended, one would expect to see device types appear as features of the two threads (sensors perhaps). A diagram form of this example is given in Figure 4.

Example 1. Sample AADL code (incomplete) of a process control mechanism, demonstrating the standard form declarations in action. [4]

Figure 4. Diagram of the AADL code presented in Figure 4. [4]

The next example is given in Example 2 and depicts the code and diagram of an end to end flow in a more complicated architecture, part of a vehicle. An end to end flow is one that is entirely contained from start to finish within a component. In this case, it is contained in the system implementation complete.impl. The system implementation includes multiple subcomponents, including two devices and one system: a brake pedal, throttle, and cruise control. Two connections through ports are made between the devices and subsystem. Note that the connection is made to a feature in the brake pedal. The brake pedal contains the event keyword, which indicates a triggered action. This triggered action initiates the end to end flow of data float_type from brake_pedal through connection C1 to cruise_control and then to throttle_actuator through connection C2. In English, braking causes the cruise control of the vehicle to respond and slow the vehicle down. In brake_pedal, the clause flow source indicates that the end to end flow begins there, whereas in throttle_actuator, the clause flow sink indicates that this is where the flow terminates. Note also that in and out clauses must be present and matched for the code to be valid. Some new diagram symbols are used to represent the flow. The solid arrowheads are ports, while the decorated arrowheads are event data ports.

Example 2. Code and accompanying diagram of a simple end to end flow. [4]

Finally, Example 3 will demonstrate the error model annex extension of AADL.

Example 3. Simple code for error modeling in AADL. [6]

This annex adds a new component type to AADL as well as several new keywords. Basically, this code describes two error events with differing rates of occurrence and the transitions from error state Error_Free to error state Failed and vice versa. The error events are triggered by the propogation Software_KO, which can come in and go out of the component. This indicates that the failure of one component could cause others to fail if they are linked. Analyzing the model could yield knowledge about the dependability of the system.

Conclusion

This paper presented a brief introduction to the Architecture Analysis and Design Language, describing its origins and basic implementation and features. In addition, one annex to AADL was presented and sample code interpreted. Due to its niche nature, it does not directly compete with UML but complements it instead. Given its unambiguous nature, wide array of features, and the fact that it can be compiled and translated into code, AADL seems a worthy addition to any analysis and design workflow.

References

1. De Niz, Dionisio. Diagrams and Languages for Model-Based Software Engineering of Embedded Systems: UML and AADL. Software Engineering Institute. Carnegie Mellon.

1. De Niz, Dionisio. Aspects in the Industry Standard AADL. Software Engineering Institute. Carnegie Mellon.

1. Feiler, Peter H. Gluch, David P. Hudak, John J. Lewis, Bruce A.Embedded System Architecture Analysis Using SAE AADL. Software Engineering Institute, Pittsburgh, PA, 15213 USA. June 2004.

1. Feiler, Peter H. Gluch, David P. Hudak, John J. The Architecture Analysis and Design Language (AADL): An Introduction. Software Engineering Institute. Carnegie Mellon. 2006.

1. Hecht, Myron. Lam, Alex. Vogl, Chris. Application of the Architectural Analysis and Design Language (AADL) for Quantitative System Reliability and Availability Modeling. International Symposium on Software Reliability Engineering Briefing. November 2009.

1. Rugina, Ana-Elina. System Dependability Evaluation Using AADL (Architecture Analysis and Design Language). LAAS-CNRS, Toulouse, France.

1. SAE Architecure Analysis & Design Language: Fact Sheet. Software Engineering Institute. Carnegie Mellon.

1. Silberschatz, Galvin, Gagne. Operating System Concepts. 8th ed. John Wiley & Sons. 2009.

1. Sioutis, C. Nguyen, T. Modelling Airborne Mission Systems using the Architecture Analysis and Design Language. Defence Science and Technology Organization, South Australia. 13 July 2009.