The architecture description language is suited for systems with challenging resource constraints and strict real-time requirements.

When designing mission-critical and real-time systems, designers must satisfy both functional requirements and nonfunctional attributes, such as performance (throughput and quality of service), safety, reliability, time criticality, security, and fault tolerance. These system-level features are decided by the system architect. With the increasing hardware diversity and complexity of embedded software systems, a model-driven development approach has become a viable method to address system-integration issues in the early stages of development. One key aspect of model-based development is selecting the appropriate design language to represent the platform-specific architecture.

To tune a system architecture, the design language must support multiple analysis approaches so trade-offs can be made across domains. An architecture design language must also support incremental analysis during the development and multiple levels of fidelity for system evaluation. This incremental aspect allows the architecture specification to be used throughout the lifecycle. AADL (Architecture Analysis and Design Language) is a standard, extensible architecture-description language that satisfies these requirements.

AADL is suited for embedded systems with challenging resource constraints (such as size, weight, and power), strict real-time requirements, and/or high assurance levels. Intended applications include surveillance, avionics, flight management, engine and power-train control, medical devices, industrial process-control equipment, and aerospace.

AADL is developed under the guidance of the International Society for Automotive Engineers (SAE) and has been approved as industry standard AS5506 (November 2004). To support performance analysis, AADL defines timing semantics; to support dependability analysis, it includes an error modeling annex as part of a larger set of annexes contained within AS5506/1, which enables the expression of error models for each component.

Compared with other modeling languages, such as SysML and UML, AADL provides strong semantics for standard categories of hardware and software components so that common analysis approaches and well-defined system integration can be accomplished from the specs. The language, designed especially for embedded systems, is extensible through user-definable properties (supported with a property sublanguage checked by AADL compilers) and through user-defined annexes. Annex extensions can be standardized for industry-wide use. In addition, with operational modes, AADL can also support system-dynamics modeling.

The AADL supports model interchange and tool chaining based on a standard XML/XMI definition. The language has a standard meta-model, graphical definition, and textual language. An AADL UML 2.0 profile has been developed and has started into ballot. An annex for ARINC 653 architectures has been started. A number of toolsets support the language, many of them open source. An important one is the Open Source AADL Toolset Environment (OSATE). OSATE is based on the Eclipse framework and includes textual, XML, and graphical editors as well as a number of analysis tools. These tools are open-source Eclipse plug-ins and can be extended (see the AADL website, www.aadl.info, for a current list).

Surveillance-system design
In this example, let's first look at the user requirements. The user wants to install a surveillance system to monitor three houses far from the office. No local networks are available in those locations. To effectively prevent intruders, the detection must be quick, in less than two seconds. This latency spec is an end-to-end, system-level performance requirement.

One solution is to deploy three web cameras to monitor these houses. The cameras will send information to the computer in the office building wirelessly. However, the limited bandwidth of wireless communication can't accommodate all the video-stream data. Hence, we'll need to embed a video processor onto each camera to compress and preprocess the stream, but this may affect the end-to-end latency. We must evaluate different hardware choices, such as the video processor and the radio ICs. We also want to try several compression and intruder-detection algorithms. AADL simplifies this process by keeping us focused on satisfying the system-performance requirement.

The next step is to define the architecture. The AADL graphical notation can help with this, as shown in Figure 1. Note this model isn't designed on the fly; rather it's a formal model with clear definition, even at a high level of abstraction.

View the full-size image