Simulator for Real-Time Abstract State Machines

P. Vasilyev

1,2⋆

Laboratory of Algorithmics, Complexity and Logic, Department of Informatics, University

Paris-12, France

Computer Science Department, University of Saint Petersburg, Russia

Abstract. We describe a concept and design of a simulator of Real-Time Ab-

stract State Machines. Time can be continuous or discrete. Time constraints are

deﬁned by linear inequalities. Two semantics are considered: with and without

non-deterministic bounded delays between actions. Simulation tasks can be gen-

erated according to descriptions in a special language. The simulator will be used

for on-the-ﬂy veriﬁcation of formulas in an expressible timed predicate logic.

Several features facilitating the simulation are described: external functions deﬁ-

nition, delays settings, constraints speciﬁcation, and others.

1 Introduction

Usually the process of software development consists of several main steps: analysis,

design, speciﬁcation, implementation, and testing. The steps can be iterated several

times and accompanied by this or that validation. We are interested in the validation by

simulation of program speciﬁcations with respect to the given requirements. We con-

sider real-time reactive systems with continuous or discrete time. Time constraints are

expressed by linear inequalities and programs are speciﬁed as Abstract State Machines

(ASM) [1]. The requirements are expressed in a First Order Timed Logic (FOTL) [2,3].

The speciﬁcation languages we consider are very powerful. Even rather simple, “basic”

ASMs [4] are sufﬁcient to represent any algorithmic state machine with exact isomor-

phic modeling of runs. This formalism bridges human understanding, programming and

logic. The ASM method has a number of successful practical applications, e.g., SDL

semantics, UPnP protocol speciﬁcation, semantics of VHDL, C, C++, Java, Prolog (see

[5,6]).

To express properties of real-time ASMs we use FOTL. This logic is clearly unde-

cidable. There exist practical decidable classes [2,3]. We know from practice that most

errors in software can be revealed on rather simple inputs ; for reactive systems this

means that ﬁnite models of small complexity are usually sufﬁcient to ﬁnd very serious

errors.

Thus, we design our simulator as some kind of partial, bounded, on-the-ﬂy model-

checker. We consider two semantics, both with instantaneous actions, one without de-

lays between actions, another one, more realistic, with bounded non deterministic de-

lays between actions (by action here we mean an update of the current state, we make

it more precise below). The simulator checks the existence of a run for a given input,

⋆

Partially supported by ECO-NET project No 08112WJ.

Vasilyev P. (2006).

Simulator for Real-Time Abstract State Machines.

In Proceedings of the 4th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages

202-205

DOI: 10.5220/0002501002020205

 SciTePress

outputs details of the run that can be speciﬁed in a special language, and checks the re-

quirements formula for this run. There are several implementations of ASM interpreter

or compiler, such as the Microsoft AsmL [7], Distributed ASML [8], Michigan inter-

preter, Gem-Mex. These systems do not deal with real-time ASMs or predicate logic

requirements.

2 Timed ASM

In this paper by an ASM we mean timed basic Gurevich abstract state machine. A

timed ASM is a tuple (V, IS, P rog), where V is a vocabulary, IS is a description of

the initial state, and P rog is a program. The vocabulary consists of a set of sorts, a

set of function symbols, and a set of predicate symbols. The following pre-interpreted

sorts are included: R is the set of reals; Z is the set of integers; N is the set of natural

numbers; Bool is the set of Boolean values: true and false; T = R

special time sort;

Undef = {undef } is a special sort used to represent the undeﬁned values.

All functions of an ASM are divided into two categories: internal and external func-

tions. Internal functions can be modiﬁed by the ASM. External functions cannot be

changed by the ASM. On the other hand, the functions can also be divided into static

and dynamic functions. Dynamic external functions represent the input of the ASM. A

static function has a constant interpretation during any run of the ASM. Among the sta-

tic pre-interpreted functions of the vocabulary are arithmetical operations, relations, and

boolean operations. The equality relation “=” is assumed to be deﬁned for all types. The

timed ASMs use a special time sort T and a nullary function CT : → T which returns

the current “physical” time. Only addition, subtraction, multiplication and division by

a rational constant, standard equality and inequality relations are supported.

The program of the timed ASM is deﬁned in a usual way as a sequence of instruc-

tions of several types. The main constructions are: while-do and repeat-until loops,

forall and choose statements, etc.: a single update rule in the form of an assignment

A = {f(x

, . . . , x

) := θ}; a parallel block of update rules [A

; . . . ; A

] which are

executed simultaneously (this block is called an update block); a sequential block of

update rules {A

; . . . ; A

} which are executed in the order they are written; a guarded

rule, where Guard

, i ∈ 1, . . . , n are guard conditions and A

, i ∈ 1, . . . , n + 1 are

statements:

if Guard

then A

elseif Guard

then A

. . . else A

n+1

3 Simulator Conﬁguration

An external function deﬁnition looks as follows: f : X → Y, where f is its name,

X is an abstract sort, T is the pre-interpreted time sort, Y is an abstract sort or pre-

interpreted sort R. The sort X can be enumerated as a sequence of natural numbers.

Thus, we can deﬁne a function as follows: f (i) := (t

, f

; t

, f

; . . . ; t

, f

kk+1

; . . .)

where i ∈ 1, . . . , n, n is the cardinality of the sort X , t

, t

, . . . , t

, . . . are start time

points of intervals, f

, f

, . . . , f

kk+1

, . . . are function values deﬁned on the time left-

closed right-open intervals. Each function can be also deﬁned by an expression.

203

All updates in ASM [1] are instantaneous. In reality, it may take some time to per-

