The size and complexity of aerospace software systems has increased significantly in recent years. When looking at source lines of code (SLOC), the size of systems has doubled every four years since the mid 1990s, according to a recent SEI technical report. The 27 million SLOC that will be produced from 2010 to 2020 is expected to exceed $10 billion. These increases in size and cost have also been accompanied by significant increases in errors and rework after a system has been deployed. Mismatched assumptions between hardware, software, and their interactions often result in system problems that are detected only after the system has been deployed when rework is much more expensive to complete.

To address this problem, the Society of Automotive Engineers (SAE) released the Architecture Analysis & Design Language (AADL), which helps software and system architects address the challenges of designing life- and safety-critical systems by providing a modeling notation with well-defined real-time and architectural semantics that employ textual and graphic representations. This blog posting, part of an ongoing series on AADL, describes the use of AADL in the aerospace industry to improve safety and reliability.

The Evolution of AADL

The SEI has been a leader in the development of AADL and has participated on the AADL standardization committee since its inception. Likewise, several projects have used AADL to design software architecture and analyze, validate, or improve various quality attributes, such as reliability, latency/performance, or security.

While AADL was initially conceived for use in avionics, this blog series has demonstrated its applicability in other domains that rely on life- and/or safety-critical systems, including the medical domain. This post focuses on the evolution of AADL from its initial foundations (covered in our previous blog posting) to its use in the System Architecture Virtual Integration (SAVI) project.

SAVI is part of the collaborative and applied research performed by an aerospace industry research cooperative known as the Aerospace Vehicle Systems Institute (AVSI). SAVI is a multi-year project separated into different tasks that aim to improve system and software development and significantly reduce development costs through the early discovery of what will eventually become integration issues. Each sub-task addresses a particular issue companies are actually struggling with. The remainder of this post shows how the design rationale of AADL fits with SAVI's goals and describes the uses of AADL within the project to improve software safety and reliability.

A Focus on Safety

A major integration challenge in fielding aerospace software systems stems from safety requirements. Detecting and analyzing faults/errors within a component can prove demanding for software architects. These tasks are especially hard during component integration, when it is necessary to understand how the faults would propagate among the architecture without testing or simulation. This challenge served as a catalyst for the development of demanding certification standards such as DO178C, also known as "Software Considerations in Airborne Systems and Equipment Certification."

SEI researchers, led by Peter Feiler, a senior member of the technical staff and author of AADL, made the decision to document the benefits of the architecture model and bind safety-related specifications (such as faults occurrence and propagation across the architecture) to the architecture model. As Bruce Lewis--an experienced software practitioner working for the U.S. Army Aviation & Missile Research at the Development & Engineering Center (AMRDEC) in Huntsville Alabama and a key player in the development and evolution of AADL--reported:

The error models are placed on components, but when we integrate the components, we know what kinds of errors they can accept on their input and what kinds of errors they can propagate out. Then we can do an integration of error models to actually look at how errors might propagate to the system.

SEI researchers extended AADL to describe system faults and analyze the safety of systems. This work consisted of two parts:

1. enhancing the core of the technology with an updated sub-language (the Error-Model Annex Version 2, an AADL annex being standardized by the SAE) to better describe architecture safety concerns
2. developing new tools to process this additional information within the model, validate system safety, and help engineers produce documents for validating the system

These enhanced capabilities enable AADL users to augment their software architectures with fault description and specify error source and propagation across hardware and software components. These enhancements can also be used to improve system validation and detect faults that are potentially overlooked during the initial development process and that may lead to errors. These safety analyses can now be evaluated incrementally as the architecture is refined during the development process, again permitting early discovery of issues and reducing manual effort.

A Safety-Dedicated Sub-language for AADL

To improve system validation and detect faults, an updated annex language has been proposed by the SEI and is currently under review by the AADL Standardization Committee. The effort involved contributors from several companies and domains, and was intended to make the document more user friendly for safety analysts. SAE will publish this addition to the core AADL language in the coming months as an official standard annex. In addition, the SEI will publish technical reports to present this sub-language and demonstrate its use on real systems, such as the Wheel Brake System example. This example (originating from the SAE AIR6110 standard that demonstrates the safety validation process for the avionics domain) demonstrates the relevance of our approach and that the approach scales with current industrial practices

Researchers from the SEI also recently enhanced the AADL reference environment, OSATE, to analyze system safety and produce documents required by safety evaluation standards, such as SAE ARP4761. For now, the toolset provides several functions that allow software engineers to extract safety-related information from an architecture model and show the impact of a fault in documents, such as

• Functional Hazard Assessment provides a list of faults with their description, reference to design document and severity classification
• Fault Tree Analysis provides a hierarchical description of fault dependencies.
• Failure Mode and Effects Analysis provides a list of all faults with their propagation paths across the architecture.
• Reliability Block Diagram provides an analysis that evaluates the failure probability of a component according to its failure events and incoming error propagations.

These functions have been demonstrated in the context of the SAVI project. Also, as these functions can be interfaced with open-source tools that are available at no cost, they can be tested using the public release of OSATE. In that context, the SEI researchers detailed how to reproduce the demonstration using a public model of the Wheel Brake System from the SAE AIR6110 standard.

Beyond Safety: Analyzing System Behavior

The next iteration of SAVI will focus on system behavior. Many projects from the avionics or aerospace communities reuse software and hardware components from different projects, trying to reduce new development and take advantage of existing components. When software and hardware components are integrated, however, tests show that behavior discrepancies can generate issues that were not predicted in their initial execution environment. For example, different development teams may use different assumptions regarding quality attributes (such as timing, resources dimensions, etc.) resulting in issues (late arrival of data, insufficient computing capacity, etc.) during integration. This discrepancy may lead to significant increases in testing efforts and development costs as well as a postponement in the delivery of the system.

To overcome these issues, SEI researchers are working to extend AADL by integrating component behavior descriptions into a new "behavior annex." This new addition to the AADL language would provide software architects with the ability to describe the software behavior in terms of modes (operational, failed, degraded, etc.), states (running, idle, waiting for inputs, etc.) and operations (call to system functions or subprograms, send/receive values from interfaces, etc.). This additional architecture information would also allow architects to check the consistency of integrated components behaviors and detect potential defects or requirements mismatches. Part of this work may lead to the development of analysis tools that will integrate an existing behavior specification (such as state machine) into an architecture model and detect potential defects.

Our next post will present the actual outcome of this work and the envisioned tool support.

Additional Resources

To view the AADL Wiki, please visit https://resources.sei.cmu.edu/aadl-wiki.cfm

For more information about AADL, please visit http://www.aadl.info

To read the SEI technical report, System Architecture Virtual Integration: An Industrial Case Study, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9145