Specification and Verification of Timing Properties in Interoperable Medical Systems

To support the dynamic composition of various devices/apps into a medical system at point-of-care, a set of communication patterns to describe the communication needs of devices has been proposed. To address timing requirements, each pattern breaks common timing properties into finer ones that can be enforced locally by the components. Common timing requirements for the underlying communication substrate are derived from these local properties. The local properties of devices are assured by the vendors at the development time. Although organizations procure devices that are compatible in terms of their local properties and middleware, they may not operate as desired. The latency of the organization network interacts with the local properties of devices. To validate the interaction among the timing properties of components and the network, we formally specify such systems in Timed Rebeca. We use model checking to verify the derived timing requirements of the communication substrate in terms of the network and device models. We provide a set of templates as a guideline to specify medical systems in terms of the formal model of patterns. A composite medical system using several devices is subject to state-space explosion. We extend the reduction technique of Timed Rebeca based on the static properties of patterns. We prove that our reduction is sound and show the applicability of our approach in reducing the state space by modeling two clinical scenarios made of several instances of patterns.


Introduction
Medical Application Platforms (MAPs) [HKL + 12] support the deployment of medical systems that are composed of medical devices and apps. The devices, apps, and the platform itself may be developed independently by different vendors. The ASTM F2761 standard [Int09] specifies a particular MAP architecture called an Integrated Clinical Environment (ICE). The AAMI-UL 2800 standard complements F2671 by defining safety/security requirements of interoperable medical systems, including those built using the ICE architecture. Other medical domain standards such as the IEC 80001 series address safety, security, and risk management of medical information technology (IT) networks. All of these standards, as well as emerging regulatory guidance documents for interoperable medical devices, emphasize the importance of accurately specifying the device and app interfaces, understanding the interactions between devices and apps, as well as the implications of those interactions (and associated failures) for safety and security. Timeliness is an important safety aspect of these interactions -sensed information and actuation control commands need to be communicated to and from medical functions within certain latency bounds. A number of approaches to medical device interfacing have been proposed. Given the needs described above, interfacing approaches and interoperability platforms would clearly benefit from specification and verification frameworks that can define the interface capabilities of devices/apps and provide an automated means for verifying properties of interactions of devices/apps as they are composed into systems. Using such a framework that supports a compositional approach, we can inspect the substitutability and compatibility of devices to have a flexible and correct composite medical system.
Goals for a device interfacing framework, together with its communication needs have been described in [YKW15]. Working from these goals, a collection of communication patterns for MAPs was proposed in [RKHR15] that can be implemented on widely available middleware frameworks. These communication patterns address timing properties for medical systems built on a MAP. The patterns break down the timing properties into finer properties that can be locally monitored by each component. The timing properties impose constraints on timing behavior of components like the minimum and maximum amount of time between consequent sent or handled messages. These constraints balance the message passing speed among components, and assure freshness of data. The timing requirements of the communication substrate can be derived from these local timing properties. The timing requirements of the communication substrate impose upper bounds on communication latency. With certain assumptions on the local timing properties, and configuring the network • Proposing a novel technique for state space reduction in model checking of Timed Rebeca models; • Modeling and analyzing two real-world case-studies. This paper extends an earlier conference publication [ZGS20] by adding more explanation on the theory and foundation of our reduction technique. We provide a visualization of the state-space to show the reduction in a clearer way. We also provide guidelines and templates for modeling composite systems. The experiments on considering different communication substrate models due to different networks and the first case-study are also new materials. In our communication substrate models, we model the effect of networks by introducing different timing delays or priority on transmitting the messages of patterns.
The novelty of our modeling approach is that only the behavior of devices/apps need to be modeled. Thanks to the interface components, the behavior of devices/apps are separated from the ones monitoring the local timing properties. The model of patterns used in the system is reused with no modification and the proposed template for the communication substrate should be only adjusted to handle the messages of involved patterns. Our reduction technique takes advantage of static properties of patterns to merge those states satisfying the same local timing properties of communication patterns.
Although the approach in this paper is motivated by needs of interoperable medical systems, the communication patterns and architectural assumptions that underlie the approach are application-independent. Thus, approach can also be used in other application domains in which systems are built from middleware-integrated components as long as the communications used in this paper are applied for specifying intercomponent communication.

