Model-Based Engineering for Medical-Device Software

MANAGEMENT & TECHNOLOGY

Model-Based Engineering for Medical-Device Software Arnab Ray, Raoul Jetley, Paul L. Jones, Yi Zhang Abstract

This paper demonstrates the benefits of adopting model-based design techniques for engineering medical-device software. By using a patient-controlled analgesic (PCA) infusion pump as a candidate medical device, the authors show how using models to capture design information allows for i) fast and efficient construction of executable device prototypes ii) creation of a standard, reusable baseline software architecture for a particular device family, iii) formal verification of the design against safety requirements and iv) creation of a safety framework that reduces verification costs for future versions of the device software.1

Introduction

The increasingly complex nature of modern medicaldevice software, combined with its safety critical nature, makes the engineering of medical software a challenge. Strategies for ensuring that software is error-free typically consist of manual design inspections and unit/integration testing of the code, making detection of errors heavily dependent on human factors. Model-based engineering is a software development paradigm that has achieved steady adoption in the embedded systems industry, especially in the automotive and aerospace domains. In this development methodology, engineers construct design models using executable notations with the property of “executability” that simulate code execution. Once the models are encoded, implementation code may automatically be generated from them using commercially available tools. This paper advocates the use of such model-based techniques for the engineering of medical device software. Specifically, four aspects of model-driven development are identified as being of particular interest to device manufacturers. • Fast prototyping: Models, being at a higher level of abstraction than code, can be constructed much more rapidly than a full-fledged implementation. 70

These virtual prototypes can then be simulated on a desktop computer and act as a reference model for the final implementation. Additionally, they may be used to study the ramifications of humandevice interface decisions at a much earlier phase of the development life-cycle than would be possible with more conventional methods. • Creating a baseline software architecture: Different variations of a medical device (for example, different types of PCA pumps) are typically found to share a common set of base functionalities which may be captured as part of a generic device specification. Models of such a generic device may then provide a reusable baseline artifact that can be extended to generate different members of the product family in a faster and more efficient manner than if each of these were individually designed from scratch. • Formal verification of design models: Formal coverage-based testing strategies can be used to perform verification on device models. This facilitates the identification of safety violations in the preimplementation phase where errors are easier to identify and can be rectified at lesser cost. • A safety framework for medical devices: A model of the generic device software, annotated with monitor models (an artifact from the instrumentationbased verification methodology, described later, that is a model representation of a safety requirement), can provide a safety framework that may be reused for verification of future iterations of the product, thus reducing the cost and time needed for re-verification of a new version. The principle on which the safety framework operates is that any particular model component may be replaced by an enhanced model component only if the enhanced component satisfies the monitor models that annotated the old component model. The rest of the paper is arranged as follows. Section 2 details the background for the concepts used in the subsequent discussion. Section 3 shows how a prototype of November/December 2010

MANAGEMENT & TECHNOLOGY Ray et al

a generic infusion pump is constructed and simulated through a user interface. Section 4 discusses the reusable generic infusion pump architecture, while Section 5 explains a model-based testing technique called Instrumentation Based Verification (IBV). Section 6 lays out how models of a generic device can lead to the creation of a safety framework for that device family. Section 7 concludes the paper and lays down future research directions.

Background

A generic infusion pump (GIP) design specification developed at Food and Drug Administration/Center for Devices and Radiological Health/Office of Science and Engineering Laboratory (FDA/CDRH/ OSEL)2 is used as the basis for this study. Simulink/Stateflow is provided in the rest of this section. Mathworks Simulink/Stateflow5 is the executable modeling notation used as the basis for the study.

The Generic Infusion Pump Project The GIP project provides a reference implementation of a generic infusion pump that can be verified against safety requirements using formal verification techniques. Once this model is established and ascertained to be complete and correct, it can then be extended to incorporate additional, more product-specific features for specialized pumps. There are a number of different types of infusion devices on the market, such as large-volume pumps, patient controlled analgesic (PCA) pumps, insulin pumps, and even implanted pumps. The models produced as part of the GIP project encapsulates only features common to these infusion pumps, hence the name “generic.” To help define the common characteristics for the generic model, a hierarchical classification of pump types (shown in Figure 1) has been established. Mapping out pumps in this manner helps identify the common characteristics for the generic model. The root of this hierarchy represents the broad category of all infusion pump devices (generic infusion pump in the figure). Infusion pumps are then classified as external pumps or implanted (in vivo) pumps based on whether the delivery mechanism is external or internal to the patient. External pumps are further classified based on their intended use as therapeutic, anesthesia, enterBiomedical Instrumentation & Technology

Figure 1. Hierarchy of Infusion Pump Types

al, or analgesic. Implanted pumps are similarly divided into two categories, corresponding to whether they are used for analgesic or therapeutic treatments. Examples of therapeutic pumps include pumps targeted at specific ailments, such as insulin and chemotherapy pumps. Analgesic pumps include pain-relieving pumps, such as PCA and epidural pumps. Safety requirements for the generic infusion pump, and the generic PCA pump in particular, were derived by performing a detailed system-level hazard analysis2 for PCA pumps. The hazards were enumerated based on consultations with subject-matter experts and historical data on pump malfunctions. Software safety requirements were then constructed with reference to the identified hazards by asking the question: How can these hazards be remedied or detected by software? Consider, for example, the hazard of under-infusion, a common problem with infusion pumps. This hazard may be caused by improper flow (due to occlusion or air lock) or an empty reservoir. The suggested mitigation is to ensure that a minimum predefined flow rate must always be maintained by the pump. Correspondingly, the safety requirements defined for this hazard would include the following: • The pump should maintain a minimum keep-veinopen (KVO) rate of 0.1 ml/hr at all times during infusion. • If the calculated volume of the pump reservoir is 0 ml and an infusion is in progress, the pump shall issue an “empty reservoir” alarm. Similarly, the requirement corresponding to the hazard “low battery” would be: If the battery life remaining is less than five minutes, the pump shall issue a “battery depleted” alarm. 71

MANAGEMENT & TECHNOLOGY Model-Based Engineering for Medical-Device Software

Fast Prototyping

Figure 2. A Simulink Diagram

Mathworks Simulink® Simulink® is a software plug-in for Mathworks Matlab that enables one to model, simulate, and analyze systems whose outputs change over time. Simulink models are represented as hierarchical blocks that graphically depict time-dependent mathematical relationships among the system’s inputs, states, and outputs. The user can execute the model by running the Simulink simulator from a specified start to a specified stop time. The ability of a system to be simulated follows directly from the execution semantics of Simulink which can be stated as follows. At every time-step, the inputs for a block B are first calculated. B then transforms these inputs into its outputs based on the time- dependent mathematical relationship it encodes. The internal state of B may optionally change as a result of this computation step. It should be noted that this mathematical relationship (block logic) may be expressed alternately as an equation, a network of hierarchically nested Simulink blocks, or even in terms of state-machines and flow charts. This last-mentioned specification formalism is provided by an optional extension of Simulink® called Stateflow.® In Figure 2, an example of a Simulink diagram is shown. Here, the Simulink block A (which may have other Simulink blocks nested in it) takes in In1 and computes Out1. This Out1 then serves as an input to block B (specified as a Stateflow diagram). The output of block B and that of block C is then sent to a logical AND block, whose block logic is represented by an equation that implements the AND logical operation. 72

