The Problem Statement (PSM Verification)

6.3.1. Motivating Example

We first give a running example motivated from the GPCA safety requirements and the GPCA model explained in Section 3.2 in order to explain the platform-dependent verifica-

tion process.

Consider the following informal timing requirement that is obtained from the GPCA safety requirements [6]:

• (REQ1)“When a patient requests a bolus, a bolus infusion should start within 500ms."1

In the PI-Phase, a platform-independent code is developed by going through the two pro- cesses:

Platform-independent modeling and verification: the timed behavior of a system is first formalized using timed modeling languages. Fig. 17 shows a UPPAAL model that abstracts the timed behavior of the infusion pump system and its environment. This model is a parallel composition of two automata, M and ENV. M models the system using a clock variable (x), input synchronizations (m-BolusReq and m-EmptySyringe), and output synchronizations (c-StartInfusion and c-StopInfusion and c-Alarm). ENV models the en- vironment using a clock variable (env-x) and complementary synchronizations with that of M.

(1) M

(2) ENV

Figure 17: The example PIM

The informal semantics of the model is as follows: ENV can perform synchronizations, m- BolusReq and m-EmptySyringe, with its respective minimum inter-arrival times (200 and 1_{Note that the specific timing parameter (500ms) is added to the original requirement to explain our} work.

400 time-units). In case them-BolusReq synchronization is enabled whileM is in theStart location, M makes a transition to BolusRequested location and then performs the output synchronization c-StartInfusion in between 300 and 500 time-units; similarly, M makes a transition either to the Start or EmptyDetected location depending on the timing guards and the available synchronization.

We can show that REQ1 is satisfied in this model (by describing REQ1 as a logic formula, which states that the maximum delay of two successive synchronizations – m-BolusReq followed byc-StartInfusion – does not exceed 500 time-units, and verifying it using model checking).

Platform-independent code generation: a code generation process automatically gen- erates the platform-independent code (e.g.,C code) from the verified model (e.g.,the model in Fig. 17). Listing 6.1 gives the pseudo code of the generated code that is typically produced by existing code generators [14] [40].

Listing 6.1: Abstraction of Code(PIM)

1 Code(PIM){ 2 loop forever 3 await(); 4 local_i:=readInput(i); 5 Compute-InputTrans(local_i, getClock()); 6 local_o:=Compute-OutputTrans(getClock()); 7 writeOutput (local_o); 8 end loop 9 }

The pseudo code interacts with a platform via several platform-specific primitives (which must be implemented by any platform that executes the generated code) as follows: First, the code waits for a trigger (await in Line 3) from a platform so that the subsequent blocks of the code can be executed. Once being triggered, it reads inputs (readInput in Line 4) from the platform, and uses the obtained values to make a decision for input transitions

(Compute-InputTrans in Line 5) along with the current clock time (which can be read from a platform through getClock). Subsequently, it performs a transition decision for outputs (Compute-OutputTrans in Line 6) along with the current clock time. Finally, it writes the produced output to the platform (writeOutput in Line 7), and repeats this series of actions.

6.3.2. Problem Statement

The example platform-independent model (PIM) in Fig. 17, which is one of the artifacts produced in the PI-Phase (Chapter 4), does not explicitly capture the platform-specific timing information. For example, it only describes thatM is synchronized withENV over them-BolusReq channel for the input interaction, but it does not express information about how such synchronization is to be implemented on a particular platform. On the other hand, the PD-Phase (Chapter 5) aims at expressing such platform-dependent information from which the platform-dependent code can be generated to support the execution of the platform-independent code. This information includes, e.g., how a platform reads a bolus request input from a sensor (e.g., interrupt or sampling), how a platform processes the sensor readings and delivers them to the software (e.g., shared variable or buffering), and how tasks are scheduled by a platform (e.g., periodic or aperiodic invocation) to read the input values and to take transitions.

The above separation of timing concerns is necessary in the model-based implementation, because these platform-specific timing details are not typically available or less concerned in the early modeling/verification stage, and the generated code is also expected to be re-used on a range of target platforms through platform-specific customizations. However, it also leads to timing gaps between a model and its implementation. In other words, the testing result of the timing requirements on the final implementation may not be consistent with the timing verification result of the platform-independent model, mainly because of the missing platform-specific timing details in the early modeling stage.

ter. Code(PIM) denotes the platform-independent code generated from a PIM. This code needs to be composed with platform-specific primitives (e.g., read/write API) to realize the platform-specific interactions. IS denotes an implementation scheme that is used for such a composition. The implemented system is denoted by IMP, which indicates that the resulting implementation is the platform-independent code executed with the support of an implementation scheme IS. Finally, P(∆mc) denotes a timing requirement that the delay

between an inputmand an outputcmust be within ∆_mctime units (e.g.,the delay between the bolus request and the start infusion must be within 500ms).

As explained in the infusion pump example, the timing information of a chosen IS is not explicitly modeled in thePIM and hence, the following claim maynot always hold:

PIM |= P(∆mc) implies IMP |=P(∆mc).

To better describe the timed behavior of the implementation, we need a platform-specific version of the PIM that captures the timed behavior of the IS, such that if this platform- specific model (PSM) is verified to meet a timing requirement, then its implementation also satisfies the requirement. In addition, as was discussed earlier, the IS may introduce an additional delay to the response time between an input m and an outputc, which can lead to a violation of the timing requirement P(∆_mc) in the implementation. To quantify how close the implementation is from satisfying P(∆_mc), we would like to compute a new delay bound ∆0_mc for whichP(∆0_mc) holds in the implementation. In other words, we need to derive a platform-specific model (PSM) and a bound ∆0_mc such that

PSM |=P(∆0_mc)implies IMP |= P(∆0_mc).

To this end, our goals are (1) to identify the necessary information to obtain such aPSM, (2) to develop a method for systematically transforming a PIM into a PSM based on the identified information, and (3) to compute the bound ∆0_mc.

In the next section, we introduce a platform-dependent verification framework that achieves these goals.