Achieving Discrete Relative Timing with Untimed Process Algebra A.J. Wijs CWI, Department of Software Engineering, P.O.Box 94079, 1090 GB Amsterdam, The Netherlands wijs@cwi.nl Abstract For many systems, timing aspects are essential. Therefore, when modelling these systems, time should somehow be represented. In the past, many timed pro- cess algebras have been developed, using untimed pro- cess algebras as initial inspiration. In this paper, we take another approach, considering the possibility to model timing aspects with an untimed process algebra. The advantage is that the algebra itself does not need to be extended, and the available tools can be reused. In contrast to other work, where this approach has been looked at, we focus on ease of modelling, and single delay steps of varying sizes. We present the timing mechanism used, our approach, and some examples. 1 Introduction Model checking has proven to be very useful in find- ing bugs in embedded system specifications. µCRL [13, 23], for instance, has been used to verify properties of many systems and protocols. Many cases, however, are time-critical, meaning that time should also play a role in specifications of those systems, in order to be able to check relevant properties. Over the years, the inclusion of time in modelling languages has shown to be complex, both on a theoretical and on a practi- cal level. As can be found in the literature, in theory, subjects like the extension of modelling languages with time [1, 2, 17, 20] and the design of relations between systems such as timed branching bisimilarity [9, 24] are very complicated, and at times difficult to get, and prove, correct. On the practical side, a major prob- lem in model checking is the so-called state explosion problem, meaning that a linear growth of the number of processes placed in parallel in a specification leads to an exponential growth of the resulting state space. Adding time to a specification makes this problem even more difficult, often leading to infinite state spaces, such as when an action is allowed to happen at any time. In the past, based on the modelling language µCRL, which is basically the process algebra ACP [4] with abstract data types [15], a timed language, called timed µCRL [11], has been developed. For practical reasons, one of which is the aforementioned tendency of state spaces to be infinite, there are currently no tools for that language yet. In [6, 14], another approach was taken. There, the possibility to model time in regular, untimed µCRL was investigated, which would enable modellers to use the fully developed and highly optimised µCRL toolset [5] when dealing with timed systems. Moreover, existing relations between systems, such as branching bisimilarity [10], can then be checked on timed systems. What they finally presented was a framework, a recipe, to express processes involving some notion of time. It is very important that a modeller follows this recipe faithfully, otherwise unwanted and bizarre timing be- haviour might occur, such as the violation of principles like time determinism [2] and maximal progress [2], to which we will return later in this paper. Besides that, a delay of one time unit corresponds directly with one transition in the system, resulting in large sequences of delays whenever a big time jump has to be made. After that, in [22], this recipe was used as an in- spiration for a translation scheme from the timed lan- guage χ t [3] to µCRL. By this, it was again shown that time could be modelled using an untimed modelling language, but in some cases, most notably when us- ing alternative composition, it led to complex process terms. The complexity of the resulting process was not so problematic, since it was the result of an automatic translation, but a high complexity cannot be demanded when a modeller has to create the term directly. The work on modelling time in [6, 14] and the trans- lation scheme in [22] inspired us to investigate the pos- sibilities of modelling time in an untimed process alge- bra, such that: 1. The resulting timing mechanism makes sense, i.e. 1