Communication Patterns
In this paper, we model communication patterns using Rebeca, here we provide an outline of patterns (based on the content of [RKHR15]). Devices and apps involved in a communication pattern are known as components that communicate with each other via a communication substrate, e.g., networking system calls or a middleware. Each pattern is composed of a set of roles accomplished by components. A component may participate in several patterns with different roles simultaneously. Patterns are parameterized by a set of local timing properties that their violation can lead to a failure. In addition, each pattern has a point-to-point timing requirement that should be guaranteed by communication substrate. There are five communication patterns: • Publisher-Subscriber: a publisher role broadcasts data about a topic and every devices/apps that need it can subscribe to data. Publisher does not wait for any acknowledgement or response from subscribers, so communication is asynchronous and one-way. • Requester-Responder: a requester role requests data from a specific responder and waits for data from the responder. • Initiator-Executor: an initiator role requests a specific executor to perform an action and waits for action completion or its failure. • Sender-Receiver: a sender role sends data to a specific receiver and waits until either data is accepted or rejected. 2.1. Publisher-Subscriber. In this pattern, the component with the publisher role sends a publish message to those components that have subscribed previously. Even when there is only a single subscriber component, choosing the pattern may be appropriate in situations where one wishes to have one-way asynchronous communication between the sender and receiver. In the interoperable medical device domain, this pattern would commonly be used in situations where a bedside monitor such as a pulse oximeter is sending data such as pulse rate information (P R) or blood oxygenation information (SpO 2 ) to some type of remote display (like a monitor that aggregates many types of health-related information for the patient) and/or applications that watch for trends in data to generate alarms for care-givers or to trigger some type of automated change in the patient's treatment. In these situations, there is a one-way flow of information from the monitoring device to one or more consumers. This pattern is parameterized with the following local timing properties: • MinimumSeparation (N pub ): if the interval between two consecutive publish messages from the publisher is less than N pub , then the second one is dropped by announcing a fast Publication failure. • MaximumLatency (L pub ): if the communication substrate fails to accept publish message within L pub time units, it informs the publisher of timeout. • MinimumRemainingLifeTime (R pub ): if the data arrives at the subscriber late, i.e., after R pub time units since publication, the subscriber is notified by a stale data failure. • MinimumSeparation (N sub ): if the interval between arrival of two consecutive messages at the subscriber is less than N sub , then the second one is dropped. • MaximumSeparation (X sub ): if the interval between arrival of two consecutive messages at the subscriber is greater than X sub then the subscriber is notified by a slow publication failure. • MaximumLatency (L sub ): if the subscriber fails to consume a message within L sub time units, then it is notified by a slow consumption failure. • MinimumRemainingLifeTime (R sub ): if the remaining life time of the publish message is less than R sub , then the subscriber is notified by a stale data failure.
The timing properties are chosen to (a) enable both the producer and consumer to characterize their local timing behavior or requirements and (b) enable reasoning about the producer/consumer time behavior compatibility and important "end-to-end" timing properties when a producer and consumer are composed. For example, the local property N pub allows the publisher to specify the minimum separation time between the messages that it will publish. From this value, one can derive the maximum rate at which messages will be sent. This provides a basis for potential consumer components to determine if their processing capabilities are sufficient to handle messages coming at that rate. Publisher compliance to N pub can be checked at run-time within the communication infrastructure of the producer, e.g. before outgoing messages are handed off to the communication substrate, by storing the time that the previous message was sent. Similarly, N sub and X sub are local properties for the subscriber. These allow the subscriber to state its assumptions/needs about the timing of incoming data. Figure 4 gives further intuition about the purpose and relationship between the parameters.
While the above parameters can be seen as part of component interface specifications on both the Publisher and Subscriber components, when reasoning about end-to-end properties, the following attribute reflects a property of the networking resource upon which intercomponent communication is deployed.
Regarding the intuition of this inequality, consider that the publisher will send a piece of data with a parameter R pub indicating how long that data will be fresh/valid. As the message is communicated, latencies will accumulate in the PublisherInterface (maximum value is L pub ) and communication substrate (maximum value is L m ). When the message arrives at the SubscriberInterface, it's remaining freshness would be R pub − L pub − L m . That remaining freshness should be as least as large as R sub -the time needed by the subscriber to do interesting application work with the value, i.e., to achieve the goals of the communication, the following inequality should hold R pub − L pub − L m ≥ R sub . The intuition is that R pub is a application property of the publisher -in essence, a "guarantee" of freshness to consumers based on the nature of the data, and R sub is "requirement" of the consumer (it needs data at least that fresh to do its application work). Given that L pub is a fixed latency in the software that interacts with the network, the network needs to guarantee that L m is low enough to make the inequality above hold. Using algebra to reorient the constraint so that it can be more clearly represented as a latency constraint on the communication substrate (L m ) yields Inequality 2.1.
For an example of how these parameters might be used in a medical application, assume a pulse oximeter device that publishes pulse rate data of the patient. A monitoring application might subscribe to the physiological readings from the pulse oximeter and other devices to support a "dashboard" that provides a composite view device readings and generates alerts for care-givers based on a collection of physiological parameters. In such a system, the Publisher-Subscriber pattern can be used to communicate information from the pulse oximeter (publisher) to the monitoring application (subscriber). In this description, there is only one subscriber (the monitoring application), but using the Publisher-Subscriber pattern is still appropriate because it allows other subscribers (e.g., a separate alarm application, or a data logging application) to be easily added. Even when there is a single subscriber, the pattern selection emphasizes that the communication is one-way. For publisher local properties, the pulse oximeter can use N pub to indicate the maximum rate at which it will publish blood oxygenation information (SpO 2 ) and/or pulse rate information. In medical devices in general, this rate would typically be associated with the interval at which meaningful changes can be reflected in the reported physiological parameters. The device designer would use the L pub parameter to specify the maximum length of the delay associated with putting a published value out on the communication substrate that would be acceptable for safe and correct use of the device. On the subscriber side, N sub allows the monitoring application to specify an upper bound on the rate of incoming messages. The value chosen may be derived in part from the execution time needed to compute new information and format resulting data for the display. Intuitively, the X sub allows the monitoring application to indicate how frequently it needs pulse oximetry data to maintain an "up to date" display. The other properties can be used to characterize end-to-end (non-local) timing concerns. To ensure that care-givers receive timely dashboard information and alerts, safety requirements should specify that information is (a) communicated from the pulse oximeter device to the monitoring application with a medically appropriate bound on the latency, and (b) the received physiological parameter is currently an accurate reflection of the patient's physiological state (i.e., the parameter is "fresh" enough to support the medical intended use). Such requirements would build on the type of non-local timing requirement specified above.
2.2. Requester-Responder. In this pattern, the component with the role requester, sends a request message to the component with the role responder. The responder should reply within a time limit as specified by its local timing properties. In the interoperable medical device domain, this pattern would commonly be used in situations where an application needs to "pull" information from a medical device (e.g., retrieving the current blood pressure reading from a blood pressure device, retrieving the infusion settings from an infusion pump) or fetching patient data from medical record database.
This pattern is parameterized with the following local timing properties: • MinimumSeparation (N req ): if interval between two consecutive request messages is less than N req , then the second one is dropped with a fast Request failure. • MaximumLatency (L req ): if the response message does not arrive within L req time units, then the request is ended by a timeout failure. • MinimumRemainingLifeTime (R req ): if the response message arrives at the requester with a remaining lifetime less than R req , then the requester is notified by a stale data failure. • MinimumSeparation (N res ): if the duration between the arrival of two consecutive request messages is less than N res , then the request is dropped while announcing an excess load failure. • MaximumLatency (L res ): if the response message is not provided within the L res time units, the request is ended by a timeout failure. • MinimumRemainingLifeTime (R res ): if the request message with the promised minimum remaining lifetime cannot be responded by the responder, then request is ended by a data unavailable failure. Compared to the Publisher-Subscriber, several of the timing specification parameters are similar, while others are reoriented to focus on the completion of the end-to-end two-phase "send the request out, get a response back" as opposed to the one-phase goal of the Publisher-Subscriber "send the message out". For example, the minimum separation parameters for both the Requester N req and Responder N res are analogous to the N pub and N sub parameters of the Publish-Subscriber pattern. The MinimumRemainingLifetime concept is extended to include a check not only on the arrival of the request at the responder (R req ) at the first phase of the communication, but also the a check on the communication from the Responder back to the Requester (at the end of the second phase of the communication).
Reasoning about the end-to-end two-phase objective of this pattern now needs to consider communication substrate latencies for both the request message L m and the response message L m . The point-to-point timing requirement defined for this pattern concerns the delivery of response with lifetime of at least R req . So the communication substrate should ensure that "the sum of [its] maximum latencies to deliver the request to the responder (L m ) and the resulting response to the requester (L m ) does not exceed L req +R req −L res −R res " (inequality 2.2).
For an example of how this pattern might be used in a medical application, consider a medical application that requires a blood pressure reading. The application would send a request message to a blood pressure device (with maximum communication substrate latency L m ), the blood pressure device would either return the most recent reading or acquire a new reading (with latency of L res to obtain the value within the device), and then the device would send a response message to the requester (with maximum communication substrate latency L m ). L req expresses the application's requirement on the overall latency of the interaction. The lifetime parameters can be used in a manner similar to that of the Publisher-Subscriber pattern.
2.3. Initiator-Executor. In this pattern, the component with the initiator role, requests a specific component with the executor role to execute an action. The executor should provide appropriate acknowledgment message (action succeeded, action failed or action unavailable) within a time limit as specified by its local timing properties. In interoperable medical applications, this pattern would typically be used by an application to instruct an actuation device to perform some action. For example, an infusion control application might use the pattern to start or stop the infusion process. A computer-assisted surgery application might use the pattern to instruct the movement of computer-controlled surgical instruments.
This pattern is parameterized with the following local timing properties: • MinimumSeparation (N ini ): if interval between two consecutive initiate messages is less than N ini , then the second one is dropped with a fast init failure. N ini can be seen as a guarantee in interface specification on the Initiator to not send messages faster than a certain rate. L ini is a requirement that the Initiator has on the overall latency of the action. Failure of the system to satisfy this property might lead the initiating component to raise an alarm or take some other corrective action necessary for safety. N exe can be understood as a requirement that the Executor has related to its ability to handle action requests. L exe can be seen as a guarantee that the Executor provides to either perform the action or generate a time out message within a certain time bound.
The point-to-point timing requirement defined for this pattern concerns the delivery of data within maximum latencies. The overall latency of the actions of sending the execution command L m , the executor carrying out the action L exe , and sending the acknowledge L m should not exceed the requirement on the overall latency specified by the Initiator L ini . Some algebra on this relationship to focus on the requirements of the communication substrate yields the following inequality (inequality 2.3).
For example, in the X-Ray/Ventilator synchronization in Section 6.1, a coordinating application needs to send commands to both the X-Ray and Ventilator. The Initiator-Executor pattern can be used to control both of these devices with the minimum separation constraints as used in previous patterns. The parameter L ini parameter would be used to specify the requirement on the maximum latency of each interaction.
2.4. Sender-Receiver. In this pattern, the component with the sender role, sends data to a specific component with the receiver role. The receiver should reply with appropriate acknowledgment message (data accepted or data rejected) within a time limit as specified by its local timing properties. This pattern is structurally and semantically very similar to the Initiator-Executor pattern. It is only presented as a separate pattern to distinguish the fact that the receiving component only accepts data and, e.g., stores it rather than performing an action that may impact the external environment.
This pattern is parameterized with the following local timing properties: • MinimumSeparation (N sen ): if interval between two consecutive send messages is less than N sen , then the second one is dropped with a fast send failure. The point-to-point timing requirement defined for this pattern concerns the delivery of data within maximum latencies. So the communication substrate should ensure that "the sum of maximum latencies to deliver the sent data to the reciever (L m ) and the resulting acknowledgment to the sender (L m ) does not exceed L sen − L rec " (inequality 2.4).
In interoperable medical applications, this pattern would typically be used to change the settings on a device or to update a record in some electronic medical record. For example assume a BP monitor that measures blood pressure every 3 minutes periodically. The monitoring application could use the pattern to change the settings on the device to an interval of 1 minute.

