• No results found

Formal verification techniques for the platform integration

CHAPTER 2 : Related Work

2.2 Formal verification techniques for the platform integration

One challenge that arises by separating timing concerns is to reason about the correctness of the integration of the platform-independent and the platform-dependent codes. In par-

ticular, when it comes to timing properties, this reasoning can be challenging due to the complex timing interactions that come from different levels of timing abstraction. There have been a number of approaches to bridge such timing gaps between a high-level model and its implementation. Here are a few works that are closely related to our work:

The work proposed by Altisen et al. [11] studied whether timed automata can be imple- mented on a given platform satisfying a desired property using its standard semantics. Our work also relies on timed automata semantics to abstract the platform-independent timed behavior, but with three major differences between Altisen’s and our work: firstly, their implementation methodology that transforms a timed automaton into a program is similar to our implementation schemes in a sense that both study the possible ways to implement a timed automata on a given platform. However, Altisen’s work studied only a restricted set of implementation methodologies, whereas we provide more general sets of implemen- tation schemes. For example, (a) the buffering scheme for the communication between a platform and a program, and (b) the polling scheme for reading environmental signals, are commonly used implementation schemes that we consider; however, their work only consid- ers the communication scheme using a shared-variable, and the interrupt-based scheme in reading inputs from the environment. Secondly, Altisen’s work does not give details about how one can systematically transform an original timed automata model into a program model. Our work focuses on providing a systematic algorithm so that the transformation from the platform-independent model to the platform-specific model can be automated given an implementation scheme. Thirdly, Altisen’s work focuses more on studying the property preservation under platform refinements; that is, when a slower platform is re- placed with a faster one, they want to check whether the same property holds or not. On the other hand, our work focuses on providing a framework that enables one to compose a platform-independent model with a particular implementation scheme so that the composed platform-specific model can be used to verify timing properties.

can be combined with the platform-independent model. These works introduced how an abstract model (that is matched to ourPIM) can be transformed into a physical model (that is matched to ourPSM). The basic idea of their transformation is to construct the physical model by assigning the execution time to each action transition of the abstract model (i.e., transitions that are associated with input or output synchronization); more specifically, a single transition in the abstract model is decomposed into two separate transitions in the physical model. At the first transition, the clocks used in the abstract model freeze while performing the synchronization (i.e.,time does not flow while performing synchronizations), then, at the second transition, it compensates the execution time of the input (or the output) by adding timing guards associated with additional clock variables, which enables the transition to be completed after a constant execution time. However, this transformation simplifies several platform-specific aspects on which our work wants to focus. To the best of our knowledge, for example, their transformation does not consider a notion of event buffering or invocation mechanisms. Hence, the following scenarios cannot be captured and verified in their physical model: (1) "even though an input event is read by the platform, the input may not lead to a transition in the model due to a buffer over-run condition, (2) "when the generated code invoked is too slow while the frequency of the input generated from the environment is relatively faster, the code may not process all the inputs".

Wulf et al. [54] proposed an approach to tackle the timed automata implementability prob- lem based on a new semantics called Almost ASAP that is parameterized by a platform- processing delay. It presented a way to check whether a model that is constructed using this semantics can be implemented with a sufficiently fast platform; and if a faster platform replaces a slower one, the property still remains hold. However, Wulf’s work didn’t consider what constitutes the platform-specific delays specifically, wheres our work focuses on the source of timing delays that affects the platform-processing delays.

Bonakdarpour et al. [18] proposed a way to desynchronize distributed components modeled as the BIP semantics (Behavior, Interaction, Priority) in a way that the behavior of the

transformed BIP components is observationally equivalent with that of the original BIP model. During the desynchronization process, they inserted a notion of manager that me- diates the communication among distributed BIP components in an asynchronous manner. Even though the distributed setting of their work is different from the stand-alone setting of ours, the problem of the interaction desynchronization is similar to our problem. However, they did not consider timing issues, whereas our main focus is to desynchronize the timed behavior of the platform-independent model from its environment by inserting a platform.