Specifying Behavior with AADL

Architecture , Architecture Analysis & Design Language (AADL) Add comments

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien Delange 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.


Chart 1 Specifying Behavior with AADL

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.

Chart 2 Specifying Behavior with AADL Delange

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://wiki.sei.cmu.edu/aadl/

Share this

Share on Facebook Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Save this page on your Google Home Page 

5 responses to “Specifying Behavior with AADL”

  1. Derrick Says:
    An excellent article. How do you think AADL compares to UML? What about AADL compared to Archimate? Also, would you be able to advise on how to adapt AADL to use on application level systems, such as software systems built on .NET employing SOA principles, and running on microprocessors (ie Dell servers) as opposed to embedded systems that use RTOS?
  2. Brian R Larson Says:
    The Behavior Language for Embedded Systems with Software (BLESS) was created concurrently with the Behavior Annex (BA) to rectify shortcomings in BA known at the beginning. Namely, BA was intended to merely "model" behavior, not to actually define behavior.
    BLESS has completely formal semantics, where BA has none, an expressive behavior interface specification language (BISL) for formal specification, and a proof engine that transforms BLESS programs annotated with Assertions as a proof outline into a complete formal proof, with human assistance choosing proof tactics.
    Finally, BLESS was used to define formal semantics of actuators in a SEI tech report last year, and proof of correct operation.
    BA does not need to be "refined and improved" but instead supplanted by BLESS.
  3. Julien Delange Says:
    Dear Brian,

    Thank you for your interest in this blog post. During this effort,
    the main objective was to analyze existing behavior models
    (e.g. Simulink, SCADE) and propose an approach to map their concepts
    within an architecture notation (e.g. use of shared resources) by applying transformation patterns. For example, for mapping data/signals shared between state machines, we use a shared data component. This adds the underlying runtime architecture to the initial functional description so that one can discover potential runtime and integration issues.

    For example, if two state machines that share data are executed in separate tasks without protecting the data with a locking mechanism (e.g. mutex/semaphore), the implementation would then have data consistency and concurrency issues.

    The presented approach uses industry standard notations to represent the task and communication architecture (SAE AS5506B AADL 2004/2012) as well as behavior specification in an architecture-centric way (SAE AADL Modes, and SAE AS5506/1 BA). By using industry standard notations, we also promote model reuse and tool inter-operability.

    Users select AADL-BA compliant tools that fulfill their needs (for example, system verification – with FIACRE/TINA, code generation - with RAMSES, etc).

    SAE AADL and SAE BA have become a platform for applied research
    in architecture-led system specification and verification as evidenced by the large number of publications by academic and industrial research groups around the world (see www.aadl.info/wiki for AADL related publications or Google “AADL”).

    I would like to call attention to three projects in particular that utilize the AADL and BA from a verification perspective:

    1. Filali, Bodeveix, et.al, on Formal Verification of AADL models with Fiacre and Tina -

    2. Renault, Kordon, Hugues on Adapting Models to Model Checkers, A Case Study : Analysing AADL Using Time or Colored Petri Nets -

    3. Miller, Cofer, et.al., on Contract-based Compositional Verification of UAVS from a Security Perspective (see Your What Is My How: Iteration and Hierarchy in System Design, IEEE Software, Feb 2013) -

    This work is done in the DARPA HACMS funded Secure Mathematically-Assured Compositional Control Models (SMACCM) project [http://crisys.cs.umn.edu/smaccm.shtml]

    Please be also on the lookout for additional blog posts on future topics such as survivability by design, architecture-led assurance cases, verification of synchronous system designs, etc.

  4. Julien Delange Says:
    Dear Derrick,

    Thank you so much for your interest in AADL!

    Comparing AADL and UML is quite difficult.
    UML provides several diagrams to represent
    different aspects (each diagram having its
    own representation) whereas AADL maintains
    them in a single and consistent notation.
    Selecting a modeling language will depend on several factors that might have nothing to do with the underlying technology (business goals, objective of the modeling activity, re-use of existing models, analysis capabilities, etc.).

    I recommend having a look at our other blog posts (http://blog.sei.cmu.edu/archives.cfm/category/architecture-analysis-design-language-aadl) to see the capability of AADL or to read the SEI technical report
    that details the fundamentals of the language (http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7879).

    From my understanding, Archimate is an enterprise architecture modeling language that focuses on the business aspects of your system. AADL mostly
    focuses on the software architecture (tasks, subprogram,
    shared resources, etc.) and its deployment on the execution platform (processor, bus, device, etc). AADL was initially designed for representing and analyzing
    software architectures (for example by making performance or safety analysis).

    For a more detailed description of AADL, I would recommend a previous blog post published some months ago: "AADL: Initial Foundations"

  5. Peter Feiler Says:
    We would like to take this opportunity to thank the following people in making the SAE Behavior Annex (BA) standard (http://standards.sae.org/as5506/2/) and its prototype implementation a reality. The prototype implementation is part an OSATE release that integrates a number of capabilities from different sources. This work has its roots in a French industry-driven research study called COTRE.

    The team consisted of Bernard Berthomieu, Jean-Paul Bodeveix, Etienne Borde, Pierre Dissaux, Jean-Marie Farines, Patrick Farail, Peter Feiler, Mamoun Filali, Pierre Gaufillet, Sebastien Gardoll, Serban Gheorghe, Jerome Hugues, Brian Larson, Oleg Sokolsky, François Vernadat, as well as other SAE AADL committee members.

    Bruce Lewis (AMRDEC SED), Chair of the SAE International AS-2C (AADL) Subcommittee, Peter Feiler, Technical Lead of AS-2C.

Add Comment

Leave this field empty: