The Architecture Analysis and Design Language (AADL) is a modeling language that, at its core, allows designers to specify the structure of a system (components and connections) and analyze its architecture. From a security point of view, for example, we can use AADL to verify that a high-security component does not communicate with a low-security component and, thus, ensure that one type of security leak is prevented by the architecture. The ability to capture the behavior of a component allows for even better use of the model. This blog post describes a tool developed to support the AADL Behavior Annex and allow architects to import behavior from Simulink (or potentially any other notation) into an architecture model.

The amount of software in safety-critical systems, such as automotive, aerospace, and medical domains--where failure could result in loss of life--continues to grow in size and complexity. As systems become more complex, the challenges of architecting them continue to grow. In Safety Critical Systems: Challenges and Directions, John C. Knight took note of this trend: "Breakdown in the interplay between software engineering and systems engineering remain a significant cause of failure. It is essential that comprehensive approaches to total system modeling be developed so that properties of entire systems can be analyzed. Such approaches must accommodate software property and provide high fidelity models of critical software characteristics."

Many software projects capture the behavior of components using state machines or use-case diagrams. These descriptions support development efforts, either as a specifications document or as inputs for code generators. They focus only on one component, however, and do not take into account the execution environment such as the hardware platform, communication buses and potential concurrent use of resources or the integration with other architectural elements such as connections with other components, etc. Below we describe how a tool developed in accordance with the AADL Behavior Annex can support these capabilities.

Foundations of Our Approach