One of the benefits of creating executable models of medicaldevice software is that models, being more abstract entities than code and hence free from low-level implementation details, can be constructed much more rapidly. The prototype model may be virtually executed on a desktop and its behavior checked for consistency with the user’s expectation of device operation. In this way, software verification can be performed early in the development lifecycle where design errors are easier to fix. In contrast, non-model-based development flow methods often require that the software is completely developed and flashed onto the hardware before prototyping and simulation can begin. The ability to rapidly create executable prototypes opens up the possibility for experimenting with different design choices. For example, the human-software interface is an important component of a medical device. Many of the critical failures that cause loss of life or injury happen due to operator error that follows from an imperfect understanding of this interface. As a result, humanfactors engineers concerned about the design and layout of the device-user interface can explore the ramifications of the proposed user interface early in the lifecycle before finalizing it as an implementation. As part of the GIP project, an executable prototype for a generic patient-controlled analgesic (GPCA) pump was constructed from a set of functional requirements. A “front-end” user interface, implemented in software, was used to drive this prototype. The architecture of the prototype is designed in such a way that, if required, different user interfaces can be swapped in and out, and the ramifications of each of them on the operation of the infusion pump checked through exhaustive simulations of the prototype. The prototype architecture is such that not only the user interface, but even the model of the software or the system can be exchanged seamlessly with corresponding alternatives—provided the old and new models have the same architectural interface. This would be helpful for example if one desired to check the implications of changing the control logic of the software with an alternative algorithm. November/December 2010


The inputs to the GPCA simulation model are environmental parameters (e.g., temperature, pressure, and humidity), system parameters (e.g., the charge capacity of the battery, its charge rate), and sensor inputs (e.g., upstream and downstream occlusion pressure, air bubble size). The outputs of the simulation model are a series of GPCA states that are displayed on a computer monitor, in effect mimicking how the human interface would behave if the GPCA was running as an actual system. Each GPCA state is defined by the current GPCA alarms/warnings/alerts, the status of the current infusion (e.g., volume left to be infused), and the state of the different buttons, i.e., which of the software buttons are currently enabled and their current function. Internally, the GPCA model has three top-level architectural components: • The GUI model: The GUI architectural component, as the name suggests, interacts with the human-being (a caregiver) to obtain different infusion parameters (volume to be infused and the dose rate) through a settings console and also infusion control signals (start infusion, stop infusion, pause infusion) through button presses. As the output, it provides information related to the current operational state of the pump and also displays messages pertaining to different alarms and alerts/warnings through a message console. • The software model: This architectural component defines the different states (e.g., POST, INFUSION IN PROGRESS, POWER OFF) that the GPCA may be in during its operation, checks the validity of the supplied infusion parameters and raises alarms/warnings if they are out of the “safe” range (as specified by an in-built database of “safe” infusion parameters defined per drug). This model also encodes the logic by which the GPCA interprets user input and enforces proper sequence of user actions (for instance, infusion cannot be startBiomedical Instrumentation & Technology

Figure 3. Generic Patient Control Analgesic (GPCA) Pump Top-Level Overview

ed before proper infusion parameters have been input). It is also responsible for interpreting alarms and warnings that are raised by the pump hardware (the system) and for taking remedial action if needed. • The system model: This architectural component consists of system models of the different functional components that are part of the GPCA (for example, the battery, the physical pump, the flowmeter, the different sensor controllers, and the drug reservoir) and the connections between them. We assume the presence of a drug library (a data file that contains information about maximum, minimum, and typical values of drug parameters) and bar-code readers (for reading in patient data) as essential safety features. The primary role of the system model is to model the operation of the system components and their controlling firmware. It also serves to raise alarms when devices fail (e.g., battery not charging properly), or their resources get exhausted (e.g., battery charge is close to zero), or when events occur that jeopardize the safe operation of the pump (e.g., an air bubble is present in the infused fluid), and to display alerts when appropriate (e.g., the pump’s AC power has been disconnected and it is drawing power from its battery). Sections 3.1 to 3.3 provide greater detail on the GPCA architectural components. 73


The GUI Model

The GUI model provides a set of buttons, a message console, and a settings console to the user. Buttons are of two types–hard and soft. A hard button is a switch, the interpretation of which is constant throughout the operation of the pump. For example, the power button is a hard button as it is always used to turn the pump off or on. In contrast, soft buttons have varying interpretations, depending on the GPCA state. The same soft button that is used to confirm the selection of the volume to be infused in one state can be used to pause infusion in another state. (Note: Human factors engineering was not a consideration for this study.) The message console provides information regarding alarms, alerts/warnings, and other GPCA status messages (e.g., the amount of charge left in the battery, the volume of drug remaining, time left for current infusion). The settings console initially displays the default value of different infusion parameters, where the defaults are obtained from a drug library. Using two soft buttons (increment and decrement), a caregiver is able to set these parameters. The GUI model interacts with the software model through a bidirectional data transfer interface. The GUI model sends data regarding the button-press status of the individual buttons. If the GPCA is at a state where the user is being queried for the infusion parameters, the GUI model is also responsible for relaying these values from the setting console. The GUI model, in turn, receives the following in-

