Error Type Refinement for Assurance of Families of Platform-Based Systems

value-hierarchy
The fault type hierarchy for timing related errors, extended first for MAP Apps in general, and then for the PCA Interlock App

Last time I wrote about my work, I mentioned that we were using the architectural modeling language AADL to describe a particular type of distributed, compositional medical applications called Medical Application Platform (MAP) apps. One neat aspect of AADL is that the core language — which describes hardware and software architectures — can be extended by language annexes to cover other, related aspects of a system like its behavior (via the creatively-named “Behavior Annex”) or failure-related aspects (via the “Error Modeling” annex or “EM”). The EM has a number of neat features, not the least of which is its error type system.

Briefly, the idea behind the EM is that you can describe problems with your system, like a sensor failing and producing values that are wrong, or a communications channel delaying or dropping a message. These problems, termed “errors” in the EM, are made machine-readable by being described in a type system. The EM allows errors to be related to one another by three refinement mechanisms: extension, renaming, and aggregation — so you can actually create a full type lattice, if you’d like. The EM even comes with a standard set of errors, called the error library.

In a new paper, we looked at using the refinement mechanisms in the context of MAPs to specialize these fault types first by a component’s architectural category — the idea being that there are a finite number of categories in a MAP system: things like software application, network controller, medical device, etc. — and then by a component’s actual implementation. Component implementations, of course, have very concrete faults, because we know the actual message types various components will be sending and receiving. The list of errors produced by this refinement can then help a developer when it comes time to perform a hazard analysis (like FTA, FMEA, or STPA), regardless of which analysis / style (ie, top-down or bottom-up) is being performed.

The paper was accepted to the upcoming ASSURE workshop in Delft, The Netherlands, (collocated with SAFECOMP) so I’ll be headed out there in September to give a talk on it. Hopefully we’ll get some good discussion from the other workshop attendees, plus it’ll be fun to check out the presentations at the main conference, not to mention the city of Delft itself.

One Reply to “Error Type Refinement for Assurance of Families of Platform-Based Systems”

Leave a Reply

Your email address will not be published.

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