Use AADL to analyze and design embedded systems - Embedded.com

Use AADL to analyze and design embedded systems

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

The system construct can model the whole system and the core subsystem (the video detection system). The AADL device construct can represent physical components, such as the video cameras and display, where we don't need to bind application software. We use a port group and connections to model the communication among different components. The data stream from the cameras comes through the video detection system.

AADL can describe the system in different levels of detail, by using the hierarchical structure. Figure 2 shows the context of surveillance application at a high level. After modeling the architecture, we must specify different components in detail. Before going through the design details, let's look at the basic elements in AADL. The software components include the process, thread, thread group, data, and subprogram. They are defined as:

Process: a protected address space

Thread: a unit of concurrent execution

Thread group: a compositional unit for organizing threads

Data: data types and static data

Subprogram: callable sequentially executable code

View the full-size image

In Figure 2, we use the software components process, data, thread, and system components to model the video detection system's logic. Note that this model is just one step forward from the previous context diagram shown in Figure 1.

The hardware components (also called platform categories ) include the processor, memory, bus, and device. In Figure 3 (under AADL constructs), you see the AADL standard graphical representations for hardware components. They describe the system's physical features. In the surveillance-system model, the hardware platform is specified by the CPU (processor), memory, and bus.

View the full-size image

Component abstraction includes features, properties, and modes. Features define the interfaces or the exported component functions. Properties represent attributes and component behaviors. Modes describe the dynamic component reconfigurations.

Component interactions
After defining the components, we need to specify the relationship among them. AADL supports this process in a natural way. Component interactions use ports (data and event inputs and outputs), port groups, subcomponent access, subprogram calls, data exchange, and sharing. They define the functional interfaces and communication among components. In Figure 2, we used the data port to describe the interactions among the system and devices.

A key feature of AADL is its ability to model data and control flows. A flow defines the sequential data or events through several components and connections. In our example, we specify three flows for three video cameras: video_flow1, video_flow2, and video_flow3. These flows represent end-to-end flows from the cameras to the display.

We define these flows because they're separated by location. The goal of flow specification is to support end-to-end analysis, such as end-to-end timing and latency, error propagation, and quality-of-service resource management. The properties of a flow define the performance features. For example, in the surveillance system, the flow-specific property is expected maximum latency. It will be checked against the actual implementation to decide whether the design goal is satisfied. For each end-to-end flow in this system, there's a property that defines “expected latency equals 200ms.”

A powerful characteristic of AADL is its ability to model hardware and software together for a target system. This helps the modeler specify and evaluate the interactive effects of the complete system. In our example, the choices of video cameras, radio transceivers, and processors directly effect the end-to-end latency.

Complete system model
Figure 3 shows the AADL design of the wireless surveillance system, with hardware and software. The system communicates with the cameras over the wireless network, through the radio device. The software components are bound for execution to the processor(s) in accord with scheduling properties and are bound to memory for storage. The protocols are reflected as properties on a bus and feed through to analysis tools. Different bus types, such as PCI or VME can be defined, including the protocol and performance characteristics of those standards. We can also define a customized bus, Wireless, which models the features of the CSMA/CA wireless link.

Because we've described one of our performance-critical features using timing semantics with the flow specification, we can evaluate system-level performance. Other architectural detail or properties can be incrementally added to expand the forms of analysis as we determine what's critical. We can also evaluate it during all the development stages, including early architectural trade-off analysis, system tuning and adjustment during development, evaluation of impact of change to existing architectures, and automated integration based on performance models. Thus we can evaluate using a component-based architecture spec, along with the tradeoffs in each available dimension of change. We can experiment with hardware and software components, communication models, scheduling, error modeling, modal dynamics, and so forth, and integrate the results. The language is also extensible for integrating additional modeling and analysis capabilities.

Tool support
Many tools support AADL architecture design and analysis. The Open Source AADL Tool Environment (OSATE) is a set of plug-ins on top of the open source Eclipse platform (www.eclipse.org). It provides an integrated development environment for AADL model editing, compiling, and front-end analysis. In addition, it includes the graphical editor for AADL notations using the TOPCASED plug-in. Several analysis plug-ins have been developed for performing various architecture consistency checks, flow and dependability analysis, data quality and security analysis, and resource scheduling. Details of those tools can be found at www.aadl.info.

Hui Cao worked as an intern at the Eaton Innovation Center. His research focuses on dependability of wireless sensor networks. Currently, he is a Ph.D student at Department of Computer Science and Engineering at Ohio State University. He can be reached at .

Ting Yan is a lead engineer in the Embedded Systems and Communications group at the Innovation Center of Eaton Corporation. He received his Ph.D degree in computer science from the University of Virginia. He can be reached at .

Luis Pereira is an embedded systems architect in the Embedded Systems and Communications group at the Innovation Center of Eaton Corporation. He can be reached at .

Sujit Das is the technology manager in the Embedded Systems and Communications group at the Innovation Center of Eaton Corporation. He can be reached at .

Bruce Lewis is a senior experimental developer for the U.S. Army's Aviation and Missile Command, Research, Development and Engineering Laboratory, Software Engineering Directorate (SED). He can be reached at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.