Figure 4. GPCA Architecture

74

formation from the software model. 1. Current configuration of the GPCA: The information about current GPCA configuration is used to determine the interpretation of the soft buttons. For example, once all the infusion parameter checks have been completed and the hardware checked for errors, the GPCA is ready to begin infusing. Consequently, it enters a state where one of the soft buttons is interpreted as the start infusion button. Once that soft button has been pressed, the GUI model transmits that information to the software model which then changes state to “infusion in progress.” This state information is then read by the GUI model and the soft button is changed to “stop infusion” so that the next time that soft button is pressed, the infusion is stopped. 2. Status messages: The software model sends status messages (e.g., infusion in progress or low battery), in the form of text strings, to the GUI model which then prints them on the display console.

The Software Model The software model defines the states of the pump and the conditions that need to be triggered for the GPCA to transition from one state to another. For example, let the GPCA be at an initial “power down” state. The “power on” hard button is pressed. The GUI model sends the button-press status to the software model. The software model interprets this information and realizes that the GPCA is to be turned on. The pump state now changes to POST (power on self test) state. Then, depending on whether the POST operation was successful, the pump transitions to the “check admin set” state or to the ”post failed” state. This information is then sent to the GUI model so that it can now set the status of its soft buttons based on the current state of the software model. The software model is also responsible for handling all kinds of alarms and alerts/ warnings. These may originate from two sources. • The software model November/December 2010


itself: The software model checks to see if the drug in the drug reservoir—this information is obtained from the system model— matches the drug that the patient is supposed to be given—this information is read off a barcode on the patient’s wrist— and if they do not match, raises an alarm. The GPCA is also equipped with a drug library which specifies the optimal infusion parameters for a particular drug and a particular type of patient and also upper/ lower limit of the infusion parameters. If the values of the infusion parameters sent from the GUI model are outside the limits defined by the drug library (these values are obtained from the system model), the software model sets an alarm and prompts the GUI model to obtain different parameter values. • The system model: The system model throws alarms when infusion errors (e.g., air in line, under-infusion, over-infusion, infusion paused for too long) and system errors (e.g., battery charge depleted, battery charging error, AC voltage out of range) occur, and when environmental conditions (temperate, pressure, humidity) are outside the GPCA’s operational boundaries. Finally, the software model parses the button-press events and settings console values obtained from the GUI model, captures the infusion control signals, like start infusion, stop infusion, pause infusion, and the infusion parameter values and then sends them to the system model.

The System Model The system model consists of GPCA system components, namely the controllers for the physical pump, the AC adapter sensor, the temperature sensor, the pressure sensor, the humidity sensor, the flow meter, the pump motor, the battery, and the bar-code reader. It also models the charging/discharging of the physical battery and the depletion of the drug reservoir due to infusion. The system model takes as its input environmental parameters (temperature, pressure, humidity, vibration), system parameters (charge/discharge rate) and also inputs of the sensors (occlusion pressure, air bubble size). These are interpreted by the respective controller models which then check if the values obtained are within “safe”’ ranges and if not, alarms (critical-error conditions that need to be handled immediately) or warnings (non-critical alerts) are raised and sent off to the software model. Biomedical Instrumentation & Technology

In addition, the software model supplies the system model with: • Infusion parameters like the programmed flow rate and volume to be infused (VTBI), so that the pump knows at what rate it must pump and when should it stop pumping. • Infusion control signals like start infusion, stop infusion, pause infusion. As an example, when the software model sends the start infusion message, the system model starts infusing using the programmed flow rate until the volume infused becomes equal to the supplied VTBI or until a stop infusion is received. If in the mean time the pump is paused by the user, the system model gets the “pause infusion” message and maintains a keep vein open (KVO) rate of infusion.