form an action. We model this by non-deterministic bounded delays between actions

that remain instantaneous. Some ideas of managing the process of time propagation al-

ready appeared, for example in [9,10]. We deﬁne a function of time delay δ : S → T

on the set of all statements and expressions which is denoted by S. For the sequential

composition the delay is calculated as a sum of delays of each function. For the parallel

composition the delay is the maximum of the delays of all functions. The delays can

be used in different ways. For example, we can have only two different time delays for

slow and fast operations making difference between operations with internal and shared

variables which are usually slower than operations with internal variables of a process.

Another way is to specify delays manually for each function or operation.

We consider a nondeterministic situation as a tuple of all possible choices with sev-

eral ways of element selection. The method should be deﬁned in the conﬁguration ﬁle

of the simulator by one assignment (the abbreviation ndr stands for non-determinisms

resolution). It can be the ﬁrst (last), minimal (maximal) element of the tuple.

To express requirements for ASMs one needs a powerful logic. In this work we con-

sider a First Order Timed Logic (FOTL) [2, 3] for representing the requirements. For

the Lamport’s Bakery [11] the following properties are required: Safety: ∀pq ∀t(p 6=

q → ¬(CS

◦

(t) ∧ CS

◦

(t))

Liveness: ∃c

∀pt(n

◦

(t) > 0 → ∃t

′

(t < t

′

< t + c

· δ

int

+ c

· δ

ext

∧ CS

◦

′

)))

where δ

int

> 0, δ

ext

> 0 (in the degenerated case we should use another formula).

4 Timed Abstract State Machine Semantics

In brief the process of simulating a system deﬁned by an ASML speciﬁcation in our

approach consists of the following steps: 1. Calculation of the next time point in which

at least one guard is true. 2. State update, which is represented by one or more statement

blocks. 3. Evaluation of constraints before and after the state update.

In the sequential mode of execution the next operation is taken, all required calcula-

tions are made and the state of the machine is changed. The current time value is simply

incremented by the value of current instruction time delay.

We consider a block of parallel instructions as a block of sub-machines running in

the same way as the top-level ASM but in its own space of states. Each sub-machine

has its own state change. The total change of state will be calculated as a union of state

changes of all sub-machines. If all pairwise intersections of state changes are empty

then they are consistent. If a parallel block is looped it can happen that there are no

instructions for the current time moment to be executed. To avoid inﬁnite looping we

have to wait for the closest time moment at which at least one of the guards turns to

true and some instructions can be executed. If such a time point exists it is calculated

and if it is not the time to exit the loop, the instructions concerning this time point are

executed. A case when all the delays are set to zero is detected by the simulator and a

warning message can be sent to the user.

204

5 Conclusion

In this paper several new important features concerning the semantics of the ASM based

language were described. These features will help us to build and verify speciﬁcations

of real-time systems via a customizable simulation of the models. The most impor-

tant parameters of simulation can be conﬁgured, i.e. external functions, time delays

for language operations and constructs, non-determinism resolving. The whole project

is aimed at development of a simulator for the described version of ASM language

extension where the results of the current work are used. At the moment a simulator

prototype is ready, which implements most of the speciﬁed features: lexical and syn-

tactical analysis, building a parse tree containing full information, loading deﬁnitions

of external functions from a ﬁle, loading the simulation parameters, simulation of most

constructs and operations of Timed ASML, output the results of simulation.

References

1. Gurevich, Y.: Evolving algebras 1993: Lipari Guide. In Egon, B., ed.: Speciﬁcation and

Validation Methods. Oxford University Press (1995) 9–36

2. Beauquier, D., Slissenko, A.: A ﬁrst order logic for speciﬁcation of timed algorithms: Basic

properties and a decidable class. Annals of Pure and Applied Logic 113 (2002) 13–52

3. Beauquier, D., Slissenko, A.: Periodicity based decidable classes in a ﬁrst order timed logic.

(Annals of Pure and Applied Logic) 38 pages. To appear.

4. Gurevich, Y.: Sequential abstract-state machines capture sequential algorithms. ACM Trans-

actions on Computational Logic 1 (2000) 77–111

5. Huggins, J.: (University of Michigan, ASM homepage) http://www.eecs.umich.edu/gasm/.

6. B

orger, E. St

ark, R.: Abstract State Machines: A Method for High-Level System Design and

Analysis. (2003)

7. Foundations of Software Engineering — Microsoft Research, Microsoft Corporation: AsmL:

The Abstract State Machine Language. (2002) http://research.microsoft.com/fse/asml/.

8. Soloviev, I. Usov, A.: The language of interpreter of distributed abstract state machines.

Tools for Mathematical Modeling. Mathematical Research. 10 (2003) 161–170

9. B

orger, E. Gurevich, Y., Rosenzweig, D.: The bakery algorithm: yet another speciﬁcation

and veriﬁcation. In B

orger, E., ed.: Speciﬁcation and Validation Methods. Oxford University

Press (1995) 231–243

10. Cohen, J., Slissenko, A.: On veriﬁcation of reﬁnements of timed distributed algorithms. In

Gurevich, Y., Kutter, P., Odersky, M., Thiele, L., eds.: Proc. of the Intern. Workshop on Ab-

stract State Machines (ASM’2000), March 20–24, 2000, Switzerland, Monte Verita, Ticino.

Lect. Notes in Comput. Sci., vol. 1912, Springer-Verlag (2000) 34–49

11. Lamport, L.: A new solution of Dijkstra’s concurrent programming problem. In: Communi-

cations of ACM, 17(8). (1974) 453–455

205