Timed Rebeca and Actor Model
Actor model [Agh90,Hew77] is a concurrent model based on computational objects, called actors, that communicate asynchronously with each other. Actors are encapsulated modules with no shared variables. Each actor has a unique address and mailbox. Messages sent to an actor are stored in its mailbox. Each actor is defined through a set of message handlers to specify the actor behavior upon processing of each message. Rebeca [SMSdB04,Sir06] is an actor model language with a Java-like syntax which aims to bridge the gap between formal verification techniques and the real-world software engineering of concurrent and distributed applications. Rebeca is supported by a robust model checking tool, named Afra 1 . Timed Rebeca is an extension of Rebeca for modeling and verification of concurrent and distributed systems with timing constraints. As all timing properties in communication patterns are based on time, we use Timed Rebeca for modeling and formal analysis of patterns by Afra. Hereafter, we use Rebeca as short for Timed Rebeca in the paper.  denotes meta parenthesis, superscripts + and * respectively are used for repetition of one or more and repetition of zero or more times. Combination of with repetition is used for comma separated list. Brackets [ ] are used for optional syntax. Identifiers C, T , m, v, c, e, and r respectively denote class, type, method name, variable, constant, expressions, and rebec name, respectively.
The syntax of Timed Rebeca [RSA + 14, SK16] is given in Figure 1. Each Rebeca model contains reactive classes definition and main part. Main part contains instances of reactive classes. These instances are actors that are called rebecs. Reactive classes have three parts: known rebecs, state variables and message servers. Each rebec can communicate with its known rebecs or itself. Local state of a rebec is indicated by its state variables and received messages which are in the rebec's mailbox. Rebecs are reactive, there is no explicit receive and mailbox manipulation. Messages trigger the execution of the statements of message servers when they are taken from the message mailbox. An actor can change its state variables through assignment statements, make decisions through conditional statements, communicates with other actors by sending messages, and performs periodic behavior by sending messages to itself. A message server may have a nondeterministic assignment statement which is used to model the nondeterminism in the behavior of a message server. The timing features are computation time, message delivery time and message expiration. Computation time is shown by delay statement. Message delivery and expiration times are expressed by associating after and deadline values with message sending statements.
Example 3.1. A simple request-response system is specified in Timed Rebeca given in Figure  2. This model has two rebecs: req is an instances of class Requester while res is an instance of Responder . The size of the rebec mailboxes is specified by (5) after the name of classes. These two rebecs are passed as the known rebecs of each other in lines 27 − 28 by instantiating. Each class has a message server with the same name as the class name and it acts similar to class constructors in object-oriented languages. Rebec req initially sends a message request to itself upon executing its constructor. The global time is initially 0. Rebec req takes the message request from its mailbox to handle. By executing the statement delay(3) it is blocked until time 3. The rebec req resumes its execution at time 3 by sending a "request" message to the rebec res. This message is delivered to the rebec res after a delay of 8, i.e., 11. At time 11, rebec res takes the message "request" from its mailbox. Upon executing its message server, it sends a message "response" to req which will be delivered at time 16. Rebec req takes the message "response" from its mailbox at time 16 and sends a message "request" to itself.   [HMP91]. In a TTS, transitions are partitioned into two classes: instantaneous transitions (in which time does not progress), and time ticks when the global clock is incremented. These time ticks happen when all participants "agree" for time elapse. The standard semantics of Timed Rebeca is defined in terms of TTS as described in [KKS18]. In the following, the brief description of this semantics is presented based on [KKS18]. Assume that AID is the set of the identifiers of all of the rebecs, MName is the set of the names of all of the message servers, Var is the set of the all of the identifiers of variables, and Val is all of the possible values of variables. Also, Msg = AID ×MName×(Var → Val )×N×N is the type of messages which are passed among actors. In a message (i, m, r, a, d) ∈ Msg, i is the identifier of the sender of this message, m is the name of its corresponding method, r is a function mapping argument names to their values, a is its arrival time, and d is its deadline. Also assume that the set P(A) is the power set and P * (A) is the power multiset of its given set A. More details and SOS rules which define these transitions are presented in [KKS18].
Example 3.3. We explain the state-space shown in Figure 3A derived partially for the Rebeca model given in Figure 2. The global state is defined by the local states of rebecs and global time. Note that this presentation has some minor difference in comparison with the structure of the global state in the presented semantics. As local states of all the rebecs in TTS has the same time, in Figure 2 one value for now is shown as the global time of the system. In addition, the values of the state variables and resuming times are omitted to make the figure simpler. In the initial state, called s 1 , only the rebec req has a message "request" in its bag. By taking this message, we have a transition of type event to the state s 2 while the pc of rebec is set to 1 indicating the first statement of the message server "request" should be executed. Upon executing the delay statement, the rebec is suspended for 3 units of time.
As no rebec can have progress, the global time advances to 3 and there is a time transition to the state s 3 . Now, rebec req resumes its execution by executing the send statements. This execution makes a state transition to the state s 4 by inserting a message "request" into the mailbox of res by setting its arrival time to 11.  The semantics of Timed Rebeca in FTTS is defined in terms of a transition system. The structure of states in FTTS are the same as that of in TTS; however, the local times of actors in a state can be different. FTTS can be used for the analysis of Timed Rebeca models as there is no shared variables, no blocking send or receive, single-threaded actors, and atomic (non-preemptive) execution of message servers which gives an isolated message server execution. As a result, the execution of a message server of an actor will not interfere with the execution of message servers of other actors. Therefore, all the statements of a given message server can be executed (including delay statements) during a single transition. result, states of actors in FTTS are in the form of (v, q, 0, t, ). In addition, there is no guarantee for the local times of actors to be the same, i.e. time floats across the actors in the transition system. • The initial state of a model in FTTS is the same as that of in TTS.
• The set of actions is defined as Act = MName.
• The transition relation → ⊆ S × Act × S defines the transitions between states that occur as the results of actors' activities including: taking a message from the message box, and executing all of the statements of its corresponding message server. For proposing the formal definition of →, we have to define the notion of idle actors. An actor in the state (v, q, , t, r) is idle if it is not busy with executing a message server. Consequently, a given state s is idle, if s(x) is idle for every actor x. We use the notation idle(s, x) to denote the actor identified by x is idle in state s, and idle(s) to denote s is idle. Using these definitions, two states s, s ∈ S are in relation s mg − − → s if and only if the following conditions hold.
More details and SOS rules which define these transitions in FTTS are presented in [KSVK15] and [Kha18].
Example 3.5. The FTTS of the Rebeca model given in Figure 2 is given in Figure 3B. As mentioned before, the values of resuming times and program counters are set to and zero in FTTS, so they are not shown in the figure. In the initial state, called t 1 , only the rebec req has a message "request" in its bag, and the local time of all rebecs is 0. Upon handling the message "request", the local time of rebec req is progressed to 3 and a message "request" is inserted to the bag of res as shown in the state t 2 . Upon handling the message "request" by rebec res, as its arrival time is 11, the local time of rebec is progressed to 11 in the state t 3 .
As proved in [KSVK15], the FTTS and the TTS of a given Timed Rebeca model are in a weak bisimulation relation. Hence, the FTTS preserves the timing properties of its corresponding TTS, specified by weak modal µ-calculus where the actions are taking messages from the bag of actors.
There is no explicit time reset operator in Timed Rebeca; so, the progress of time results in an infinite number of states in transition systems of Timed Rebeca models in both TTS and FTTS. However, Timed Rebeca models generally show periodic or recurrent behaviors, i.e. they perform periodic behaviors over infinite time. Based on this fact, in [KSS + 15] a new notion for equivalence relation between two states is proposed to make transition systems finite, called shift equivalence relation. Intuitively, when building the state space there may be a new state s generated in which the local states of rebecs are the same as an already existing state s , and the new state s only differs from s in a fixed shift in the value of parts which are related to the time (the same shift value for all timed related values, i.e. now, arrival times of messages, and deadlines of messages). Such new states can be merged with the older ones to make the transition systems bounded.
Definition 3.6 (shift-equivalence relation). Two states s and s are called shift equivalent, denoted by s δ s , if for all the rebecs with identifier x ∈ ID there exists δ such that: (1) statevars(s(x)) = statevars(s (x)), (2) now (s(x)) = now (s (x)) + δ, The bounded floating-time transition systems (BFTTS) S f , →, Act , s 0 f of a Timed Rebeca model is obtained by merging states of its corresponding FTTS S, →, Act , s 0 that are in shift equivalence relation. Shift equivalent states are merged into the one that its rebecs have the smallest local times. In [KSVK15] it is proved that FTTS and its corresponding BFTTS are strongly bisimilar; so, BFTTS of a Timed Rebeca model preserves the timing properties of its corresponding FTTS.
Example 3.7. The FTTS of Figure 3B modulo shift-equivalence is partially shown in Figure  3C. Assume the state t 6 in FTTS with the same configuration of t 6 in BFTTS. In the state t 6 , rebec req handles its "response" message and as a consequence it sends a "request" message to itself and its local clock is advanced to 32. We call the resulting state t 7 . The local clocks of rebecs in states t 7 and t 4 have a 16-time difference and the values of their state variables and bag contents are equal. So, these two states are shift-equivalent and are merged, resulting the loop in the corresponding BFTTS.

