Platform-Independent Verification Process

The platform-independent verification process aims at verifying the conformance of a formal model of PCA pump systems with respect to the safety requirements. Ideally, we expect all the GPCA safety requirements to be verified using the UPPAAL model, so that the rest of the development processes can inherit sufficient safety assurance from the beginning. However, we were only able to formally verify some of the GPCA safety requirements using the UPPAAL model for the following reasons.

Firstly, the GPCA model is not detailed enough to verify some of the safety requirements. This is because the GPCA model relies on a different level of abstraction from that of the safety requirements. For example, the GPCA model does not describe detailed functions related to the calculation of the reservoir time remaining, which is mentioned in the following requirement: the reservoir time remaining shall be re-calculated at the beginning of every bolus dose. Such functions are considered platform-dependent since different platforms may have different ways of calculating the reservoir time remaining using platform-dependent parameters such as availability of sensors to detect a certain threshold of remaining volume. As another example, the following requirement couldn’t be verified for a similar reason since the GPCA model does not detail the behavior of the pump stroke: if the suspend occurs due to a fault condition, the pump shall be stopped immediately without completing the current pump stroke.

Secondly, some requirements could not be formalized regardless of the abstraction level of the GPCA model. Even if these requirements were formalized in any form, the meaning of the formal property would be difficult to verify in the context of the safety requirements. For example, the following requirement -the flow rate for the bolus dose shall be programmable - requires a system to have the functionality to maintain flow-rate information in memory so that it can be modified on demand. Since this requirement describes implementation- specific functionality, developers need to assure this requirement at the implementation level through validation instead of formal verification.

Thirdly, some safety requirements are too vague from the formal verification perspective, so they can neither be formalized for verification nor be validated at the implementation level. For example, the following requirement -flow discontinuity at low flows (f ml/hr or less) should be minimal -, or the requirement - a clear indication should be displayed any time the drug library is not in use - contains unclear definitions of minimal and a clear indication, respectively. These requirements need to be clarified and improved before they can be formally verified at the model level or validated at the implementation level.

Table 3: Categorization of GPCA Safety Requirements Category 2

SR 1.5.4. Reservoir amount remaining shall be re-calculated at the beginning of every bolus dose.

SR 1.6.2. If the suspend occurs due to a fault condition, the pump shall be stopped immediately without completing the current pump stroke.

Category 3

SR 1.4.2. The flow rate for the bolus dose shall be programmable.

SR 1.11.3. Each log entry shall be stamped with a corresponding date/time value.

Category 4

SR 1.1.3. Flow discontinuity at low flows (f ml/hr or less) should be minimal.

SR 5.1.7. A clear indication should be displayed any time the drug library is not in use.

Based on this observation, we divided these safety requirements into four categories:

◦ Category 1 : Safety requirements that can be formalized and verified in the UPPAAL model.

◦ Category 2 : Safety requirements that can be formalized, but the GPCA Simulink/S- tateflow model needs additional information to verify them.

◦ Category 3 : Safety requirements that cannot be formalized, but can be validated at the implementation level.

◦ Category 4 : Safety requirements that cannot be formalized because they address issues related to the ambient environment of the pump or they are vague in description.

Out of 97 safety requirements, we identified 20 requirements as Category 1; 23 as Category 2; 31 as Category 3; and 23 as Category 4. Table 3 shows example safety requirements belonging to Categories 2, 3, and 4; we introduce how the safety requirements belonging to Category 1 are verified using the UPPAAL model.

Formal Verification of Safety Requirements in Category 1: The GPCA safety requirements belonging to Category 1 are manually translated into a temporal logic formula expressed in the UPPAAL query language. The UPPAAL query language consists of state formulaand path formula[15]. State formula describes an expression that can be evaluated

for a state without looking at the behavior of the model; on the other hand, the path formula quantifies over paths or traces of the model, which can be classified intoreachability,safety and liveness. Even though there is no systematic way to translate informal requirements into formal queries, our translation process roughly follows the strategy: (1) expressing the state formula using relevant UPPAAL locations and variable conditions, (2) extending the state formula with the path formula so that the context of the safety requirement is appropriately represented in the form ofreachability orsafety orliveness properties.

For example, consider the safety requirement, No bolus dose shall be possible during the POST. This requirement can be captured by the following UPPAAL query:

A[ ] (! (POST.POST-In-Progress && ISSM.BolusRequest)) ,

