Given that up to 70 percent of system errors are introduced during the design phase, stakeholders need a modeling language that will ensure both requirements enforcement during the development process and the correct implementation of these requirements. Previous work demonstrates that using the Architecture Analysis & Design Language (AADL) early in the development process not only helps detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our latest blog posts and a recent webinar have shown how AADL can identify potential design errors and avoid propagating them through the development process. Verified specifications, however, are still implemented manually.

This manual process is labor intensive and error prone, and it introduces errors that 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 summarizes different perspectives on research related to code generation from architecture models.

An Approach to Improve Safety-Critical Process Development

At the ERTSS 2014 conference in February 2014, Jerome Hugues from Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) and Matteo Bordin from AdaCore presented an approach that completely generates a system implementation from models. Their approach relies on various notations--including AADL and Simulink--to capture the different system aspects, such as architecture and behavior. This work is the result of a collaboration between a university (ISAE) and a company (AdaCore) that are both experts in the design and implementation of safety-critical systems. After the conference, I had the opportunity to discuss the project with Cyrille Comar, the cofounder of AdaCore, and Matteo Bordin, a model-based expert at AdaCore, and learn more about this work.

Their approach integrates two different modeling notations to capture system concerns:

1. The architecture is specified using AADL. This architecture defines the execution environment, software deployment, and configuration and includes the number of tasks, allocation to a processor, binding of a connection on a specific bus to transport data, and other specifications. Some people relate to this view as the so-called nonfunctional architecture (how the system provides its functions).
2. The behavior is specified using Simulink, which characterizes how the system processes and uses the data from its environment, for example, to compute new data or activate a device. Some relate to this view as the functional architecture (what functions the system provides).

These two notations are fully integrated: the architecture is the execution support for the behavior. To integrate behavior models, the architecture (the AADL model) contains components (subprograms) that reference the behavior and allocate the functional components into the execution platform.

The ISAE-AdaCore team developed tools--including Ocarina and Project P--that generate and integrate code from AADL and Simulink. Once the tools have generated the code, compilers can link the code together without modification, creating the complete implementation and avoiding any errors related to manual code development. Such an approach removes an important error contributor (i.e., human developers) and is a major step toward improving safety-critical process development.

Why Automate Code Production?

This work relies on AADL because it provides the appropriate semantics to generate code, as Bordin, project manager at AdaCore, explained to me after the conference:

AADL has the main advantage of providing a blueprint representation of a runtime system. This allows translating models to source code without ambiguities and ensures that no semantics are lost during code generation. Of course, the availability of Ocarina was a major plus in choosing AADL.

During our discussion, Bordin also reported that the precise semantics of the language avoids the ambiguity of having multiple notations and diagrams for the same concept:

For this specific project, the only other off-the-shelf alternative would have been OMG MARTE. The main issue we have with MARTE is the ambiguity in representing runtime elements--they can be RtUnit, SwSchedulableResources, etc. Each MARTE tool requires one specific modeling pattern to work. Some tools may require composite structure diagrams, others may require activity diagrams, and others may require sequence diagrams. This means that it is difficult for application developers to easily adapt their modeling standard to tools. In addition, in MARTE it would have been necessary to define our own library of model elements to represent our core building blocks (Ada Ravenscar Tasks), while in AADL it is enough to specify precise properties to achieve the same result. Finally, we are not aware of MARTE-to-SPARK code generators, and we believe SPARK is a major element in our approach.

The development process described above relies on the architecture model as the central artifact for almost all activities (design, validation, analysis, and implementation). For that reason, the selected modeling language must support an accurate and precise semantics to avoid any ambiguity. This is why AADL is appropriate to fill this need.

The study by Bordin and Hugues also shows the relevance of model-based technology and especially AADL through a use case in a production project. A recent paper presented at the 35th International Conference on Software Engineering (ICSE) reported that more than half of developers do not have a real interest in modeling technology, mostly because of concerns with model consistency. For example, one architecture aspect (waiting time on a shared resource) can be represented using different patterns, each one having different and inconsistent characteristics (the timeout to wait for the resource). By using a single notation for driving different aspects of system development (such as validation and implementation), AADL addresses this issue and ensures system consistency (e.g., having the same timeout value) across the development process.

Toward an Optimized System Implementation

The research described in this post is a great step forward in the adoption of model-based tools in operational projects and shows the readiness of model-based methods to automate the implementation of safety-critical systems. By using a full model-based approach from system design to implementation, these tools ensure that validated requirements are preserved throughout the development process and then are correctly implemented.

In addition, system stakeholders can leverage model analysis techniques not only to detect potential architecture defects earlier in the design process but also to optimize the architecture and produce simpler, lighter, and more efficient implementations. In particular, adding a new step in the implementation process, as shown in the figure below, to optimize the architecture by removing useless components or refactoring their interactions would simplify the system implementation and ease its certification. As shown below, the initial model would be processed and automatically optimized by the code generator, creating a more efficient system implementation. For example, if two interdependent tasks are executed on the same processor, one potential optimization would consist of relocating them into one process, removing overhead resources and other related context-switch times during execution. Of course, optimizations would be relevant based on stakeholders' requirements. For example, relocating both tasks within the same process might improve system performance but might be an issue from a security perspective if they contain data at different security levels.

By using a high-level notation that focuses on a system's key quality attributes (e.g., performance, safety, etc.), appropriate tools can analyze the system architecture and optimize it. To achieve such optimization, an accurate semantics--such as the one from AADL, with its specialized components types and properties--is a must. AADL provides the appropriate level of abstraction to simplify the system and eventually its implementation.

Conclusion

The research described above demonstrates that system implementation can be automatically generated from models. Although code generation techniques from models are not new (generation of code skeletons in Java from UML models has existed for several years), this new ISAE-AdaCore project automatically produces a complete system implementation, avoiding errors related to manual code production and potentially improving the certification process.

Model-driven engineering techniques not only help to implement a system but also automatically improve it. By analyzing the architecture, tools can optimize and simplify the system, making the resulting implementation lighter and easier to analyze and certify. Ongoing SEI research efforts will focus on such optimizations techniques to remove some of the usual system complexity and ease the verification and certification of system implementation.

Additional Resources

For more information about the Architecture Analysis & Design Language (AADL) please visit
http://www.aadl.info/aadl/currentsite/.

For more information about the Embedded Realtime Software and Systems Conference (ERTS), please visit
http://www.erts2014.org/.

For more information about UML in Practice, please visit
http://oro.open.ac.uk/35805/.

To read the paper, System to Software Integrity: A Case Study, please visit
https://blog.adacore.com/case-study-for-system-to-software-integrity-includes-spark-2014.

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