Modeling Patterns in Rebeca
We use the architecture proposed in [RKHR15] for implementing communication patterns. We will explain the main components of the Publisher-Subscriber pattern as the others are almost the same. As illustrated in Figure 4, the pattern provides communication between two application components -a client and a service, each of which could be either a software app or a medical device. For example, the client could be a pulse oximeter publishing SPO2 values to a monitoring application service. In our modeling approach, each of the patterns will have a component acting as an interface on either side of the communication that abstracts the lower-level details of a communication substrate. In this case, there is a PublisherRequester component that the publisher calls to send a message through the communication substrate and a SubscriberInvoker that receives the message from the communication substrate and interacts with the service. This structure is common in most communication middleware (e.g., the Java Messaging Service, or OMG's Data Distribution Service) in which APIs are provided to the application level components and then behind the scenes a communication substrate handles marshalling/unmarshalling and moving the message across the network using a particular transport mechanism. In our approach to reason about timing properties, the interface components PublisherRequester and SubscriberInvoker check the local timing properties related to the client or service side, respectively.
We model each component of this architecture as a distinct actor or rebec in Rebeca. We explain the model of the Publisher-Subscriber pattern in details. Other patterns are modeled using a similar approach. Figure 5 illustrates PublisherRequester reactive class, which is the interface between the client (device/app) and the communication substrate. As we see in lines 3 and 4, it has two known rebecs: the communication substrate cs to which messages are forwarded, and the client c to which it will return messages indicating the success/failure status of the communication. We define the state variable lastPub in line 5 for saving the time of last publication message. We use this time for computing the interval between two consecutive messages. This rebec has a message server named publish. We pass Lm and life parameters through all message servers in the model to compute the delivery time and remaining lifetime of each message. As the communication substrate is impacted by network These messages are delivered to their respective receivers with a non-deterministic delay, modeled by clientDelay, using the statement after . It means that the message is delivered to the client after passing this time. In case that the N pub property is violated, it sends a message fastPublicationFailure to the client. If the L pub property is violated, it sends a message timeOutFailure. Communication substrate abstracts message passing middleware by specifying the outcomes of message passing. To this aim, it may consider priorities among received messages to transmit or assign specific or non-deterministic latency for sending messages. A specification of communication substrate reactive class is shown in Figure 6. It handles transmitPublish messages by sending a RcvPublish message to its known rebec, a rebec of SubscriberInvoker class in line 11. It considers a non-deterministic communication delay  The SubscriberInvoker reactive class, given in Figure 7, is an interface between the communication substrate and the service (device/app). It has only one known rebec that is the destination for the messages of its instances. We define a state variable lastPub in line 5 to save the time of the last publication message that arrived in this rebec. This reactive class is responsible for checking N sub , X sub , R pub , R sub , and L pub properties (see Subsection 2). Message servers in this rebec are RcvPublish and consume. The RcvPublish server begins by modeling the communication delay between the interface and the service by assigning the variable serviceDelay (in line 8) with a non-deterministic value. As we explained in Section 2, a subscriber states its need about the timing of incoming data by parameters N sub and X sub : the rate at which it consumes data. It computes the interval between two consecutive RcvPublish messages in lines 9 − 10 and then uses this value to check that it be greater than equal to the minimum separation constraint at line 11 (N sub ) and less than equal to the maximum separation constraint at line 14 (X sub ). Otherwise, subscriber concludes a too fast or slow publication, respectively. A subscriber also states its need about the freshness of data by timing properties R pub and R sub ; if data arrives at the subscriber late after its publication (by comparing Lm and R pub ) or its remaining lifetime is less than R sub , subscriber concludes that data is stale (line 17) and sends a failure message to the service. By satisfying the properties, it saves the local time of the actor in lastPub and sends a consume message to the service after a delay of serviceDelay. Handling the message reception notification from the service, the message server consumed checks L sub property in line 29 and sends a failure to the service if the consumption time exceeded the specified maximum consumption latency L sub .  The Service reactive class, given in Figure 8, consumes the publish message with a delay and then assigns L m to transmissionTime indicating the point-to-point message deliver latency from publication of data to its receipt. 4.1. Analysis of Patterns. Checking of local timing properties is encoded in component models, and failure to satisfy such properties is indicated by notification messages sent to relevant components. Non-local timing properties are specified using assertions in the property language of the model checker and are checked during the model checking process. An example of such an assertion (corresponding to the non-local timing property of inequality 2.1) is shown in Figure 9. LatencyOverLoad is the name of property and transmissionTime   Table 1 shows the result of the analysis of patterns using Rebeca. We assign two groups of values to parameters to show the state-space size for when the timing requirement is satisfied and when it is not satisfied. As we see the state-space size is smaller when the timing requirement inequality is not satisfied, because in this situation a path in which the property is not satisfied is found and the state-space generation stops.
LatencyOverload : (( RPUB -RSUB -LPUB ) >= service . transmissionTime ) ; 4 } 5 } Figure 9. The timing requirement for the Publisher-Subscriber pattern As we assumed that apps/devices satisfy their timing constraints, violation of each inequality shows a run-time failure in which the communication substrate fails to communicate the data quickly enough to meet the interface components timing requirements and so the network is not configured properly. Alternatively, it can be seen as a design error where, e.g., the interface components are making too stringent local timing requirements (e.g., on the freshness).

