Introducing new software languages, tools, and methods in industrial and production environments incurs a number of challenges. Among other necessary changes, practices must be updated, and engineers must learn new methods and tools. These updates incur additional costs, so transitioning to a new technology must be carefully evaluated and discussed. Also, the impact and associated costs for introducing a new technology vary significantly by type of project, team size, engineers' backgrounds, and other factors, so that it is hard to estimate the real acquisition costs. A previous post in our ongoing series on the Architecture Analysis and Design Language (AADL) described the use of AADL in research projects (such as System Architectural Virtual Integration (SAVI)) in which experienced researchers explored the language capabilities to capture and analyze safety-critical systems from different perspectives. These successful projects have demonstrated the accuracy of AADL as a modeling notation. This blog post presents research conducted independently of the SEI that aims to evaluate the safety concerns of several unmanned aerial vehicle (UAV) systems using AADL and the SEI safety analysis tools implemented in OSATE.

At the April 2014 AADL standardization committee meeting in Santa Barbara, CA, Jerome Hugues, a professor at the Institue Supérieur de l'Aéronautique et de l'Espace (ISAE) in Toulouse, France, presented a project that aims to evaluate the safety concerns of several UAV systems using AADL and the SEI safety analysis tools implemented in OSATE. This study's results were quite a surprise for us: the study was done independently, without any support from the SEI research team, even when safety analysis tools were under development. More impressive was that the team acquired the basics of AADL and its associated error notation very quickly, created the models for different systems, and generated safety validation materials automatically from the models within a month.

This experiment shows how quick and easy it is to learn AADL and use its associated tools to analyze a system. I wanted to learn more about this project, and Hugues gave me the opportunity to ask him a few questions:

Can you introduce yourself? Please tell us a little bit about where you work and how your organization uses AADL. When and how were you introduced to AADL?

I am an associate professor at ISAE, the reference engineering school in aeronautics and space engineering in France. Since 2010, I have served as co-chair of the Advanced Master on Embedded Systems (SM EMS) program at École Nationale Supérieure d'Électronique, d'Électrotechnique, d'Informatique, d'Hydraulique, et de Télécommunications (ENSEEIHT) and ISAE. I specialize in the teaching of software architecture. My research focuses on embedded systems architecture, with a strong focus on the AADL. I have been a member of the AADL standardization committee since 2006, and a member of its steering committee since 2011.

I was first introduced to AADL as part of the IST ASSERT project. I remember quite well my first encounter with Bruce Lewis, our AADL "Sherpa" during the Ada-Europe Conference on Reliable Software Technologies in Palma de Mallorca: it was 10 years ago, in June 2004. At that time, we were looking for an architecture design language with clear semantics and a textual representation, all of which were part of the initial requirements of the Society of Automotive Engineers (SAE) AADL standard.

Can you introduce/explain your project, its context, and objectives? What challenges did you want to address, and why did you select AADL as the modeling language?

As part of my research, I evolved from modeling patterns to modeling distributed, embedded systems and code generation to system engineering concerns. I am interested in a pragmatic solution to define stringent, tool-supported methodologies for the engineering of critical systems. Achieving this solution implies code generation that meets space industry standards as part of the TASTE project, scheduling analysis, and model checking. More recently, I became interested in defining a better coupling between analysis tools and models. Using AADL, as well as being part of the group defining it, provides a perfect context in which to discuss all those concerns and define practical solutions.

Please explain for us how you used AADL in this project. If possible, please give us the nuts-and-bolts details.

Recently, the AADL committee started an effort to support reliability analysis as part of modeling and verification activities supported by the language. In the meantime, the SEI developed various tools to support those analyses in the scope of the ARP4761 standard. I became curious about how far we could go with these tools. As head of a master's degree program at ISAE, I have the chance to teach students with strong backgrounds not only in safety but also in aeronautical engineering. I thus proposed a challenge to my students: model one family of four UAVs that we develop at ISAE using AADL, and perform safety analysis to evaluate the reliability metrics of our UAVs. It started as an exploratory project, yet the results went beyond our expectations. Not only could we abstract the key elements of the UAVs; we could also perform a wide range of analyses using a single model, as opposed to using separate tools.