Product Line Engineering

As touched upon briefly in the introduction, the GPCA model may be considered to be a baseline specification that encapsulates the generic behavior of all PCA infusion pumps. More specialized models representing actual PCA devices can be constructed by extending this basic model, much in the same way that base classes in object-oriented programming can be specialized to form derived classes or a family of similar products created by extending varying functionalities to a baseline artifact in product-line engineering.8 This section shows how a model of a generic medical device may be extended by replacing an abstract system component with a more concrete one. Figure 5(A) shows the interface of a generic power unit model, a constituent of the larger GPCA model. The interface consists of an input AC mains voltage and two output signals—power error (an abstract signal that signifies an error) and power status (an abstract signal that gives the current status of the power unit). The latter may be as simple as a bit which signifies whether the power unit is connected to an AC mains. Different PCA pumps can have different design implementations of the power unit. While some may rely exclusively on AC power, others may be equipped with a battery back-up. In Figure 5(B), we demonstrate how the generic power unit may be extended to provide a more realistic interface for an example PCA pump. In our simple extended PCA pump (let’s call it P1), the power unit is replaced by models of an AC adapter and a battery (internal details of the models are not shown). The new 75


Figure 6. The Classic Model-Based Design Flow

Figure 5. GPCA Power Unit and the Extended Power Unit

interface is derived from the generic one through: 1. Signal extension: The “power error” signal is extended by two concrete alarm signals. The first is a “battery charging malfunction alarm,” which indicates that the battery cannot attain a certain proportion of the total charge within a specified time-interval. The second is a “depleted battery alarm,” which is used to indicate that the battery charge is below a certain threshold. The “power status” signal is similarly extended to two concrete status signals—“current charge,” which gives the charge left on the battery, and “battery power,” used to indicate whether the extended power unit is connected to AC mains or whether the pump is running on battery power. 2. Signal creation: A new signal, “low battery warning,” is added. This is set to one when the battery charge is less than a certain threshold but greater than that which triggers the alarm Thus, in going from the specification of the GPCA to a more concrete PCA pump P1, our methodology requires two kinds of operations: 1) defining in 76

greater detail the internal behavior of the generic component (over here, this is done by replacing the power unit with an AC adapter and a battery) and 2) extending the interface of the generic component to support the signal handling capability required by the introduction of more complex behavior. The benefit of this approach is that it is easily extensible and allows one to define component models of increasing complexity and greater feature sets in a structured incremental fashion. For instance, a realistic battery would have a far more complicated interface than the one in our example. If such a battery model needs to be provided, all that we have to do is to 1) replace the battery model in P1 with the more complex one and 2) extend the interface of the power unit to support the signals the new battery model requires. In order to make sure that the extensions are safe, i.e., the act of extension introduces no unsafe behavior, one needs to make sure that the extended specification satisfies the safety requirements of the base specification. How this is accomplished is explained in section 6.

Formal Verification of Design Models

Verification of design models is typically performed once implementation code has been generated from the models and the resulting implementation installed onto the target platform. Standard system tests are then run on the device to check for off-specification, potentially unsafe behavior. However with the executability of notations like Simulink/Stateflow, it is theoretically possible to perform a large portion of the verification activities at November/December 2010


Figure 7. A Modified Model-Based Design Flow

the model level itself i.e., before code is produced, thus providing the potential of earlier error detection and a consequent saving of time and effort. An additional shortcoming of the traditional model-based design flow is that there is often no direct connection between the system tests and the safety requirements. This makes it difficult to make a general argument that just because a device passed the system tests it also satisfies the safety requirements. Alternative design flows have been proposed4 for using formal methods-based techniques to verify models against safety requirements. Temporal logic formulae are used to encode the requirements and then the design models are checked against them through a variety of model-exploration techniques known as model-checking.6 Auto-code7 is subsequently generated from the verified models and instrumented by hand as required. Assertions are then generated from the requirements and the code verified against these assertions. In this workflow, requirements drive both the model as well as the code verification. (It should be noted that models and the code have to be independently verified for high-confidence systems.) This design flow is not without its limitations however. Model-checking tools3 typically available in the research community are found to support a limited set of modeling constructs so that the analysis remains tractable. In contrast, industrial modeling tools5 favor expressive input notations in order to make the modeling activity more efficient. Because of this conflict, a designer has to Biomedical Instrumentation & Technology