Guidelines on Modeling Composite Medical Systems.
Depending on the configuration of a composite medical system, devices and applications connect to each other through a specific pattern. For each connection of two devices/apps, two interface components are needed as summarized in Table 2.
In a composite medical system, there may be device/apps that communicate over a shared message passing middleware. In such cases, we should also share the communication    substrate among the corresponding patterns of device/apps. It is a design decision to be faithful to the patterns (and the system). As a shared communication substrate communicates with all interface components of involved patterns, then we have to pass these components via its constructor in our models. Instead, to make the specification of a shared communication substrate independent from its interface components, we use the inheritance concept in Rebeca. We implement a base reactive class for the shared communication substrate and all interface components as shown in Figure 10, inspired by the approach of [YKG + 19]. We define the state variable id in line 2 to uniquely identify rebecs. This class has a lookup method named find to get the rebec with a given identifier as its parameter. Thanks to the special statement getAllActors (in line 4), we can get access to all actors extending the Base. In the method find, we define an array of reactive classes and initiate it by calling getAllActors. We iterate over the actors of this array to find the actor with the given identifier (in lines 5 − 7).  Figure 10. Base Reactive Class

Requester Responder
The communication substrate reactive class extends Base class. As illustrated in Figure  11, this class has a parameter id in its constructor for assigning the id variable of the parent class (in line 3). This class has no known rebec as opposed to the one specified in Figure  6. Instead, rebecs append their identifiers to their messages during their communication with the substrate. The communication substrate class uses the find method for finding the rebec that wants to send data based on its id (lines 6 and 11). Communication substrate class includes a message server for each communicated message of all patterns as shown in Table 2 (in addition to those for error messages). We can remove the message servers of unused patterns for the sake of readability. However, there is no cost if we do not remove the additional ones as when an event is not triggered, it will not be handled. This class specification can be used as a template even when we have no sharing. As communication substrate class in Figure 11 is commonly used by the components of Publisher-Subscriber and Requester-Responder patterns, it has the two message servers transmitPublish and transmitRequest for Publisher-Subscriber, and transmitResponse for Requester-Responder.
All interface components that communicate through a shared communication substrate should also extend the Base class. For each usage of a pattern, one instance of component interfaces on both side is needed. When an interface component is instantiated, the identifier of its counterpart interface component is set via the constructor. When an interface component sends a message to its counterpart interface component via our proposed communication substrate, it includes the identifier of the counterpart entity.
Each device/app may use several patterns to communicate with other device/app. Depending on its role in each pattern, we consider a known rebec of the appropriate interface component. To model devices/apps, we only focus on the logic for sending messages through the interface components.
We consider three types of delays in our specifications; 1) between sender interface components and communication substrate (after in the sender interface in the Rebeca model), and 2) between communication substrate and receiver interface components (after in the communication substrate in the Rebeca model), 3) between receiver interface component to receiver application (after in the receiver interface in the Rebeca model). RequestRequester rr = ( RequestRequester ) find ( requesterId ) ; 18 rr . response ( data , ( Lm + cs2Delay ) , ( life -cs2Delay ) ) after ( cs2Delay ) ; 19 } 20 } Figure 11. Modeling Communication substrate using inheritance The sender interface component models the behavior of communication driver, and the first type of delay defined in this component models the delay caused by network traffic. The driver retries until it successfully sends its message depending on the traffic. The value of this delay is defined by clientDelay in the sender interface component. The second type of delay, defined by netDelay in communication substrate, shows the delay of message passing middleware on transferring messages (for example caused by the routing and dispatching algorithms). The third type of delay, defined by serviceDelay in the receiver interface components, shows the delay caused by the system load. When a receiver interface receives messages, it should send them to the application components. Depending on the system load, the operating system allows the interface components to deliver their message to the application components.