Integration issues account for more than 70 percent of software defects. As behavior is a key aspect of the system, it is crucial to analyze the impact between behavior specifications and the overall architecture. Most modeling techniques focus on behavior (which involves what the system is supposed to do) for design and implementation purposes. If such notations accurately detail behavioral aspects, then they do not incorporate the execution environment (which involves how the service is provided). This omission makes it hard to analyze the interactions and dependencies between system functionality and its execution environment, which is of primary importance because one aspect can impact the other. (For example, a task may request a resource being already locked, leading to an expected delay or a timeout.

In contrast, AADL allows architects to specify the structure of the system as well as the system's execution environment. The remainder of this blog post, therefore, describes research aimed at integrating a behavior description (what the system performs) into the execution environment defined in AADL (how the system performs the functions: deployment of system functions on processors, buses, etc.).

AADL provides mechanisms to extend component specifications, including user-defined properties and annex languages. While user-defined properties are an extension mechanism to describe non-functional properties and is semantically limited, the annex language allows architects to associate third-party languages to a component to specify various aspects. Several annex languages have been proposed such as the error-model annex, which allows for the specification of errors and faults that occur within a component or that may propagate across the architecture. The behavior annex brings into the overall architecture the ability to describe the behavior of AADL components as well as their interactions.

SAE International, formerly the Society of Automotive Engineers, published the AADL Behavior Annex language extension to describe component behavior in terms of a state machine that interacts with component members (i.e., modifying data when the component is in a specific state) and interfaces (i.e., sending data through a port when the component is in a state or triggering a state transition upon a specific event received on an AADL event port).

The behavior annex is currently being revised and improved by SEI researchers. Revisions include adding the ability to connect behavior specifications with other annexes such as the error-model annex. By connecting component descriptions, analysis tools can then show the impact between different aspects of the model (e.g. behavior and error specification). This modification would provide architects greater insight into the impact that component behavior can have on other system attributes. For example, this approach will allow architects to visualize how a task activation or communication delay can generate an error that could be propagated through the rest of the architecture.

The behavior annex is now included in the Open-Source AADL Toolset Environment (OSATE).Télécom Paris Tech, an engineering school that has been involved in AADL development for several years, played a significant role in incorporating the behavior annex into the OSATE framework. The behavior annex language is being used in OSATE extensions for research projects such as the System Architecture Virtual Integration (SAVI) program, which was undertaken by the Aerospace Vehicle Systems Institute. To read more about the use of AADL in the SAVI program, which was a recent post in our ongoing series on AADL, please click here.

Adding Behavior to the Execution Platform

The AADL Behavior Annex augments system architecture description for a better design and more accurate analyses. From a security perspective, for instance, component behavior specifies the communication policy so that analysis tools can check that all channels exchange data at the same classification level. For example, if a component has two communication channels--one for highly secured data and another for low-secured data--the behavior description will specify which one is used to send data, thereby avoiding an important type of security leak.

Such validation is infeasible with existing tools because they do not provide the appropriate semantics to capture these aspects. The loose coupling of notation and analysis tools makes it hard to analyze a system's behavior within its execution environment. Integrating these notations in a single model helps address these issues and provides better end-to-end system analysis.

In the previous post in our series on AADL, we explored the use of AADL in several application domains such as aerospace and aviation as well as projects to specify cyber-physical systems. Current projects focus mostly on defining the system architecture. For example, these projects define functions such as temperature readings and how they are realized (using a dedicated device or sensor) and inter-connected (a shared bus between the sensor and the computer receiving and processing temperature values).

Until recently, however, AADL specifications did not describe how they perform their designated functions. Our latest work, therefore, augments the existing language so that users can associate behavior specifications with each hardware and software component. This capability will integrate another part of the component description and extend potential analysis so that tools can find more issues or refine actual diagnosis of system defects.

Integration with Other Behavior Specification

Several methods and tools already exist to specify component behavior. For example, Simulink or SCADE provide architects the capability to define state machines that characterize how a component processes data and produces its outputs. Thus, when a user establishes the AADL behavior of a component that has already been defined with another language, the following question is raised:

Is the AADL behavior consistent with the other specification?

Indeed, one has to ensure that both behaviors (the AADL model and a second language) are consistent to assure model correctness and consistency. This assurance increases confidence that verification done using the AADL model are applicable to other notations, as well. For that purpose, as shown in the picture below, current research efforts aim to

• automatically generate AADL behavior specification from existing behavior model
• validate an AADL behavior specification according to a behavior model defined with another notation

These two different methods to connect behavior specifications (from AADL and other languages) will help engineers ensure correct specifications. In addition, ensuring correctness and consistency in behavior specifications will help architects avoid discrepancies between different behavior specifications, ensuring that the behavior description is actually what is specified in other models and not what the engineer wants to expose.

The approach shown in the picture above would avoid any mismatch of behavior specifications, especially if the models are developed by different engineers (i.e., one who makes the AADL model and another who focuses on behavior specification using another language). Likewise, generating AADL behavior specification from existing models would encourage engineers to integrate the behavior description in their architecture model by reducing the learning curve.

These new methods are being implemented as part of OSATE and are already released under an open-source license in the testing branch. Interested users can already use them by downloading our testing release.

Wrapping Up and Looking Ahead

Current research efforts from the SEI and its collaborators aim to refine and improve the AADL Behavior Annex to provide a better and more accurate description of components behavior (e.g., by providing the ability to associate behavior for system or process components, a feature not currently allowed by the current standard). As part of this effort, SEI researchers are also working on methods to connect the AADL behavior specification with existing behavior models used in industrial projects.

Our research and development activities are yielding an improved method and a set of open-source software components that integrate behavior in the architecture, thereby extending the description of the system and providing more information that can be analyzed and processed by analysis tools. The results of our work should help architects detect more issues when integrating components and support design and analysis. In future work we plan to investigate impacts of behavior aspects over system quality attributes (such as performance, safety or security). AADL can capture all these aspects in a single notation. This capability provides necessary information to help designers reasoning about several architecture variances and choose the most appropriate according to their business goals.

We welcome your feedback on this research effort. Please leave us feedback in the comments section below.

Additional Resources

For more information about AADL, please visit
www.aadl.info and our wiki https://resources.sei.cmu.edu/aadl-wiki.cfm