choose between whether to use a full-featured modeling environment that helps build the system faster or use a restricted modeling notation that provides facilities for automated verification. This choice is often resolved on the side of ease of modeling. Consequently, the designer is once again forced to rely on classical methods of codetesting in order to verify the models. In addition to this limitation, model-checking suffers from severe scalability issues,6 which makes verifying anything but moderately sized models practically infeasible. It is also the case that the requirements drive the model and code verification, but not the final system (i.e., after the software has been deployed on the hardware) verification. The verification strategy used as part of this study seeks to address these shortcomings by using a novel modelbased verification strategy called instrumentation-based verification (IBV).1 In IBV, functional requirements are encoded as models themselves—called monitor models— whose role is to monitor the behavior of the system that is to be verified. If the observed behavior deviates from the ideal behavior as encoded in the monitor model, then the system under test does not satisfy the requirement under study. Alternatively, for a design model to satisfy the requirement the monitor model should always output 1 (i.e., signal test passed) for all simulation time steps. The IBV process, followed in this study, consisted of the following steps:

Figure 8. The Instrumentation-Based Model-Based Design Flow

77


Figure 9. Example of a Monitor Model

Monitor Model Construction Each safety requirement is encoded as a monitor model in Simulink. A monitor model may be looked upon as a specification of idealized system behavior where the notion of ideal is as defined by the requirement that the monitor model encodes. The goal of IBV is to detect if the actual behavior of the system models deviate from this idealization. As an example, consider the following safety requirement for the GIP that relates to pausing the infusion. It states: Infusion paused alarm: If the pump is paused for more than 10 minutes during infusion, the pump shall issue an alarm. The monitor model of this above requirement is given in Figure 9. It consists of: • A verification model, whose output represents the ideal value of the “infusion paused alarm” at every time instant. The verification model (shown in detail in Figure 10) takes as its input “infusion paused during infusion,” which is obtained by ‘AND”-ing the value of “infusion in progress” and ”infusion paused,” i.e., its value is 1 when infusion is in progress and the infusion has been paused. Inside the verification model, the “infusion paused during infusion” signal is used to drive a resettable counter. The moment the “infusion paused during infusion” becomes zero—either infusion is not paused or infusion has been stopped totally—this counter sets to zero. Otherwise, it keeps on counting once per every clock tick, essentially keeping track of how long infusion has been paused while it has been in progress. If the value of the counter becomes greater than ten minutes, then the “infusion paused” alarm is set to one. • A comparison model, which in this case, is simply an equality block. It takes as its input a) the actual 78

“infusion paused alarm” output from the verification model and b) the output from the design model that is being observed, namely “infusion paused alarm actual.” It then checks to see if they are equal, i.e., if the observed system behavior corresponds to the ideal. • The override logic, whose role it is to make sure that the output of the monitor model reflects whether the requirement is ’in scope’ or not. As an example, the above requirement is a specification of ideal behavior only within a certain system scope i.e., when infusion is in progress but is paused. In all other scopes, the requirement should be considered to be trivially satisfied. Consequently, the override logic detects when the requirement is not defined and outputs one to denote this trivial satisfaction.

Model Wiring In order for the monitor model to perform its role, it needs to be wired in to the design model. This wiring is performed by mapping the inputs of the monitor model to inputs and outputs of the design model in a tool that supports instrumentation-based verification (like Reactis) For example, in Figure 11 the “infusion in progress” and “infusion paused” inputs of the monitor model are connected to the “infusion in progress” and “infusion paused” inputs of the design model so that both of them are being driven by the same signal. The ”infusion paused alarm actual” input of the monitor model is connected to the ”infusion paused alarm” output of the design model, so that the alarm output produced by the design model may be monitored at every simulation step and checked with the ideal value of the alarm.