State-space Reduction
A medical system is composed of several devices/apps that communicate with each other by using any of communication patterns. With the aim of verifying the timing requirements of medical systems before deployment, we use the Rebeca model checking tool, Afra. As we explained in Section 4, each communication pattern is at least modeled by five rebecs. It is well-known that as the number of rebecs increases in a model, the state space grows significantly. For a simple medical system composed of two devices that communicate with an app, there are nine rebecs in the model (as communication substrate is in common). In a more complex system, adding more devices may result in state-space explosion, and model checking cannot be applied. We propose a partial order reduction technique for FTTS which merges those states satisfying the same local timing properties of communication patterns. The reduced model preserves the class of timed properties specified by weak modal µ-calculus of the original model where the actions are taking messages from the message bag [KSVK15]. If we use the value of now in our Rebeca codes, then it is very likely that we encounter an unbounded state space, because the first condition of shift-equivalent relation given in Definition 3.6 may not be satisfied. By this condition, two states are shift-equivalent if all state variables of all rebecs have the same value. Here, we suggest a restricted form of using the value of now by specifying a set of variables called interval variables, and we relax the first condition for such variables. The model checking tool of Rebeca, Afra, is adjusted to treat these variables differently and hence we prevented generating an unbounded state space.
Let Var ∆ be the set of interval variables that are defined to only hold time values, i.e., we can only assign the value of now to these variables at different points of the program. We use these variables to measure the time interval between two execution points of a rebec by comparing the value of now at these two points. At the first point of execution, we assign now to the interval variable x ∈ Var ∆ , and at the second point the expression "now − x" measures the time interval between the first and the second point. For instance, the state variable lastPub of Rebeca class PublisherRequeter in Publisher-Subscriber pattern is used to measure the interval between two consecutive publish messages. This interval value is used to check local timing properties like N sub , N pub , and X sub . As variables of Var ∆ can only get the value of now , we relax the first condition of Definition 3.6 on these variables, and we treat such variables similar to the local time (see Section 3.2).
We also relax the third condition of Definition 3.6 which compares the messages in rebec bags. The local timing properties may impose restrictions on the transmission time or the remaining life time of data. In our implementations, we model the transmission time or remaining life time of data by the parameters of messages, namely L m and life, respectively (see the message server RcvPublish in the Rebeca class SubscriberInvoker ). To check the timing property on the freshness of data, the parameter life is compared with the constant R sub , configured as the system parameter, in a conditional statement. This is the only place that the variable is used within its message server. So, we can abstract the concrete value of this parameter and only consider the result of the comparison. Instead of passing life as the parameter, we can pass the Boolean result of life < R sub instead upon sending the message RcvPublish. We use this interpretation to compare the messages with such parameters in bags. Instead of comparing the values of parameters one-by-one, for the parameters similar to life we only consider the result of the comparison. If the values of life for two RcvPublish messages either both satisfy or violate the condition life < R sub while other parameters are equal, these messages can be considered equivalent as both result the same set of statements to be executed (irrespective to the value of this parameter). This idea can also be applied to the message RcvResponse in the Request-Responder pattern, parameterized by life which is compared to the local timing property R res in its message server. Formally speaking, we identify those messages, denoted by Msg ex , whose parameters are only used in conditional statements (if-statements). We use the conditions in the if-statements for data abstraction. We can abstract the concrete values of the parameters and only consider the result of evaluation of conditions. In Definition 5.1 (relaxed-shift equivalence relation), for simplicity, we assume that each message m ∈ Msg ex has only one parameter that we abstract its value, denoted by msgpar ex (m), based on the result of one condition, denoted as cond (m). We also assume that the message has another parameter that its value is denoted by msgpar ex (m).
By cond (m)(msgpar ex (m)), we mean the result of evaluation of the condition that is checked by the message server m over its specific parameter of m. The concrete values of a message parameter can be abstracted if it is only used in the conditions of if-statements. The concrete value of a parameter is needed if it is used in other statements (e.g., assignment or send statement in Timed Rebeca). To ensure the soundness of our abstraction, we limit cond (m) to propositional logic over the comparison of msgpar ex with constants. Considering more complicated conditions is among of our future work. In practice, we can find such parameters and their corresponding conditions through a static analysis of the message server or ask the programmer to identify them.
Definition 5.1 (relaxed-shift equivalence relation). Two semantic states s and s , denoted by s ∼ δ s , are relaxed-shift equivalent if there exists δ such that for all the rebecs with identifier x ∈ ID : (2) now (s(x)) = now (s (x)) + δ.
We consider Timed Rebeca models that in their message servers now can be only accessed for updating variables of Var ∆ or used in expressions like "now − x" (where x ∈ Var ∆ ) for computing an interval value. We reduce FTTSs of such models by merging states that are relaxed-shift equivalent. The following theorem shows that an FTTS modulo relaxed-shift equivalence preserves the properties of the original one.
Proof. Assume an arbitrary transition (s, m, s * ) ∈→ that denotes handling the message m by the rebec i. Based on the third condition of Definition 5.1, two cases can be distinguished: • m ∈ Msg ex : there exists message m ∈ bag(s (i)) such that m = (msgsig(m), arrival (m) + δ, deadline(m) + δ). The local time of rebec i in both states s and s are progressed by executing delay statements in the message servers m and m which is the same and hence, their local timers have still δ-difference in the resulting states s * and s * * . So, the second condition is satisfied (result †). Due to the execution of the same message server, all variables are updated by the same expressions. Based on the constraint on the models and the assumption s ∼ δ s , we conclude that all the variables except for Var ∆ have the same values (defined by the same expressions on un-timed variables). The values of Var ∆ are updated to now and, by the result †, they still have δ-difference. So, s * and s * * satisfy the first condition. The messages sent to other rebecs during handling m and m are sent at the same point with the same parameters (defined by expressions on untimed-variables). As their local timers have δ-difference, the arrival and deadline of sent messages have δ-difference. So, the third condition is also satisfied.
• m ∈ Msg ex : there exists message m ∈ bag(s (i)) with the same message name of m, i.e., Type(msgsig(m)), arrival time arrival (m) + δ, and deadline deadline(m) + δ. The first assumption of Definition 5.1 together with the assumptions msgpar ex (m) = msgpar ex (m ) and (cond (m)(msgpar ex (m)) ⇔ cond (m )(msgpar ex (m ))) result that the same statements are executed by the rebec i during handling m and m . The variables x ∈ Var ∆ are used in expressions as now − x and so now (s(i)) − statevars(s(i))(x) = now (s (i)) − statevars(s (i))(x). With a similar discussion in the previous case, the local time of rebec i in both states s and s are progressed by executing the same delay statements and hence, their local timers have still δ-difference in the resulting states s * and s * * . So, the second condition is satisfied (result ‡). Due to the execution of the same statements, all variables are updated by the same expressions. Based on the constraint on the models and the assumption s ∼ δ s , we conclude that all the variables except of Var ∆ have the same values (defined by the same expressions on un-timed variables). The values of Var ∆ are updated to now and, by the result ‡, they still have δ-difference. So, s * and s * * satisfy the first condition. The messages sent to other rebecs during handling m and m are sent at the same point with the same parameters (defined by expressions on untimed-variables).
As their local timers have δ-difference, the arrival and deadline of sent messages have δ-difference. So, the third condition is also satisfied.
Corollary 5.3. For the given FTTS S, s 0 , → , assume the states s, s ∈ S such that s ∼ δ s . Then, s and s are strongly bisimilar.
Proof. To show that s and s are strongly bisimilar, we construct a strong bisimulation relation R such that (s, s ) ∈ R. Construct R = {(t, t ) | t ∼ δ t }. We show that R satisfies the transfer conditions of strong bisimilarity. For an arbitrary pair (t, t ), we must show that • If (t, m, t * ) ∈→, then there exists t * * such that (t , m, t * * ) ∈→ and (t * , t * * ) ∈ R; • If (t , m, t * * ) ∈→, then there exists t * such that (t, m, t * ) ∈→ and (t * , t * * ) ∈ R.
The relaxed-shift equivalence preserves the conditions of shift equivalence on all variables except the time related variables, i.e., Var ∆ . Furthermore, it preserves the conditions of shift equivalence on all messages in the bag except for messages Msg ex . But the condition on parameters of msgpar ex , i.e., (cond (m)(msgpar ex (m)) ⇔ cond (m )(msgpar ex (m ))) ensures that the same statements of the corresponding message server will be executed. Therefore, by Corollary 5.3 any FTTS modulo relaxed-shift equivalence is strongly bisimilar to its original FTTS, and it not only preserves the local timing properties (those properties checked on variables of Var ∆ in model specification like now − lastPub < N pub ) of the original one but also preserves the timing properties defined on events (taking messages from the bag).
Example 5.4. Figure 12 shows part of the FTTS for the Publisher-Subscriber pattern. As we see all local times and the values of lastPub are shifted one unit in states s 17 and s 20 , so the first and the second conditions of Definition 5.1 are satisfied. The message contents of their bags are equal in all rebecs except for the rebec si. This rebec has a RcvPublish message in its bag in both states that their life values are different but both of them are greater than the R sub value. So the third condition of Definition 5.1 is satisfied too and the states are relaxed-shift equivalent and we can merge them. Respectively, we can merge states s 22 with

