When life- and safety-critical systems fail, the results can be dire, including loss of property and life. These types of systems are increasingly prevalent, and can be found in the altitude and control systems of a satellite, the software-reliant systems of a car (such as its cruise control and GPS), or a medical device. When developing such systems, software and systems architects must balance the need for stability and safety with stakeholder demands and time-to-market constraints. The Architectural Analysis & Design Language (AADL) helps software and system architects address the challenges of designing life- and safety-critical systems by providing a modeling notation that employs textual and graphic representations. This blog posting, part of an ongoing series on AADL, describes how AADL is being used in medical devices and highlights the experiences of a practitioner whose research aims to address problems with medical infusion pumps.

Although AADL was initially applied in the avionics and aerospace domains, it is now being used in other domains where software failures have significant impact. The design of life- and safety-critical systems in the medical domain, where an error or software fault may have catastrophic consequences including loss of human life, has been the topic of recent media reports, as well as increased scrutiny from the FDA as described in this story in The New York Times. The size and complexity of medical-related software continues to grow and the more complex the software, the more likely it is to contain bugs or errors. A classic example was the Therac-25 linear accelerator, which malfunctioned due to software problems and gave overdoses of radiation to patients.

Medical devices must be designed and validated carefully to shield users from software defects. For that purpose, engineers must adhere to a strict development process that requires analyzing and validating their architecture prior to implementation efforts. Such a process would ensure requirements enforcement and reduce potential re-engineering efforts.

The SEI's Work on AADL

The SEI has been one of the lead developers of AADL and has participated on the AADL standardization committee since its inception. SEI researchers also developed the Open Source AADL Tool Environment (OSATE), which is the reference implementation for supporting AADL within the Eclipse environment. Other researchers and developers have used AADL as a foundation to design and analyze life- and/or-safety-critical systems. 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 or aerospace systems, it can be used to design systems in other domains that place a premium on life- and/or safety-critical behavior. An apt example is the domain of medical devices, which have expensive and time-consuming certification and accreditation processes to validate and verify that they are free of software bugs. Thus, the AADL design and validation methods and tools that have been developed for avionics and aerospace can be applied and reused between the various domains.

One Practitioner's Experience

Oleg Sokolsky, a research associate professor with the department of computer and information science at the University of Pennsylvania, first became involved in AADL in 2004 after applying for and receiving a Small Business Innovative Research grant. Sokolsky described his introduction to AADL:

The sponsor was looking for modeling languages and analysis tools for complex distributed systems. We had some tools that would be applicable, but we had to make them work in a wider context. A connection to the architecture level was needed. I recently heard a workshop talk on AADL and it was still fresh in my head. I have a colleague who had a startup, so he led the tool development effort. We began by applying schedulability analysis techniques to AADL models, using AADL semantics. It was a good fit for the tools we had in house.

Next, Sokolsky's team extended the analysis for the same semantic representation and built what he believes is the first simulator for AADL models.

Applying AADL in the Medical Domain

After their initial application, Sokolsky said his team applied AADL to modeling whatever systems they were developing at the time, including medical devices. Sokolsky's team started using AADL in their research to address software problems as part of the U.S. Food and Drug Administration's (FDA) Infusion Pump Improvement Initiative, which seeks to make infusion pumps safer and more reliable. Sokolsky described some of the architecture problems with the infusion pump that his team was trying to address:

In several cases, there wasn't enough sanity checking on inputs. Software should be designed in such a way that it should reject wrong inputs. Unfortunately, several pump models weren't designed that way. It was very easy for a nurse to enter a wrong value. Over-infusion and under-infusion are both serious hazards.

Specifically, his team used AADL to describe the infusion pump's software architecture, the platform-independent controller (which receive inputs and reacts to outputs), and the platform-dependent software, such as drivers for sensors and actuators between them. Sokolsky described the ways in which his team used architecture and modeling techniques to address some of the problems with the infusion pump:

In the reference architecture, there should be a module that assesses quality of inputs and rejects the wrong ones. Also, timing information on the components in the architecture can help us evaluate latency of data flows to determine whether the pump will stop the motor fast enough in case of an alarm.

Over the years, Sokolsky's AADL-based research has focused on developing platform-independent code generation techniques, specifically for model-based development of infusion pump software.

We had a very detailed model of the safe controller for the infusion pump, and we were looking for ways to generate code for it automatically. What we realized is that existing code generation tools are producing platform-independent code that had to then be manually connected to the platform. We were looking for ways to minimize the amount of new code that had to be written manually. That's where AADL came in. It allowed us to describe the various platform dependencies that existed in our systems and characterize, for each kind of dependency, what code needs to be generated for a particular platform.

Sokolsky said his team continues to use AADL because they understand the semantics of the language and have long-standing experience with it. One of the challenges they face, however, is keeping up with all of the changes that are occurring within the AADL community, which operates its own wiki site:

Right now there are so many things going on in this AADL ecosphere. We have a hard time picking things that are mature enough that we can actually use.

Looking Ahead

Sokolsky described various AADL-based design artifacts that his team has developed for the infusion pump. The artifacts include hazard analysis documents, requirement specifications, models of pump controllers, verification results, generated code, and a preliminary safety case:

The goal is to provide a set of artifacts for the community and the FDA, so, on the one hand, researchers have a way to apply their formal methods to these artifacts. The FDA can look at the safety argument that we are constructing. It gives feedback to the community.

Sokolsky said that the manufacturer's intellectual property restrictions do not impede the dissemination of documents, models, and code developed by his research team.. Such artifacts can serve as case studies for the wider research community, enabling comparison of modeling and analysis tools from different research groups. These artifacts could also potentially be used by the FDA to showcase good development practices to manufacturers and develop future guidance documents for industry.

Future Work

SEI researchers are working to extend AADL so that it can describe system faults and analyze the safety of systems. These capabilities will enable AADL users to augment their software architectures with fault description and specify error source and propagation across hardware and software components. This enhanced notation would then be used to improve system validation and detect faults that are potentially not spotted during the initial development process and that may lead to errors. This work consists of two parts:

1. enhancing the core of the technology with a sub-language to describe architecture safety concerns
2. developing new tools to process this additional information within the model, validate system safety, and assist engineers in the production of documents for validating the system

For the purpose of improving system validation and detecting faults, a new language has been proposed by the SEI and is currently under review by the AADL standardization committee. The language would be published as an official standard annex later by the Society of Automotive Engineers (SAE). In addition, the SEI is developing new functions within OSATE to analyze system safety and produce documents required by safety evaluation standards, such as SAE ARP4761. Looking ahead, Sokolsky said that his team will work with the SEI to use the error-model annex and specify an error model for the pump to reason about its reliability.

AADL is fairly versatile and, if used to its full capacity, it gives a boost to whatever other development techniques that you are using on top of it.

Our next blog post will discuss the use of AADL in the System Architecture Virtual Integration (SAVI) project. SAVI is part of the collaborative and applied research performed by an aerospace industry research cooperative. Our post will describe the use of AADL within this project to improve software safety and reliability.

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

For more information about the Generic Infusion Pump research at the University of Pennsylvania, please visit
https://rtg.cis.upenn.edu/gip/