Building Blocks for Safe Medical Devices

       -- Assumption Management and Dependency Structuring

Lui Sha, lrs@cs.uiuc.edu

The designer of Ariane 4 monitor SW noted that the 16 bit horizontal velocity variable was impossible to overflow because of the law of physics [for Ariance 4]   
 

But it was reused in Ariane 5 with higher horizontal speed. 
 

During launch, it overflowed and triggered the destruction of Ariane 5

   www.ima.umn.edu/~arnold/disasters/ariane.html

Many Medical devices are real time embedded systems that must deal with many sensors and actuators in real time. Lessons in aerospace can be useful. Traditional software interfaces only specify the types of exchanged data, not the properties of hardware & software components that must be observed for correct usage. For example, in a low pass software digital filter, the only interface is the floating number, not S/N, phase delay or processing time delay needed for correct use. 

Currently, assumptions about the environment and properties of components are implicitly assumed by the logic of the codes, not on the interfaces that can be automatically checked. The problem of this approach is highlighted by the Ariane 5 incident.  When one changes a mechanical, hardware or software component’s internal properties without corresponding changes in the interface, there are no automated tools that will flag all the software elements that become inconsistent with the new environment. This is not an isolated incident. The failure of the Patriot anti-missile system during Gulf war was due to the mismatch between the new extended operational duration and the limited precision of the 24 bit register.¹  Making all the assumptions explicit, human readable and machine checkable is important.

Another important point illustrated by the Ariane 5 incident is the need for robust software architecture. The overflowed variable is not flight critical but it led to the destruction of the rocket. We have seen many incidents where faults and failures in a non-critical component cascade along complex and unexpected interdependency graphs resulting in catastrophic failures in a large part or even an entire system. This is unacceptable. We need to develop dependency structuring and tracking technologies that remove unnecessary dependencies between components, ensure proper criticality ordering along dependency trees, and guard against faults and failures of complex components that are useful but not essential.