Case Studies
Our reduction techniques are more applicable when using several patterns and devices, as one might find in an interoperable medical system. We applied our techniques on the following two interoperability scenarios, modeled based on the guidelines given in Section 4.2. The first case scenario relies on the Initiator-Executor pattern while the second one uses the Publisher-Subscriber and Request-Responder patterns.
6.1. X-Ray and Ventilator Synchronization Application. As summarized in [HKL + 12], a simple example of automating clinician workflows via cooperating devices addresses problems in acquiring accurate chest X-ray images for patients on ventilators during surgery [LHH + 99]. To keep the lungs' movements from blurring the image, doctors must manually turn off the ventilator for a few seconds while they acquire the X-ray image, but there are risks in inadvertently leaving the ventilator off for too long. For example, Lofsky documents a case where a patient death resulted when an anesthesiologist forgot to turn the ventilator back on due to a distraction in the operating room associated with dropped X-ray film and a jammed operating table [Lof05]. These risks can be minimized by automatically coordinating the actions of the X-ray imaging device and the ventilator. Specifically, a centralized automated coordinator running a pre-programmed coordination script can use device data from the ventilator over the period of a few respiratory cycles to identify a target image acquisition point where the lungs will be at full inhalation or exhalation (and thus experiencing minimal motion). At the image acquisition point, the controller can pause the ventilator, activate the X-ray machine to acquire the image, and then signal the ventilator to "unpause" and continue the respiration. An interoperable medical system realizing this concept was first implemented in [AGWL09].
Controller Ventilator X-Ray Figure 13. Communication between entities in the X-Ray and Ventilator Synchronization Application. We model the system assuming that the image acquisition point is identified. Controller initiates starting and stopping actions on two devices through the initiator-executor pattern. We define two instances of Initiator-Executor in the model for communication of the controller with ventilator and X-ray machine as shown in Figure 14. Each instance of the pattern needs one instance of InitiatorRequester and ExecutorInvoker classes as the interface between device/app and the communication substrate as explained in Table 2. The model of controller is given in Figure 15. The controller communicates with the communication substrate via IR VENTILATOR and IR X RAY , instances of InitiatorRequester. First the controller initiates a stop command to ventilator in its initialization in line 13. Upon receiving a successful acknowledgement through ack message, it initiates a start command to X-ray in line 18. Upon successful completion of the start command, informed via ack , it initiates a stop to X-ray in line 21 and then a start command to ventilator in line 23. Upon receiving an unsuccessful acknowledge or successful completion of the last command, the controller is terminated by sending a terminate message to itself.
As illustrated in Figure 16, the communication substrate extends the Base class for transmitting the two messages of these interface components. In itiatorRequester ir_v ( cs ) :(1 , 0 , 2) ; 4 ExecutorInvoker ei_v ( cs ) :(2 , 3 , 1) ; 5 Ventilator v ( ei_v ) :(3) ; 6 In itiatorRequester ir_x ( cs ) :(4 , 0 , 5) ; 7 ExecutorInvoker ei_x ( cs ) :(5 , 6 , 4) ; 8 X_Ray x ( ei_x ) :(6) ; 9 C o mm un ica ti on Sub st ra te cs () :(7) ; 10 } Figure 14. Main part of X-ray and ventilator application  Figure 15. The controller model in Timed Rebeca 6.2. PCA Safety Interlock Application. A Patient-Controlled Analgesia (PCA) pump is a medical device often used in clinical settings to intravenously infuse pain killers (e.g., opioids) at a programmed rate into a patient's blood stream. A PCA pump also includes a button that can be pushed by the patient to receive additional bolus doses of drug -thus allowing patients to manage their own pain relief. PCA infusion is often used for pain relief when patients are recovering from an operation. Despite settings on the pump that limit  Figure 16. X-Ray and ventilator communication substrate the total amount of drug infused per hour and that impose lock out intervals between each bolus dose, there is still a risk of overdose when using PCA pumps.
Symptoms of opioid overdose include respiratory depression in which a patient's blood oxygenation (SPO2 as can be measured by pulse oximetry) drops and expelled carbon dioxide (End-Tidal CO2 as can be measured by capnography) increases. A PCA pump alone has no way of telling if a patient is suffering from respiratory depression. However, using emerging interoperable medical system approaches that leverage MAP infrastructure, a pump can be integrated with a pulse oximeter (to measure blood oxygenation) and a capnometer (to measure ETCO2) and an additional control logic in a monitoring application as shown in Figure 17. The monitoring application looks for drops in SPO2 and increases in ETCO2, and if monitored values indicate that respiratory depression may be occuring, the application sends a command to the PCA Pump to halt infusion. Other signals (not shown in Figure 17) may be used to alert care-givers of a problem.
This scenario has been considered in a number of demonstrations in medical device interoperability research (see e.g.[APG + 10, KAL + 10]), in interoperability risk management [HVCW18], and is a subject of current standardization activities. The specifics of the model considered here are inspired by the prototype of Ranganath 2 that uses OMG's DDS message-passing middleware as the communication substrate.
The capnometer and oximeter devices publish data through the Publisher-Subscriber pattern, and the monitoring application detects if data strays outside of the valid range and sends the appropriate command to disable pump infusion. The model of monitoring application is given in Figure 18. Monitor, as the role of service in Publisher-Subscriber, consumes data published by capnometer and oximeter in its consume message server. It communicates with these devices via SI c and SI o which are instances of SubscriberInvoker. Upon receiving a consume message and detecting invalid values of SPO2 or ETCO2, it sends an inactive command to pump in lines 22 and 29. As monitoring app communicates  Figure 17. Communication between entities in the monitoring application.
with pump via the Requester-Responder pattern, it sends its commands to pump via RR p, an instance of RequestRequester. We abstractly model the invalid/valid values for SPO2 or ETCO2 by false/true values for the parameter data of consume message server. This parameter together with topic models the published data of devices.
As two devices (capnometer and oximeter) send data by using the Publisher-Subscriber pattern to the monitoring app, there are two instances of the Publisher-Subscriber pattern in the final model. The pump and monitoring app communicate via the Requester-Responder pattern. In the resulting Timed Rebeca model of the application, we define two instances of PublisherRequester and SubscriberInvoker interfaces in main and one instances of Re-questRequester and ResponderInvoker, as shown in Figure 19. The instance of Communica-tionSubstrate class shown in Figure 11, called cs, is used by all the components to send their messages and it includes four message servers for transmitting the messages of these two patterns.
the verification results, we can adjust the network by dynamic network configuration or capacity planning in organizations. We specify a communication substrate class for each shared network settings based on our proposed template in Section 4.2 and adapt the delay values on transmitting messages and priorities on handling messages. We make an instance from each class for those device/apps that communicate over its corresponding shared network. We consider three different network settings and hence, three communication substrate models for the PCA safety interlock application: • The first model shown in Figure 11 imposes a non-deterministic delay on transmitting the messages of both patterns. The number and possible values for the delays are the same for all messages of both patterns.
• The second model considers the same number (which is also equal to the first model) but different values for the delays. • In the third model as shown in Figure 20, the network handles messages of the Publisher-Subscriber pattern with a higher priority over the messages of Requester-Responder. This is implemented by using @priority statement before their message servers. Communication substrate handles messages based on their arrival time. Messages that are arrived at the same time, are handled based on their priorities. A lower value indicates to a higher priority.  Figure 20. Communication substrate model with applying priority to patterns 6.4. Experimental Results. We extended Afra which applies our reduction technique during the state-space derivation of a complete given model. The tool adds a state to the set of previously generated states if it is not relaxed-shift equivalent to any of them. This onthe-fly application of reduction during state-space generation results in an efficient memory consumption. Our tool currently does not support the third condition of Definition 5.1 and we have hard-coded the comparison on messages in the state-space generator for the case study: If the message is of RcvPublish type, we compare the result of life < R sub instead of comparing the value of life.
We applied our reduction technique on the model of some patterns and case studies 3 . We got 23% reduction for Requester-Responder, 32% for Publisher-Subscriber, 7% for Initiator-Executor and and 8% for Sender-Receiver. The Initiator-Executor and The Sender-Receiver pattern only have variables measuring the interval between two consecutive messages while the Requester-Responder and Publisher-Subscriber patterns also have remaining lifetime parameter in their messages (life) for which our reduction technique relaxes the merge condition. So, the first two patterns have more reduction as their states may reduce with the first and third conditions of Definition 5.1, but the states of Initiator-Executor and Sender-Receiver only reduce with the first condition. In the PCA Monitoring Application which is a medical system using several patterns as explained in Section 6 we have 29% reduction in the state space and for the X-ray and ventilator application we have 27% reduction. Table 4 shows the reduction of the three network models described in Section 6.3. As we see the reduction in the first model is 28.82%. As the possible delay values are increased for one pattern in the second model, the state space size grows and the reduction increases to 28.92%. In the prioritized model, the resulting state space is smaller than the others. After applying the reduction approach, the state space size reduces to 23.9%. for larger state spaces we have more reduction, hence in more complicated systems with more components, we will have a significant amount of reduction in the state space to analyze the system more easily. 10] to address expanded versions of the applications in Sections 6.1 and 6.2. The approach uses a domain-specific modeling language based on Extended Finite State Machines. A transformation from the modeling language to Java provides simulation capabilities, and a translation to UPPAAL provides model-checking capabilities. Similar to [APG + 10], the focus is on exposing the abstract functional behavior of devices and applications rather than more details of the middleware communication and associated communication timing.
The PhD dissertation of King [Kin16] provides the closest capture of component-related timing properties related to the communication patterns [RKHR15] and our abstract modeling of the patterns. [Kin16] defines a domain-specific language for distributed interoperable medical systems with a formal semantics that takes into account the details of tasking and communication. As opposed to focusing on verification, the emphasis of the formalism is to provide a foundation for establishing the soundness of sophisticated real-time scheduling and component interactions of a novel time-partitioning middleware developed by King using Google's OpenFlow software-control network switches. King constructs a dedicated refinement-checking framework that addresses communication time and task and network scheduling using the symbolic representations of timing constraints based on UPPAAL's "zone" representation. A number of experiments are performed to assess the scalability and practical effectiveness of the framework.
Larson et al. [LCH13] specify a more detailed version of the PCA Monitoring Application of Section 6.2 using the Architecture Analysis and Definition Language (AADL). Simple functional properties of components are specified on AADL component interfaces using the BLESS interface specification language [LCH13]. Component behaviors are specified using the BLESS-variant of AADL's Behavior Annex -a language of concurrent state machines with communication operations based on AADL's real-time port-based communication. The BLESS theorem prover was used to prove in a compositional manner that component state machine behaviors conform to their BLESS interface specifications and that the composition of components satisfies important system-level behavior specifications. Compared to the approach of this paper, [LCH13] focuses on compositional checking of richer functional properties using theorem proving techniques and does not expose the time-related details of communication patterns considered in the model-checking based verification in this paper.
Each of the works above has different strengths that contribute important practical utilities. The long-term vision for specification and verification of interoperable medical systems would almost certainly include a suite of techniques that work on a modeling framework supporting realistic and detailed architecture descriptions and embedded system implementations. Interface specifications would be used to specify component behavior for functional, timing, and fault-related behavior. It is likely that both deductive methods and model checking techniques would be needed to support both compositional contract-based reasoning as well as system state-space exploration (with domain-specific partial order reductions that account for scheduling and atomicity properties of the framework). The work presented in this paper complements the works above by focusing on one part of this larger vision, i.e., it illustrates how an existing framework for timed actor-based communication can be leveraged to specify and verify timing-related abstractions of middleware communication between components.
For work that does not focus on MAP-based architectures, [SdSP + 19] models and verifies biomedical signal acquisition systems using colored Petri nets in [SdSP + 19]. The Model checkers UPPAAL and PRISM [KNP11] are used to verify autonomous robotic systems as the physical environment of robots has timing constraints and probability [LFD + 19]. To tackle the state-space explosion, reduction techniques such as symmetry and counter abstraction [CKNZ11] are used to verify the models of swarm robotic systems.

