The Problem Statements and Challenges

The FDA’s GPCA model written in the Stateflow semantics is claimed to be the general system behavior found in a range of PCA infusion pumps. The main problem of the PI- Phase is to systematically develop a platform-independent code from the GPCA model that meets the GPCA safety requirements with formal assurance. Here are several challenges in developing such a platform-independent code.

Challenge 1: The GPCA model is expressed using the informal semantics pro- vided by Stateflow, which makes it difficult to directly apply formal verification techniques. Even though the GPCA model abstracts the system behavior that is com- monly found in PCA infusion pumps using the Stateflow semantics, its conformance to the safety requirements has not been formally verified. Here, the formal verification means that a model is checked against a formal query translated from a requirement by systematically exploring all possible cases occurring in the whole state space of the model; in other words, if the formal verification result proves the conformance, there is no such case that violates the requirement in any behavior introduced from the model; otherwise, the model may contain behavior that can lead to a requirement violation. 1 In spite of the fact that Stateflow has become popular in designing system behaviors in many industrial domains, it has several semantical issues that originate from its absence of formal semantics as indicated in several literatures [45] [26]. This becomes a big obstacle for formal verification of the system design modeled in Stateflow.

Challenge 2: Not all the safety requirements are written in a way that formal

verification can be performed in the context of the GPCA model. Ideally, all the

safety requirements are to be formally verified so that the subsequent development phases 1_{We note that this kind of formal verification technique is distinguished from testing or simulation-based} techniques that are typically used to check a subset of the whole system space by providing a finite sequence of input and comparing the observed output with its expected output.

can inherit the verified property from the model. However, it is challenging to formally verify every requirement in the GPCA model for several reasons. We observed that the level of abstraction adopted in some safety requirements is different from that of the GPCA model. For example, some requirements include detailed functionality of PCA infusion pumps, whereas the GPCA model does not explicitly model such details; some requirements explain functionality belonging to the environment (e.g.,the user interface) with which the system expressed in the GPCA model should interact (i.e., those functionalities are out of the scope of the GPCA model). We also observed that some requirements are vaguely written from the perspective of formal verification. These aspects that we observed impede the formal verification of all the safety requirements at the PI-Phase.

Challenge 3: Designing a well-defined interface of the platform-independent code is difficult since it is not directly matched to the timing semantics of the platform-independent model. The platform-independent code constitutes only a part of a final implemented system in our model-based implementation; in addition, the platform- independent code should be integrated with many different platforms in the later stage. Therefore, the platform-independent code should be generated along with a well-defined interface that allows it to be integrated with a range of platforms. Designing such a code- level interface needs correct translation of the timing semantics of the platform-independent model, but such a translation is complex. For example, an input transition semantics of a model requires multiple actions to be performed at the code-level: reading sensor input, making a transition decision by comparing the current clock value to the guard condition associated with the transition, and choosing the next transition from a transition table. In addition, this series of actions may be tightly coupled with the platform-dependent timing aspects (e.g., implementation of clock semantics is different across different platforms). Therefore, designing such an interface requires consideration in terms of what aspects should be decoupled as platform-independent and platform-dependent timing aspects, and how those decoupled aspects should interact with each other. Nonetheless, state-of-the-art code generators do not utilize this concept well enough: existing code generators produce a code

that is specific to a particular platform, which makes it difficult to be integrated with other platforms (i.e., the generated code is tightly coupled with a particular platform- dependent code), or they do not provide a standard way about how the generated code should be integrated with a range of platform-dependent codes. These aspects of existing code generators requires the addition of a glue code in an ad-hoc fashion, which makes the final implemented system difficult to reason about how timing semantics at the boundary between the platform-independent and platform-dependent code are implemented.

We give the overview of our approach to tackle these challenges in the next section.