An Architecturally-Integrated, Systems-Based Hazard Analysis for Medical Applications

by

in
An example STPA-style control loop, annotated with the subset of EMV2 and AADL properties from the paper
An example STPA-style control loop, annotated with the subset of EMV2 and AADL properties from the paper

A few months ago, I wrote about my recent work on defining a subset of the language AADL to specify the architecture of bits of software (apps) that would run on medical application platforms (MAPs). Since then, I’ve been working on how developers can use these semi-formal architectural descriptions to do useful things. The first “useful thing” is integrating hazard analysis annotations with these architectural descriptions — that is, specifying how things could go wrong in the app.

Structured hazard analyses have been performed for over half a century now (some dating back to the late 1940s!) but in some ways are still the same as they were back then, in that they are still unintegrated with the system under analysis — that is, any analysis performed would live in a separate document (often a Word file). In programming terms, this would be like having a system’s documentation be separate from the implementation, which isn’t nearly as useful as techniques like Doxygen or Javadoc, where everything is more tightly integrated.

So, after looking at a number of hazard analysis techniques, I (and others my research lab) settled on the relatively new, systems-focused Systems Theoretic Process Analysis (STPA).  From there, we looked at tailoring it to the medical application development process, and how that tailored process could be integrated with the architecture specifications from our previous work. The result of this effort was a paper, which was recently accepted to the 2014 ACM-IEEE International Conference on Formal Methods and Models for System Design (MEMOCODE) in Lausanne, Switzerland. I’m really excited to go and present.

My advisor has described the paper as “incredibly dense” (I blame page limits.) so in the next few months I’ll be expanding it into a whitepaper that will hopefully be much clearer, and will be of use to our research partners in regulatory agencies.


Comments

4 responses to “An Architecturally-Integrated, Systems-Based Hazard Analysis for Medical Applications”

  1. […] recently mentioned that a paper I wrote got accepted to MEMOCODE, a conference in Lausanne, Switzerland. Having never […]

  2. Howdy,

     

    Great paper, I’m impressed by the control loop diagrams.

    Do I need aadl-translator to get the STPA style diagrams?

    I’m attempting to use sphinx/pandoc whatever “literate” tools I can scratch together to maintain our open-source project:

    * http://process-controls.readthedocs.org/en/latest/controls/index.html

    * http://nightscout.info/ – some background on Nightscout/cgm-in-the-cloud

     

    I’ve been working on applying STPA to our system, right now I’m mainly interested in easy ways to maintain and iterate on the control loop diagrams, which have lots of little details that make them difficult in a lot of tools.  The idea of maintaining some aadl text files is quite attractive, so that the changes to them can also be audited in a meaningful way.

     

    Thanks,

    -bewest

  3. […] time I wrote about my work, I mentioned that we were using the architectural modeling language AADL to describe a particular […]

  4. […] Analysis of Faults and Errors” or SAFE. Hazard analysis techniques are, as I wrote about in 2014, structured ways of reasoning about and (typically) documenting the ways that things can go wrong […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.