Being an aeronautics school, ISAE is developing prototype UAVs for both research and teaching purposes. These UAVs range from quadrotors (two variants) to fixed-wing planes. They share a common embedded part, on top of which various command laws, sensors, and actuators are deployed. Our modeling objective was to capture product-line concerns in the form of a library of components, and then to platform specific configurations as specific instances of these building blocks. This first step demonstrated that AADL could capture many of the elements considered when engineering UAVs.

The second step was to model faults and their propagation in the architecture. To do so, we defined problematic situations in our systems. Examples of these problematic situations include bad errors, loss of a component, transient errors in communication, etc.

The final step was to perform safety analysis. Our team of researchers could directly apply analysis plug-ins bundled with OSATE2, thanks to the SEI,. We performed all kinds of analyses required by the aeronautic industry, including functional hazard assessments, failure mode and effects analysis, fault tree analysis, and more.

In addition to yourself, who else is involved in the project, and what are their backgrounds? How do they learn AADL? Have they faced any specific issues or problems?

The team----in addition to myself, the team included Nicolas Chatonnay, Julien Bosseboeuf, Jérôme Pierra (MS EMS students), Jacques Lamaison and Alain Hostalier (ISAE/DMIA engineering team)--was made up of three students with backgrounds in telecommunications, two lab engineers, and me. I was the only person with a solid background in AADL and related model-based technologies. My students were exposed to a 20-hour AADL class that I teach. This teaching was combined with the availability of the book Model-Based Engineering with AADL by Peter Feiler and David Gluch.

The modeling activity was straightforward thanks to the definition provided in the Error Model Annex defined by the AADL committee. This straightforwardness is the big strength of AADL: the language and its annexes are defined using the engineer's words, not through specific modeling-language verbiage. Project meetings were more focused on "what do we want to model?" rather than "how do we model such a pattern?" This focus is definitely a good point when considering a specific modeling notation.

What tools did you use to model and analyze the system?

We relied on OSATE2.0.5 and the OpenFTA toolset. OSATE maps error models to OpenFTA for further analysis.

How much time was required to learn AADL basics and error model notation and tools? How long did it take to resolve the complete problem from start to finish?

The full project--including learning EMV2, mastering tools, modeling, and finally, analyzing--was done in four weeks. This time span included writing reports detailing all elements. The models represent 2,000 source lines of code of AADL, covering all components, interconnections, and associated error models.

What feedback have you received from this project? What is your takeaway?

Students were quite impressed to achieve all the objectives in such a short time frame. Collaborative modeling, analysis plug-ins, and power of expression of the language are satisfactory to conduct safety analysis for UAVs. The ability to achieve these objectives constitutes a good case study for those interested in AADL. We plan to publish this case study along with accompanying notes in the near future

Do you have plans for future work on this project? If yes, do those future plans involve AADL?

Now that we have demonstrated safety figures for the UAV, the next big step at ISAE is to start from these models and move toward code generation. ISAE specializes in control systems, and we have design tools for code generation from AADL models and could also integrate Simulink models. It would be great to first generate back code that was previously handwritten, and then ascertain that the quality of the code does not hinder safety. We have an ongoing project to apply theorem provers to generated code.

Wrapping Up and Looking Ahead

This experience report shows the ease with which AADL can be used to model a family of systems and apply safety-analysis techniques. ISAE's experience applying UAVs also demonstrates that AADL analysis tools are relatively straightforward and do not require experienced skills in model-based engineering. As Hugues reports, learning the language does not seem to be an issue and the team learned the language basics and received significant results within a few weeks. The ease with which Hugues' team learned the language demonstrates that engineers with appropriate backgrounds can quickly acquire and apply the technology. And because "the language and its annexes are defined using the engineer's words," as Hugues reports, it is easy to apply and transition engineering concepts in AADL. For that reason, users were able to capture systems concepts with the language and focus on their engineering domain (i.e., safety).

This study focuses mostly on safety aspects, but it could also apply to other engineering domains, such as security and performance. AADL is an extensible language, so users can tailor it to capture the quality attributes that they would like to analyze.

We welcome your feedback below.

Additional Resources

For more information about AADL, please visit http://www.aadl.info/aadl/currentsite/and our wiki at https://wiki.sei.cmu.edu/aadl/.