where the word No is mapped to the logic operator !(not), POST.POST-In-Progress is used to indicate a location that abstracts that the POST checking is being performed, and ISSM.BolusRequest is used to indicate the location that abstracts that a bolus infusion is in progress. This forms a state formula that is mapped to the safety requirement. Then, the state formula is further extended with the path formula A[ ] (invariantly) to express a safety property that enforces the above state formula to be satisfied by the model in all its executions.

Consider another requirement,the pump shall issue an alert if paused for more than t min- utes. In order to write a state formula for this requirement, three locations are identified from the UPPAAL model: ISSM.InfusionPaused is a location that abstracts a pump is in a paused state after a user presses aconfirm-pause button in order to pause the current infu- sion for a while. ISSM.PausedStopConfirmis another location that can be reached from the ISSM.InfusionPausedlocation by pressing astop-infusionbutton;ISSM.PausedStopConfirm location abstracts that a pump is in a paused state waiting for a user to press a confirm- stop button in order to completely stop the current infusion. If a pump is in either ISSM.InfusionPausedorISSM.PausedStopConfirmlocation, the pump is expected to be in a

state where the current infusion is paused. On the other hand,ISSM.Alrm-TooLongInfusion- Pause is a location that abstracts that a pump is raising an alarm due to the fact that the pump is paused for more than a certain time-limit that is defined ast minutes in the safety requirement.

One can write a state formula,ISSM.InfusionPaused &&x1 >MAX-PAUSED-T, wherex1 is a clock variable reset to 0 when it enters theISSM.InfusionPaused location, to indicate a condition that the pump stays in the locationISSM.InfusionPausedfor more thantminutes. Here, t is instantiated as a constant variable MAX-PAUSED-T; and this state formula is extended with the path formula → (lead to) to express that if the former state formula holds, the later state formula, ISSM.Alrm-TooLongInfusionPause, will eventually satisfy. The corresponding UPPAAL query is:

(ISSM.InfusionPaused &&x1 >MAX-PAUSED-T)→ISSM.Alrm-TooLongInfusionPause Similarly, ISSM.PausedStopConfirm should be extended with the path formula as follows:

(ISSM.PausedStopConfirm && x1>MAX-PAUSED-T) →

ISSM.Alrm-TooLongInfusionPause

Several more examples of requirement formalization are shown in Table 4. The current GPCA safety requirements contain 97 requirements. We translated 20 requirements into UPPAAL queries, and verified them in the UPPAAL model. More details of the platform- independent verification can be found in [33].

In order to give intuition as to how such formal verification can be used to detect defects of software designs, we give an example of the verification result and analysis here. In fact, the last query turns out to be not satisfied in the UPPAAL model that is translated from the GPCA model. Provided with a counter example produced as a result of the verification, the value of the clock variable x1 can diverge forever in the ISSM.PausedStopConfirm location; and the root cause is that the original GPCA model did not have a transition

Table 4: Mapping between Safety Requirements and UPPAAL queries Category Safety Requirement(SR) / Safety Property(SP)

SR 1.4.3 No normal bolus doses should be administered when the pump is alarming (in an error state).

Query A[](! (ISSM.BolusRequest && CDR.Alrm-UnknownDrug)) SR 3.4.3 The POST shall take no longer than t seconds.

Query (POST.Post-In-Progress && x1 > MAX-POST-WAIT) → POST.Alrm- POSTFailure

SR 1.5.6 If the calculated volume of the reservoir is y ml, and an infusion is in progress, an Empty Reservoir alarm shall be issued.

Query (ISSM.Infusion-NormalOperation && Cond-6-3 == true ) → (ISSM.Alrm- EmptyReservior)

SR 2.2.4 If the pump is idle for t minutes while programming a dose setting, the pump shall issue an alert to indicate that the user needs to finish programming and start infusion.

Query (ICR.ChangeDoseRate && x1 > MAX-WAIT-INPUT-T) → (ICR.Alrm- LongWait-ChangeDoseRate)

fromISSM.PausedStopConfirmtoISSM.Alrm-TooLongInfusionPausethat should be taken upon time-out; consequently, the UPPAAL model, translated from the GPCA model, does not have the corresponding transition either. We fixed this design defect (i.e., adding a missing transition to the UPPAAL model)3, and moved to the next development process after verifying all safety requirements belonging in Category 1. One may manually find such a type of design defect in an ad-hoc manner, but we believe that identifying such defects in an automatic fashion using formal verification will result in a higher safety assurance of systems.