Using the Architecture Analysis & Design Language (AADL) modeling notation early in the development process not only helps the development team detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our recent blog posts and webinar have shown how AADL can identify potential design errors and help avoid propagating them through the development process, where remediation can require massive re-engineering, delay the schedule, and increase costs.

Verified specifications, however, are still implemented manually, which can lead to additional errors and might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. This blog post focuses on generating code from AADL and generating configuration files for ARINC653 systems, which are used by the avionics community.

Avionics and other safety-critical systems are becoming increasingly reliant on software. For example, the F-35 Lighting II is a fifth-generation fighter jet that contains more than 8 million lines of software code (LOC), four times the amount of the world's first fifth-generation fighter, the F-22 Raptor. This upsurge in software reliance motivates the need to verify and validate requirements early in the software development lifecycle, as requirements errors are often propagated from the design phase to the implementation phase. The remainder of this blog post gives examples of how AADL is being used to generate code for software-reliant avionics systems.

AADL Model Overview

AADL was approved and first published as SAE Standard AS-5506 in November 2004. Version 2.1 of the standard was published in Sept 2012. AADL uses the Open Source AADL Tool Environment (OSATE), an Eclipse-based modeling framework, to design, validate, and analyze AADL models. AADL is designed for the specification, analysis, automated integration, and code generation of real-time distributed computer systems with performance-critical requirements such as timing, safety, schedulability, fault tolerance, and security. AADL provides a new tool set to allow analysis of system and system-of-system designs prior to development and supports a model-based, model-driven development approach throughout the system lifecycle.

As described in our earlier blog posts, AADL can lower development and maintenance costs by

• providing a standard, precise syntax and semantics for performance-critical systems, so that documentation can be well defined
• providing the ability to model large-scale architectures from multiple contractors in a single analyzable model that can be incrementally refined
• capturing the "architectural API (application programming interface)" needed to evaluate the effects of change, such as the emergent properties of integration (e.g., safety, schedulability, end-to-end latency, and security)
• allowing early and complete lifecycle tracking of modeling and analysis
• complementing functional simulation with analysis of system structure and runtime behavior
• providing the basis to establish a reference architecture and support product lines

ARINC 653 Overview

ARINC 653 (Avionics Application Standard Software Interface) is an avionics standard that defines the execution platform of software that focuses on safety and determinism. ARINC653 executes software components in separated partitions so that an error that occurs within one partition cannot impact the others. This isolation is done at two levels:

• Time: Each partition has a fixed, preconfigured execution time slot and cannot overuse it.
• Space: Each partition has a memory segment to store its code and data.

Partitions can communicate only with predefined and configured communication channels, and any attempt to open an unspecified channel raises an exception. The ARINC653 standard specifies an API to create and manage software resources so that a software developer can switch from one operating system (OS) to another without significant development effort.

ARINC653-compliant systems must be carefully designed to ensure that resources are correctly configured and allocated to partitions. For example, system integrators must check that a partition's execution time is sufficient to execute system tasks or that no other communication channel will disturb the execution of critical functions. These stringent resource management requirements motivate the need for carefully specifying partitions with appropriate notation--such as AADL and its annex dedicated to ARINC653 systems, the ARINC653 annex--and analyzing to make sure that they meet designers' requirements (time, safety, etc.). Ultimately, the models should be automatically processed by dedicated tools to configure the ARINC653 platform, avoiding hazardous manual activity, such as translating textual specifications to code.

Using AADL to Generate Code for Avionics Systems

Our work in the area of avionics systems focuses on generating code from AADL, which produces code for ARINC653 systems from verified models. Our approach generates the code for the different layers of the system: the ARINC653 module, which ensures time and space isolation of partitions, and its associated partitions, which contain resources to execute functional code. Auto-configuring the system from the models allows developers to use the same models for other analyses. Ultimately, automatically deriving the implementation code from the architecture model ensures that the implementation will comply with other generated materials. Moreover, auto-generating the code avoids errors introduced by manually written code.