Automated Test Generation Once the design model has been instrumented with the November/December 2010


Figure 10. The Verification Model of the Monitor Model in Figure 9

monitor model, the user inputs the desired coverage criterion to the automatic test generator. (In our example, we use the Reactis automatic test generator and model simulator.) This coverage criterion could be block (each model block has to be executed once), branch (each control branch needs to be taken at least once), modified condition/decision (every atomic condition in a decision has to be shown to independently affect the outcome of the decision), or all of them. Based on the desired coverage criteria, the test generator generates tests (i.e., a series of inputs) in order to exercise the maximum amount of the model’s behavior that it can with the goal being to make the monitor model’s output go to 0. If the goal is achieved, a violation is flagged. The test suite is then loaded into the Reactis model simulator to investigate the reason for the violation. If none of the monitor model inputs causes it to output 0, then for the given coverage criteria, the design model has been proven to satisfy the requirement encoded by the particular monitor model. Figure 12 contains the results of IBV on a design model (pumpcontroller) with respect to a set of sixteen monitor models, one of which is shown in Figure 9. It says that none of of the sixteen requirements were violated.

Model-Code Conformance Checking The test suite, generated automatically as part of the verification effort—shown in Figure 13—serves as an oracle for the correctness of the implemented code, and the final medical device (i.e., software flashed onto the hardware) may be checked. The way this is accomplished is that the code (or the final system) may be executed with the input values, as defined by the test suite, and the outputs so obtained matched with the test-suite outputs. If they do match, then it may be asserted that the implementation code and final system are behaviorally conformant with the model. Since the model satisfies the safety requirements, the code and the final system are thus also guaranteed to satisfy them. Biomedical Instrumentation & Technology

One of principal benefits of IBV to medical-device manufacturers may be considered to be this direct connection between the requirements and the code/system tests that have been established through the automatically generated test suite. This might be used as part of premarket submissions in order to demonstrate traceability between safety requirements and system software tests. More specifically, assurance cases for software safety may be constructed with these test suites acting as the underlying evidence for safety claims.

A Safety Framework for Medical Devices

The ideas established in section 4 and section 5 can be combined to lay the foundation for a theory of safety frameworks for medical devices. More specifically, the two concepts we use are: • Models of a generic medical device define an extensible software architecture where the individual abstract component models may be replaced by concrete, more specialized models as long as the replacements satisfy the interface requirements of the original model. • When a safety requirement is checked against a component model V, the safety requirement is encoded as a monitor model, wired to V and then automatically generated tests are run on the instrumented model, so as to try to make V contradict the requirement. Similar to the way abstract component models are replaced by more concrete ones when specific device instances are derived from a generic specification, the concrete components may, in the course of product evolution, subsequently have to be replaced by newer ones, where newer models capture enhanced component functionality. For instance, a component V1 may be replaced by V2 where V2 is an upgrade for V1. In order for any model substitution to be valid, two conditions need to hold: 79


1. V2 needs to provide, at the very least, the same interface provided by V1 and 2. V2 needs to satisfy all the safety requirements of V1 so that it may be argued that the component swapping has not changed previously safe behavior. In Figure 14, model V1 is a component of the device architecture. V1 is to be upgraded with a component model V2. Component model V1 satisfies two safety requirements R1 and R2, which are encapsulated as monitor models (1 and 2). These monitor models, together with the wiring information, can be captured as annotations to the main Simulink models and stored in a single file. This file that contains the model together with its annotations may be said to have defined a safety framework in that all component models that populate the framework have been proven to be safe, with respect to the monitor models that annotate them. Now in order to replace component model V1 with component model V2 such that no unsafe system behavior is manifested due to the upgrade, the designer has to ensure that V2 satisfies those monitor models that previously annotated V1. Now if satisfaction cannot be assured, then that implies that V2 is not a safe replacement for V1. In this way, the safety network guarantees that any modification to the model does not end up violating a safety requirement. For those device manufacturers who do not follow a model-based design process, software needs to be tested from scratch when a new version of a medical device is to be put on the market. With the use of models and IBV however, a reusable safety framework is put into place where all that the designer needs to do is to swap out the components of the system that have been upgraded, leaving the rest of the system untouched, and then check to see if any of the annotating monitor models have been violated as a result of the swap. This has the potential of reducing the time and cost needed for reverifying a new version of an already existing system.