Conclusion and Future Work
In this paper, we formally modeled composite medical devices interconnected by communication patterns in Timed Rebeca modeling language. We analyzed the configuration of their parameters to assure their timing requirements by Afra tool using the model checking technique. Since modeling many devices using several patterns results in state-space explosion, we proposed a reduction technique by extending FTTS merging technique with regard to the local timing properties. We illustrated the applicability of our approach on two model scenarios inspired by real-world medical systems. We applied our reduction technique on these models. Our results show significant reduction in systems with a higher number of components. We proposed guidelines and templates for modeling composite systems. Our templates take advantage of inheritance concept in Timed Rebeca in order to have a common communication substrate among instances of patterns.
Enriching our models by adding some modal behaviors to devices/apps is among our future work. For example, we can consider different operational modes for the monitoring application in PCA safety interlock application to verify the operational logic of monitoring application. The modes can be normal, degraded, and failed operation. In the normal operation mode, the monitoring app makes decisions based on inputs from both the pulse oximeter and the capnometer. In degraded mode, one of the two devices has failed or gone offline, in that case, the logic in the monitoring app only uses information from the non-failing device. In the failed operation mode, both monitoring devices have gone off-line and the clinician should be notified via an alarm. By modeling the scheduling algorithm of communication network, we can measure communication latency more precisely.
We aim to generalize our reduction approach by automatically deriving constraints on state variables like the one for lastPub or message contents to relax shift-equivalence relation in other domains. To this aim, we can use the techniques of static analysis. Defining a specific language to model the composition and coordination of medical devices, leveraging the proposed communication patterns is among our future work.