OSATE is able to generate ARINC653-compliant C code from the AADL model using a bridge to the Ocarina code generator. The generated code creates all the resources of a partition--including tasks, mutexes, and communication channels--that execute the functional code, whether it is designed using pure C code or functional modeling languages such as SCADE or Simulink.

In addition to creating the partition code, OSATE can configure the underlying separation kernel to execute each partition--such as the scheduling parameter and inter-partition communication channels--at runtime. OSATE, and its Ocarina bridge, is able to generate the configuration file for two ARINC653 systems: DeOS and VxWorks653.

By auto-producing the ARINC653 configuration artifacts, the user no longer needs to configure anything manually, which avoids traditional development errors such as misunderstanding requirements or specifications and making manual coding errors. In addition, using the same model throughout the development process ensures that the configuration file reflects the architecture that was validated and analyzed during previous development steps.

Two AADL Code Generation Case Studies

AADL models are edited with the OSATE toolset, and the code is generated using the Ocarina AADL code generator tool. We integrated the generated code from models into two commercial ARINC653 operating systems:

• Deos from DDC-I
• VxWorks653 from Windriver

Our intent was to automate the code production from the AADL models. Once AADL tools have validated the models, the system can be automatically deployed on top of different operating systems while preserving the characteristics that AADL validated when it analyzed the model.

The remainder of this post describes our two applications:

• The ADIRU Example: generating ARINC653 XML configuration and C partition code from AADL
• The SCADE Example: generating code from functional (SCADE) and AADL models and integrating functional models with code generated from AADL models

We applied both operating systems on these applications to demonstrate the capability of AADL to generate code on a variety of OS platforms.

The ADIRU model represents an air data inertial reference unit (ADIRU) system and tries to reproduce a faulty component. The model has been presented to an AADL committee meeting, and the slides are available here. The model is composed of four main partitions: one to simulate the sensors, two for health monitoring, and another one for the solver.

We used the AADL model to analyze the ADIRU model and generate the module configuration and partition code. SCADE captures the functional code--the code that corresponds to the subprograms--using C code, and we use the AADL code generator to produce the execution platform code and integrate it into an ARINC653 operating system. Inter-partition communications use AADL data and event data ports, which are translated into ARINC653 queuing and sampling ports in the ADIRU model.

In the SCADE example, we generated code from SCADE that will be integrated on top of the code generated from the AADL model. The SCADE model is composed of several partitions:

• panel: simulates the joystick and on/off buttons from the panels that are sent to the SCADE node. We use the value 5.0 for the joystick and on for the button.
• sensors: simulate the sensor values sent to the panel. For this demo, we use a value of 500 for the left sensor and ?200 for the right.
• roll control: executes the code generated from SCADE with the inputs from the panel and sensor partitions and then sends the result to the display partition.
• display: simulates a display that shows if there is a warning from the left or right sensor. In the present case, according to the input values, the left-sensor warning should be activated.

The goal of this experiment was to test that the model exhibits the same behavior, such as task execution order and value produced or received, in either the Deos or the VxWorks653 operating system. This assurance is very important because switching from one OS to another can be challenging: each one has specific features (i.e., task scheduling) that might change the execution behavior (task execution order).

Our tool auto-generated the configuration file and preserved the execution semantics of the verified model. This demo shows the correct integration of software models: the values of the system that integrates the SCADE model are the same as the values obtained when OSATE simulated the model, showing a correct integration of the code.

We captured these case studies in several videos to demonstrate the SCADE model, the AADL model, and how to generate and integrate code for both Deos and VxWorks653. Please click here to view the demos.

Wrapping Up and Looking Ahead

The project described in this blog post focuses on auto-generating ARINC653 module configuration and the partitioning of code from verified AADL models. Our approach not only creates the necessary code to configure the execution platform but also integrates functional models (i.e., SCADE), enabling a full zero-code development approach. The ARINC653 system was initially designed with a focus on safety. We are planning to extend and apply this work on a multiple, independent levels of security (MILS) platform, an operating system that implements software isolation for security purposes. Auto-generating the OS configuration ensures the enforcement of the security policy, such as isolation between classified and unclassified data, from the model to the code.

Additional Resources

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

To view our webinar, Architecture Analysis with AADL, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=424907.