Figure 11. Wiring the Monitor Model to the Design Model

to an incorrect implementation of the model. Additionally, the monitor models capturing these requirements could themselves be constructed incorrectly, and may not faithfully capture the natural language requirements, resulting in inadequate or incomplete verification of the models. Finally, the test generation, coverage analysis, or

Discussion, Future Work and Conclusions

The successful application of model-based engineering depends on the quality of the safety and functionality requirements against which the models are verified. Like any engineering activity, model-based development has its own limitations. A model can only be as good as the requirements it implements. However, the requirements defined for the model (both design as well as safety requirements) may be imperfect or incomplete, leading 80

Figure 12. Automatic Test Generation

November/December 2010


simulation algorithms may not be properly implemented in the tool. These are significant risks to the model-based development process and need to be addressed. To address these, the developer must: 1) perform repeated iterative peer-review of requirements, 2) carry out design reviews focused on validating the monitor models, and 3) choose industry-standard, user-validated analysis tools for development and verification. The focus of this paper has been on demonstrating model-based development of generic device specifications as a powerful software engineering paradigm for decreasing time to market, promoting design reuse and in increasing confidence in the final software product. Future work includes extending the generic infusion pump specification models to more members of the product family—currently we have only extended it to patient controlled analgesic pumps—and generating automatic code from the models. Once code is generated from the models, we may use the test suites generated from the IBV process to supply the inputs of the test to the code and check to see if the outputs so produced are consistent with the test outputs. If they are, then we may claim that the design and the code are testing equivalent. The approach may be extended even further wherein the generated code can be flashed onto the actual device and using the same method as outlined above, system-design conformance may also be performed by checking to see if the design and the final system are testing equivalent. n

Figure 13. Test Suite

Acknowledgement

This work is supported by the National Science Foundation-Food and Drug Administration Scholar-inResidence program. Arnab Ray is with the Fraunhofer Center for Experimental Software Engineer at the University of Maryland. E-mail: [email protected]. Raoul Jetley, Paul L. Jones and Yi Zhang are with the Office of Science and Engineering Laboratories at the Food and Drug Administration’s Center for Devices and Radiological Health. E-mails: [email protected]. gov, [email protected], [email protected]

References

1. Ackermann C, Ray A, Cleaveland R, Heit J, Shelton C, Martin C. “Model-based Design Verification: A Monitor-based Approach,” Society of Automotive Engineers (SAE) World Congress, 2008. 2. Arney D, Jetley R, Jones P, Lee I, Ray A, Sokolsky O, Zhang Y. “Generic Infusion Pump Hazard Analysis and Safety Requirements Version 1.0,” December 2009. 3. Holzmann G. Addison-Wesley Professional, 2003.

Biomedical Instrumentation & Technology

Figure 14. Safety Framework

4. Jetley R, Jones P. “Safety Requirements-based Analysis of Infusion Pump Software” in proceedings of the IEEE Real Time Systems Symposium, Tuscon, AZ, December 2007. 5. Mathworks. Simulink. http://www.mathworks.com/products/ simulink/. 6. Merz S. “Model Checking: A Tutorial Overview,” Modeling and Verification of Parallel Processes, Volume 2067 of Lecture Notes in Computer Science, 3–38,. Springer-Verlag, Heidelberg, 2001. 7. Sturmer I, Conrad M, Fey I, and Dorr H. “Experiences With 8. Model and Autocode Reviews in Model-based Software Development” in proceedings of the 2006 international SEAS Workshop, 45–52. 9. Weiss D, Lai CTR. Addison-Wesley Professional, 1999.

81