The TASM Language Reference Manual Version 1.1 - Synrc

synrc.com

The TASM Language Reference Manual Version 1.1 - Synrc

The TASM Language Reference Manual

Version 1.1

November 7, 2006

Martin Ouimet and Kristina Lundqvist

Embedded Systems Laboratory

Massachusetts Institute of Technology

Cambridge, MA, 02139, USA

{mouimet, kristina}@mit.edu

c○2005-2007 Massachusetts Institute of Technology


This page is intentionally left blank.

2


Contents

1 Introduction 5

2 The Language 7

2.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Basic Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Hierarchical Composition . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Parallel Composition . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6.1 Thoughts about composition . . . . . . . . . . . . . . . . . . 31

2.6.2 Communication Between Different Machines . . . . . . . . . 31

2.7 TASM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.1 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.4 Machine Templates . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.5 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Syntax 35

3.1 Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Notational Conventions . . . . . . . . . . . . . . . . . . . . . 35

3.1.2 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.3 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.4 Arithmetic Operators . . . . . . . . . . . . . . . . . . . . . . 37

3.1.5 Logical Operators . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Plain-Text Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Basic Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.4 Machine Templates . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.5 Syntax Common to all Machine Templates . . . . . . . . . . 45

3.2.6 Main Machine . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.7 Sub Machine . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.8 Function Machine . . . . . . . . . . . . . . . . . . . . . . . 47

1


3.2.9 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Well-Formedness Rules . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4.2 Typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 Semantics 64

4.1 Preliminary Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.1.1 Operator Precedence . . . . . . . . . . . . . . . . . . . . . . 64

4.1.2 Calling Convention . . . . . . . . . . . . . . . . . . . . . . . 65

4.1.3 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Formal Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.1 Sugaring/Desugaring . . . . . . . . . . . . . . . . . . . . . . 66

4.2.2 Resource definitions . . . . . . . . . . . . . . . . . . . . . . 66

4.2.3 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.4 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.5 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.6 Execution Semantics . . . . . . . . . . . . . . . . . . . . . . 68

2


List of Figures

2.1 Hierarchical composition . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Time history of variable values and resource consumption . . . . . . . 30

3.1 Tree Nodes for XML Syntax Tree . . . . . . . . . . . . . . . . . . . 48

3.2 XML Top Level Syntax Tree . . . . . . . . . . . . . . . . . . . . . . 49

3.3 XML Syntax Tree for Project (proj) Node . . . . . . . . . . . . . . 50

3.4 XML Tags for Environment (env) Node . . . . . . . . . . . . . . . . 51

3.5 XML Tags for System (sys) Node . . . . . . . . . . . . . . . . . . . 53

3.6 XML Tags for System (tmpls) Node . . . . . . . . . . . . . . . . . 53

3.7 XML Tags for System (masm) Node . . . . . . . . . . . . . . . . . . 56

3.8 XML Tags for Template Constructor (cons) Node . . . . . . . . . . 57

3.9 XML Tags for Template Rules (rs) Node . . . . . . . . . . . . . . . 58

3.10 XML Tags for Function ASM Template (fasm) Node . . . . . . . . . 60

3


List of Tables

2.1 Special Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Reserved Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 XML Tags for Top Level Syntax Tree . . . . . . . . . . . . . . . . . 49

3.4 XML Tags for Project (proj) Node . . . . . . . . . . . . . . . . . . 50

3.5 XML Syntax Tree for Environment (env) Node . . . . . . . . . . . . 51

3.6 XML Syntax Tree for System (sys) Node . . . . . . . . . . . . . . . 54

3.7 XML Syntax Tree for Templates (tmpls) Node . . . . . . . . . . . . 54

3.8 XML Syntax Tree for Main Machine Template (masm) Node . . . . . 56

3.9 XML Syntax Tree for Template Constructor (cons) Node . . . . . . 57

3.10 XML Syntax Tree for Template Rules (rls) Node . . . . . . . . . . 58

3.11 XML Syntax Tree for Function Machine Template (fasm) Node . . . 61

4.1 Operator Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4


Chapter 1

Introduction

This document serves as the central reference for the syntax and semantics of the Timed

Abstract State Machine (TASM) language. The TASM language is a specification language

used to specify and simulate the behavior of real-time systems. The type of

behavior that can be expressed in the TASM language includes functional behavior, in

pre-condition/effect style, timing behavior, and resource consumption behavior. The

TASM language is based on the principles of state-transition systems and durative

actions. The TASM language is an extension of the Abstract State Machine (ASM)

language [5], formerly known as evolving algebra. The TASM language has been designed

to specify and simulate the behavior of reactive real-time embedded systems.

Reactive systems are a class of systems that operate in an infinite loop, in a sequence

of ”sense-reason-actuate” actions. In reactive systems, the environment is the master of

the interaction, and the computer system must exhibit correct dynamic behavior during

its continuous interaction with the environment. The real-time facet of target systems

requires that operational correctness is not limited to functional correctness but must

also include timing correctness. Timing correctness reflects the physical reality that

actions take a finite amount of time to complete and hence a system will take a finite

amount of time to produce a response to an environment stimulus. The design and development

of real-time systems must ensure that a response to environmental stimulus

happens in a predictable amount of time (or at least be bounded). The embedded facet

of target systems requires that operational correctness is not limited to functional correctness

and timing correctness but must also include resource utilization correctness.

Embedded systems are typically limited in terms of resources (memory, processor, bus

bandwidth, etc.) and being able to predict that resource utilization will fall within certain

bounds is paramount to establishing operational correctness. The TASM language

provides a language that enables the specification and simulation of system behavior

along the function, time, and resource axes. Incorporating these three criteria in an

integrated language is a key contribution of the TASM language. The TASM language

forms the basis of a specification framework for embedded real-time systems. The

types of systems targeted by the specification language are those typically found in

process control in the aerospace industry (e.g., avionics) and the automotive industry

(e.g., drive-by-wire electronics).

5


The TASM language is an extension of the ASM language. The motivations and

benefits of using Abstract State Machines (ASM), formerly known as evolving algebras,

for hardware and software design have been documented in [2]. On the practicalside,

ASMs have been used successfully on a wide range of applications, ranging from

hardware-software systems to high-level system design [3, 5]. ASMs have also been

shown to be scalable to industrial size systems [4]. Furthermore, there is enough evidence

to believe that ASMs could provide a literate specification language, that is,

a language that is understandable and usable without extensive mathematical training

[6]. The preliminary evidence supporting the ease-of-use of ASMs revolves around

the small size of the syntax, the simplicity of the semantics, and the avoidance of extraneous

mathematical symbols. Moreover, the semantic distance, that is, the amount

of effort required to translate between one model to another, for example between a

design specification and an implementation, appears to be ”small” for ASMs. The

term ”small” is used in comparison to other formalisms that are predominantly visual

(e.g., timed automata) or that make heavy use of mathematical symbols (e.g., process

algebra).

On the theoretical side, ASMs have well-defined formal semantics, which makes

ASM specifications unambiguous and subjectable to formal analysis. ASM specifications

are also free from a specific verification method and can be verified either manually

or through automated tools [17]. Furthermore, ASM theory was developed as a

methodology for high-level system design [3]. Consequently, refinement, or the process

of gradually adding details to a system design, is an integral part of the theory, which

makes ASMs applicable at various levels of abstraction. Finally, ASM specifications

are executable, a useful property in the construction and validation of specifications

[9].

The anecdotal evidence supporting the success of the ASM method [2] suggests

that tailoring the formalism to the area of reactive real-time systems could achieve similar

benefits. This language reference extends the ASM formalism to make it amenable

to real-time system specification. More specifically, the ASM formalism is extended to

enable the explicit specification of timing behavior and resource consumption behavior.

The resulting specification language, named Timed Abstract State Machines (TASM),

enables the specification of functional and non-functional properties into a unified language.

The TASM language provides executable specifications that can express both

sequential and concurrent behavior.

This document is divided into 4 Chapters. The Language Chapter, Chapter 2, introduces

the basic concepts of the language from an informal perspective. The theory

on which the language is based is also introduced in this section. Chapter 3 explains

the syntax of the language, using two formats - an XML format, to enable export and

translation to other tools, and a text format, the ”display” format that is used in the

user interface of the TASM toolset. Motivations for syntax selections are explained in

this chapter and the syntax is expressed formally using grammars expressed in Backus-

Naur Form (BNF) and XML syntax trees. Finally, Chapter 4 expresses the semantics

of the language, using Abstract State Machines (ASM) as the formalism.

6


Chapter 2

The Language

The Timed Abstract State Machine (TASM) language is an executable language for

real-time system specification. The language is based on both the Abstract State Machine

(ASM) language [5] and the Extensible Abstract State Machine (XASM) language

[1]. The theory of Abstract State Machines has first been devised by Yuri Gurevich

as a language to express programming language semantics. The early history of

ASMs stems from Pascal compiler discrepancies that probed Gurevich to search for an

international standard of Pascal; when he could not find one, he came up with the idea

of writing his own semantics using a new language which he called evolving algebras.

Since this initial motivation, evolving algebras have taken on a life on their own and

have grown way beyond programming language semantics. The term evolving algebra

was dropped in favor of the term ”Abstract State Machine (ASM)”. ASM theory has

turned into a language and a methodology to express and reason about the dynamic

behavior of anything and everything. More specifically, the theory of Abstract State

Machines has developed into a methodology for high-level system design [3], including

the design of hardware and software components[2]. A cornerstone of the theory

is that of successive and provably correct refinements, that is, the gradual addition

of details from a high-level system design all the way down to implementation code.

The theory has been used successfully on a variety of projects in both industry and

academia. Nowadays, the theory is being used at Microsoft Research, to specify and

enforce interface behavior specifications, for the .NET platform, expressed in the AsmL

language [12]. Microsoft research has developed its own version of the ASM language,

which they have named ”AsmL” (Abstract State Machine Language). Other versions

of the language include the ASM Workbench, based on ASM-SL [14] and ASM Gopher

[13]. One might wonder why there are so many variations on the ASM language.

A good reason is that the original language was developed as a mathematical language,

by mathematicians (namely Yuri Gurevich)[10]. The original designers didn’t immediately

consider that the language would be implemented into computer-based tools. As

such, even though the original version of the language was simple, it does use special

symbols not found on computer keyboards. Furthermore, the mathematical nature of

the language didn’t address concerns that are important to programmers and computer

language users, such as types, object oriented concepts, etc. Furthermore, the original

7


version of the language was left generic on purpose, to allow the language to be tailored

to specific domains. More recently, the coreASM project [11] aims to develop a

generic ASM execution engine based on the original version of the ASM language [5].

The hope is that the coreASM engine will become the platform on which specialized

versions of the ASM language would be based.

The reader might also wonder why we need yet another language based on ASM.

The main reason is that so far, all of the languages implemented in tools have dealt only

with specification of sequential behavior (with the exception of the coreASM engine,

which is still in the early development stages). The specification of concurrent behavior

has been left open as an area of further research. Furthermore, the incorporation of time

into the language has been treated more on the verification side of the theory (notably

to analyze the famous railway crossing problem and Lamport’s Bakery algorithm [7]).

On the specification side, no efforts have been made to tailor the language to include

specification of time. The specification of resources is also another unexplored area,

but it is of lesser importance because resources can be viewed as just a special type of

dynamic functions. Time, however, influences not only the specification of sequential

behavior but also influences the ordering of execution for concurrent agents that share

a common concept of time. In a sense, time is not just another external dynamic function,

but it is also a synchronization mechanism between asynchronous agents. It is

the dual nature of time that motivates the development of another language based on

ASMs. Existing tools could not be reused or extended because the sequential nature

of the specifications would not allow the types of behavior that must be specified and

analyzed for concurrent systems. We realize that the TASM language development is

happening in parallel with the coreASM engine development, which will most likely

lead to redundant work. However, we hope that once the coreASM engine reaches

stability and maturity, the TASM language will also have reached maturity and will

be ported to the coreASM engine. As such, in our language design, we continuously

consider how our additions could be viewed as syntactic sugar for the minimal ASM

language first expressed by Yuri Gurevich [10].

2.1 Concepts

The concepts of Abstract State Machines (ASM) revolve around the concepts of an

abstract machine and an abstract state. Behavior in this language is specified as the

computing steps of the abstract machine and its effects on the abstract state. More

specifically, the dynamic behavior is expressed in the concept of a step, which corresponds

to a group of atomic updates made to global state. An update set is the term

used to describe the set of atomic updates that are associated with a single step. A run

of an ASM, is a sequence of steps, that is, a sequence of update sets. The global state

after each step can be obtained by applying individual update sets sequentially.

8


2.2 Basic Definitions

The term specification is used to denote the complete document that results from the

process of writing down a system design. In the ASM community, specifications

that contain only a single abstract state machine are known as basic or single-agent

ASMs[3]. Specifications that contain more than one abstract state machine are known

as multi-agent ASMs.

A basic abstract state machine specification is made up of two parts - an abstract

state machine and an environment. The machine executes based on values in the environment

and modifies values in the environment. The environment consists of two

parts - the set of environment variables and the universe of types that variables can

have. In the TASM language all variables are strongly typed. The machine consists of

four parts - a set of monitored variables, a set of controlled variables, a set of internal

variables, and a set of mutually exclusive rules. The monitored variables are the variables

in the environment that affect the machine execution. The controlled variables

are the variables in the environment that the machine affects. The internal variables

are the variables that make up the internal state of the machine but do not affect the environment.

The set of rules are named predicates that express the state evolution logic

by specifying how the variables in the environment are modified.

Formally, a specification ASMSP EC is a pair:

Where:

ASMSP EC = 〈E, ASM〉

• E is the environment, which is a pair:

Where:

E = 〈EV, T U〉

– EV denotes the Environment Variables, a set of typed variables

– T U is the Type Universe, a set of types that includes:

∗ Integers: NV U = {. . ., −1, 0, 1, . . .}

∗ Boolean constants: BV U = {T rue, F alse}

∗ Reals: RV U = R

∗ User-defined types: UDV U

• ASM is the machine, which is a four-tuple:

Where:

ASM = 〈MV, CV, IV, R〉

– MV is the set of Monitored Variables = {mv | mv ∈ EV and mv is readonly

in R}

9


– CV is the set of Controlled Variables = {cv | cv ∈ EV and cv is read-write

in R}

– IV is the set of Internal Variables = {(it, iv) | iv is a unique name and it ∈

T U is its type }

– R is the set of Rules = {(n, r) | n is a name and r is a rule of the form ”if

C then A” where C is an expression that evaluates to an element in BV U

and A is an action}

An action A is a sequence of one or more updates to environment variables, of the

form v := vu where v ∈ CV and vu is an expression that evaluates to an element in the

type of v.

Updates to environment variables are organized in steps, where each step corresponds

to a single rule application. A rule is enabled if its guarding condition, C,

evaluates to the boolean value T rue. A restriction on the set of rules is that they are

mutually exclusive, that is, only one rule can be enabled before each step. The update

set for the i th step (i ¿ 0), denoted U i , is defined as the collection of all updates to

controlled variables for the step. An update set U i will contain 0 or more pairs (cv, v)

of assignments of values to controlled variables. An update set is said to be consistent

if there are no conflicting updates in the set, that is, no variable is updated twice with

different values.

That is, an update set U is consistent if:

• For all two update pairs (cv1, v1), (cv2, v2) in U if cv1 = cv2 then v1 = v2

A run of a basic ASM is defined by a sequence, potentially infinite, of update sets.

For an ASM that terminates after n steps, a run would look like:

U 1 , U 2 , . . . , U n

The state progression can be obtained by applying the update set at each step. For

an ASM that terminates after n steps, the state progression would look like:

S 0 , S 1 , S 2 , . . . , S n

The state S 0 denotes the initial values of the environment at the beginning of the

machine execution. We introduce the ◦ operator to denote the application of the an

update set to the current state to yield a new state. More specifically:

S i = S i−1 ◦ U i (i > 0)

We differentiate between external and internal state. The external state is the set of

all environment variables. A specific instance of the state is a snapshot of the dynamics

at a fixed point in time (defined as a specific step of the machine). The internal state is

the set of all internal variables, not visible to the environment. We use these different

concepts of state to differentiate between observable and unobservable behavior. The

basic concepts explained so far are illustrated in TASM Example 1 which lists the basic

logic for a light controller that monitors the status of a switch and turns a light On/Off

depending on the status of the switch.

10


TASM Example 1 Light Switch Version 1

ENVIRONMENT:

USER-DEFINED TYPES:

light_status := {ON, OFF};

switch_status := {UP, DOWN};

VARIABLES:

light_status light := OFF;

switch_status switch := DOWN;

--------------------------------

MAIN MACHINE:

MONITORED VARIABLES:

switch;

CONTROLLED VARIABLES:

light;

INTERNAL VARIABLES:

RULES:

R1: Turn On

if light = OFF and switch = UP then

light := ON;

R2: Turn Off

if light = ON and switch = DOWN then

light := OFF;

11


A sample run with the initial environment ((light, OF F ), (switch, UP )) yields

one update set:

U 1 = ((light, ON))

After the update set is produced and applied to the environment, the machine halts

its execution because it no longer has any enabled rules.

The final state of the environment after the machine run is: ((light, ON), (switch,

UP )).

Formally:

• S 0 = ((light, OF F ), (switch, UP ))

• U 1 = ((light, ON))

• S 1 = S 0 ◦ U 1 = ((light, OF F ), (switch, UP )) ◦ ((light, ON)) = ((light, ON),

(switch, UP ))

2.3 Time

The basic ASM definition does not address time explicitly. A few attempts have been

made to extend the ASM formalism with timing concepts [5, 7, 16]. These attempts

have their merits but they have focused on the verification of ASM behavior without

explicitly addressing how time is to be specified. In these approaches, time is viewed

as just another external dynamic function that can be used in rule guards.

The TASM approach to time specification is to specify the duration of a rule execution.

In the TASM world, this means that each step of a machine will last a finite

amount of time before an update set is produced and atomically applied to global state.

The semantics of rule execution are that of a delay followed by an instantaneous state

update. These semantics are analogous to the principle of durative actions, where an

action takes a finite amount of time to complete before its effects are visible in the environment.

At the specification level, time gets specified for each rule. The specification

of time can take the form of a single value t, or can be specified as an interval [t min ,

t max ]. The lack of a time annotation for a rule is assumed to mean t = 0. The specification

of time using an interval is useful to capture the uncertain nature of specifying

time during the early stages of system design. Furthermore, using interval specification

adequately captures the interval nature of real-time systems to express worst-case and

best-case execution times. For sequential execution, the worst-case execution time is

defined as the longest executing path that code can take. The computation time is affected

by branching decisions and algorithmic concerns. The best-case execution time

is the opposite, that is, the fastest executing path that the code can take.

Formally, the set of rules R in the machine definition becomes:

• R = {(n, t, r) | where n and r are defined in Section 2.2, and t denotes the duration

of the rule execution and can be a single value, an interval, or the keyword

next}

12


The keyword next, used with time specification, is used to denote the execution

and time passing semantics of a machine that whose current rule execution will last

until the next event of interest. This construct is used to specify that the machine

will not do any ”useful” work until some outside party alters one of the values in the

environment. The next construct essentially states that time should elapse until an

event of interest occurs. This construct is especially helpful for a machine which has

no enabled rules, but which does not wish to terminate. In this case, the use of the next

construct will keep the machine alive in the event that rules will become enabled in the

future, depending on the actions of other machines. The use of the next construct is

explained in more details in Section!4.2.6.

In TASM the update set is extended to contain the time that it takes to execute a

rule. The symbol T U i is used to denote the timed update set of the i th step, where t i is

the step duration and U i is the update set:

T U i = (t i , U i )

The approach uses relative time between steps. The total time for a run is simply

the summation of the individual step times over the run.

A run of a timed basic ASM that terminates after n steps becomes:

T U 1 , T U 2 , . . . , T U n

t = Σ n i=1t i

The state concept is also extended to reflect the time value for the given state. While

the time values in the update sets are relative to the previous steps, the time values in

the state are absolute. A given run starts execution at time t = 0. The Timed State, T S i ,

where gt i denotes the global time is defined as:

T S i = (gt i , S i )

The sequence of states for a run that ends after n steps:

T S 1 , T S 2 , . . . , T S n

The ◦ operator is still defined for the state evolution:

T S i = T S i−1 ◦ T U i = (gt i−1 , S i−1 ) ◦ (t i , U i ) = (gt i−1 + t i , S i−1 ◦ U i )

For a run that ends after n steps, the total time of the run would be gt n .

The time model can be either discrete or dense, depending on the choice of the

specifier. Step times can take different durations during the same machine run. In

essence, t i can be viewed as randomly selected within the time interval for the rule that

produces the update set.

However, because time advances through the execution of steps, there is an inherent

discreteness in the passage of time. However, this discreteness does not limit the

granularity of step duration. The passage of time is illustrated in Section 4.2.6.

13


2.4 Resources

The specification of non-functional properties includes timing behavior as well as resource

consumption properties. A resource is defined as a global quantity that has a

finite size. Processor usage, memory, and bandwidth are examples of resources. Resources

are global and can be used by any ASM present in the specification. The

specification of resources is analogous to the specification of time. At the environment

level, each resource is given a name and minimum and maximum values. For example,

processor usage could be defined as a resource named processor, that has minimum

size 0 and maximum size 100.

Resource definitions are specified at the environment level. The environment E is

extended to reflect the definition of resources:

Where:

E = 〈EV, T U, ER〉

• EV and T U remained unchanged from Section 2.2

• ER is the set of named resources:

– ER = {(rn, rs) | rn is the resource name, and rs is the resource size

expressed as either a single value or an interval}

At the specification level, each rule specifies how much of a given resource it consumes,

either as an interval or as a single value. If a time specification is present,

the resource usage specification must follow it. The omission of resource consumption

specification is assumed to mean zero resource consumption. The semantics of

resource usage are assumed to be volatile, that is, usage lasts only through the step

duration. For example, if a rule consumes 25% of processor usage, the total processor

usage will be increased by 25% during the step duration and will be decreased by 25%

after the update set has been applied to the environment.

Formally, the rule definition R becomes:

Where:

R = 〈n, t, RR, r〉

• n and r are defined in Section 2.2

• t is defined in Section 2.2

• RR is the set of resources used by the rule where each element is of the form

(rr, ra) where rr ∈ ER is the resource name and ra is the resource amount

consumed, specified either as an interval or as a single value

Update sets are also extended to reflect resource consumption at each step. Each

update set is extended to include a set of resource usage pairs rc = (rr, rac) ∈ RC

where rr is the resource name and rac is a single value denoting the exact amount

14


of resource usage for the step. If a resource is specified as an interval, rac is a value

taken from the interval. The symbol T RU i is used to denote the timed update set, with

resource usage, of the i th step, where t i is the step duration, RC i is the set of consumed

resources, and U i is the update set:

T RU i = (t i , RC i , U i )

The execution semantics are also extended to reflect resource usage. Because resources

are limited quantities, if an executing ASM utilizes more than a resource’s

limits, execution halts. Execution is well-defined only if resource utilization falls below

the boundaries of the available resources. Resource usage is slightly different than

time in that the resource utilization for a given update set starts with the time of the previous

update set and lasts through the rule completion. The consumption of a resource

for an update set T RU i lasts during an open interval (gt i−1 , gt i ].

The state definition is also extended to reflect resource consumption:

T RS i = (gt i , SRC i , S i )

The sequence of states for a run that ends after n steps:

T RS 1 , T RS 2 , . . . , T RS n

For update sets with resources, the ◦ operator is defined as follows:

T RS i = T RS i−1 ◦T RU i = (gt i−1 , RC i−1 , S i−1 )◦(t i , RC i , U i ) = (gt i−1 +t i , RC i , S i−1 ◦U i )

For all gt in the open interval (gt i−1 , gt i ), the state T RS will be (gt, RC i , S i−1 ).

This definition reflects the behavior that resource consumption will begin with the start

of a rule execution and will last until the rule execution is finished.

The example from section 2.2 is extended to reflect the time and resource consumption

behavior. The example is listed in TASM example 2. The example uses two

resources, processor usage and memory usage.

Three sample update sets for different initial conditions of variable values are

shown below:

• Initial condition: ((light, OFF), (switch, UP))

Update set: ((5, ((memory, 200), (processor, 25)), ((light, ON))))

• Initial condition: ((light, ON), (switch, DOWN))

Update set: ((6, ((memory, 100), (processor, 15)), ((light, OFF))))

• Initial condition: ((light, OFF) (switch, DOWN))

Update set: ((0, ((memory, 0), (processor, 0)), ∅))

Formally, we can express the behavior and state progression of the first set of initial

conditions as follows:

• T RS 0 = (0, ((memory, 0), (processor, 0)), ((light, OF F ), (switch, UP )))

15


TASM Example 2 Light Switch Version 2

ENVIRONMENT:

USER-DEFINED VALUES:

light_status := {ON, OFF};

switch_status := {UP, DOWN};

RESOURCES:

memory := [0, 16000]; //bytes

processor := [0, 100]; //percentage

VARIABLES:

light_status light := OFF;

switch_status switch := DOWN;

--------------------------------

MAIN MACHINE:

MONITORED VARIABLES:

switch;

CONTROLLED VARIABLES:

light;

RULES:

R1: Turn On

t := [4, 10];

memory := 200;

processor := 25;

if light = OFF and switch = UP then

light := ON;

R2: Turn Off

t := 6;

memory := 100;

processor := 15;

if light = ON and switch = DOWN then

light := OFF;

R3: Else

else then

skip;

16


• T RU 1 = (5, ((memory, 200), (processor, 25)), (light, ON))

• T RS 1 = T RS 0 ◦ T RU 1 = (5, ((memory, 200), (processor, 25)), ((light, ON),

(switch, UP )))

For all times gt in the open interval (0, 5), the state TRS is (gt, ((memory, 200),

(processor, 25)), S 0 ). The same logic can be applied to the other two sample runs.

2.5 Hierarchical Composition

So far, we have dealt only with basic ASM specifications, that is, specifications that contain

only a single abstract state machine. These restrictions were sufficient because the

examples have been simple. However, for more complex systems, structuring mechanisms

are required to partition large specifications into smaller ones. The partitioning

enables bottom-up and top-down construction of specifications and creates opportunities

for reuse. We introduce the concept of hierarchical composition by introducing

different types of abstract state machines - main ASM, function ASM, and sub ASM. A

main ASM is a ”top-level” machine, that corresponds to a single thread of execution. A

main ASM cannot be used by other ASMs. A basic ASM specification is thus a specification

that contains a single main ASM. The two other types of machines, function

ASMs and sub ASMs are auxiliary ASMs that enable hierarchical composition.

The composition mechanisms included in the TASM language are based on the

XASM language [1]. In the XASM language, an ASM can use other ASMs in rule

declarations in two different ways - as a sub ASM or as a function ASM. A sub ASM

is a machine that is used to structure specifications hierarchically. A sub ASM has the

same syntax as a main ASM except for the designation of sub ASM. It yields an update

set which is merged with the update set of the parent machine. A function ASM is

a simple ASM that takes a set of inputs and returns a single value as output, similarly

to a function in programming languages. These two concepts enable abstraction of

specifications by hiding details inside of auxiliary machines.

The definition of a sub ASM is similar to the previous definition of machine ASM:

SASM = 〈n, MV, CV, R〉

Where n is the machine name, unique in the specification, and other tuple members

have the same definition as mentioned in previous sections. The execution and

termination semantics of a sub ASM are different than those of a main ASM. When

a sub ASM is invoked, one of its rules is selected, it yields a timed update set, and it

terminates. The use of the next keyword is forbidden in both sub and function ASMs.

The definition of a function ASM is slightly different. Instead of specifying monitored

and controlled variables, a function ASM specifies the number and types of the

inputs and the type of the output:

Where:

F ASM = 〈n, IV, OV, R〉

17


• n is the machine name, unique in the specification

• IV is a set of named inputs (ivn, it) where ivn is the input name, unique in IV ,

and it ∈ T U is its type.

• OV is a pair (ovn, ot) specifying the output where ovn is the name of the output

and ot ∈ T U is its type

• R is the set of rules with the same definition as previously stated, but with the

restriction that it only operates on variables in IV and OV.

A function ASM cannot modify the environment and must derive its output solely

from its inputs. The only side-effect of a function ASM is time and resource consumption.

A specification is extended to include the auxiliary ASMs:

Where:

ASMSP EC = 〈E, AASM, ASM〉

• E is the environment

• AASM is a set of auxiliary ASMs (both sub ASMs and function ASMs)

• ASM is the main machine

Semantically, hierarchical composition is achieved through the composition of update

sets. A rule execution can utilize sub machines and function machines in its effect

expression. Each effect expression produces an update set, and those update sets are

composed together to yield a cumulative update set to be applied to the environment.

To define the semantics of hierarchical composition, we utilize the semantic domain R

∪ {⊥}. The special value ⊥ is used to denote the absence of an annotation, for either a

time annotation or a resource annotation.

We define two composition operators, ⊗ and ⊕, to achieve hierarchical composition.

The ⊗ operator is used to perform the composition of update sets produced by

effect expressions within the same rule:

T RU 1 ⊗ T RU 2 = (t 1 , RC 1 , U 1 ) ⊗ (t 2 , RC 2 , U 2 )

= (t 1 ⊗ t 2 , RC 1 ⊗ RC 2 , U 1 ∪ U 2 )

The ⊗ operator is commutative and associative. The semantics of effect expressions

within the same rule are that they happen in parallel. This means that the time

annotations will be composed to reflect the duration of the longest update set:


⎪⎨ t 1

t 1 ⊗ t 2 = t 2

⎪⎩

max(t 1 , t 2 )

if t 2 = ⊥

if t 1 = ⊥

otherwise

18


The composition of resources also follows the semantics of parallel execution of

effect expressions within the same rule. The ⊗ operator is distributed over the set of

resources:

RC 1 ⊗ RC 2 = (rc 11 , . . . , rc 1n ) ⊗ (rc 21 , . . . , rc 2n )

= (rc 11 ⊗ rc 21 , . . . , rc 1n ⊗ rc 2n )

= ((rr 11 , rac 11 ) ⊗ (rr 21 , rac 21 ), . . . ,

(rr 1n , rac 1n ) ⊗ (rr 2n , rac 2n ))

= ((rr 11 , rac 11 ⊗ rac 21 ), ...

((rr 1n , rac 1n ⊗ rac 2n ))

In the TASM language, resources are assumed to be additive, that is, parallel consumption

of amounts r 1 and r 2 of the same resource yields a total consumption r 1 +

r 2 :


⎪⎨ rac 1

rac 1 ⊗ rac 2 = rac 2

⎪⎩

rac 1 + rac 2

if rac 2 = ⊥

if rac 1 = ⊥

otherwise

Intuitively, the cumulative duration of a rule effect will be the longest time of an

individual effect, the resource consumption will be the summation of the consumptions

from individual effects, and the cumulative updates to variables will be the union of the

updates from individual effects.

The ⊕ operator is used to perform composition of update sets between a parent

machine and a child machine. A parent machine is defined as a machine that uses

an auxiliary machine in at least one of its rules’ effect expression. A child machine is

defined as an auxiliary machine that is being used by another machine. For composition

that involves a hierarchy of multiple levels, a machine can play both the role of parent

and the role of child. An example of multi-level composition is given at the end of

this Section. To define the operator, we use the subscript p to denote the update set

generated by the parent machine, and the subscript c to denote the update set generated

by the child machine:

T RU p ⊕ T RU c = (t p , RC p , U p ) ⊕ (t c , RC c , U c )

= (t p ⊕ t c , RC p ⊕ RC c , U p ∪ U c )

The ⊕ operator is not commutative, but it is associative. The duration of the rule

execution will be determined by the parent, if a time annotation exists in the parent.

Otherwise, it will be determined by the child:

t p ⊕ t c =

{

t c

t p

if t p = ⊥

otherwise

19


The distribution of the ⊕ operator over the set of consumed resources is the same

as for the ⊗ operator:

RC p ⊕ RC c = (rc p1 , . . . , rc pn ) ⊕ (rc c1 , . . . , rc cn )

= (rc p1 ⊕ rc c1 , . . . , rc pn ⊕ rc cn )

= ((rr p1 , rac p1 ) ⊕ (rr c1 , rac c1 ), . . . ,

(rr pn , rac pn ) ⊕ (rr cn , rac cn ))

= ((rr p1 , rac p1 ⊕ rac c1 ), ...

((rr pn , rac pn ⊕ rac cn ))

The resources consumed by the rule execution will be determined by the parent,

if a resource annotation exists in the parent. Otherwise, it will be determined by the

child:

rac p ⊕ rac c =

{

rac c

rac p

if rac p = ⊥

otherwise

Intuitively, the composition between parent update sets and child update sets is

such that the parent machine overrides the child machine. If the parent machine has

annotations, those annotations override the annotations from child machines. If a parent

machine doesn’t have an annotation, then its behavior is defined by the annotations of

the auxiliary machines it uses.

Figure 2.1 shows a hierarchy of machines for an sample rule execution. Each numbered

square represents a machine. Machine ”1” represents the rule of the main machine

being executed; all other squares represent either sub machines or function machines

used to derive the update set returned by the main machine. Machine ”3” is

an example of a machine that plays the role of parent (of machine ”7”) and child (of

machine ”1”).

1

2 3 4

5 6

7

Figure 2.1: Hierarchical composition

Each machine generates an update set T RU i , where i is the machine number. The

derivation of the returned update set is done in a bottom-up fashion, where T RU ret is

the update set returned by the main machine:

20


T RU ret = T RU 1 ⊕ (

(T RU 2 ⊕ (T RU 5 ⊗ T RU 6 ))⊗

(T RU 3 ⊕ T RU 7 )⊗

T RU 4 )

The example from the previous sections is extended to illustrate the use of auxiliary

ASMs, in TASM example 5. The example has been extended with a function ASM

(example 3) and a sub ASM (example 4). The various machine definitions are separated

for clarity. The environment definition is the same as for version 1 of the example.

TASM Example 3 Auxiliary Function ASM Definition

FUNCTION MACHINE:

TURN_ON

INPUT VARIABLES:

switch_status ss;

OUTPUT VARIABLE:

light_status ls;

RULES:

R1: Turn On

t := [4, 10];

memory := 128;

if ss = UP then

ls := ON;

R2: Else

else then

ls := OFF;

The first step of two sample runs are shown below:

• Initial environment: ((light, OFF), (switch, UP))

Update set: (1, ((memory, 128)), ((light, ON)))

• Initial environment: ((light, ON), (switch, DOWN))

Update set: (6, ((memory, 1024)), ((light, OFF)))

The first sample run invokes the function ASM and obtains the step duration from

the main ASM definition and the resource consumption from the function ASM. The

second sample run obtains the variable updates and rule duration from the sub ASM

and the resource consumption from the main ASM.

The first sample run can be detailed as follows:

21


TASM Example 4 Auxiliary Sub ASM Definition

SUB MACHINE:

TURN_OFF

MONITORED VARIABLES:

switch;

CONTROLLED VARIABLES:

light;

RULES:

R1: Turn Off

t := 6;

if switch = DOWN then

light := OFF;

R2: Else

else then

skip;

TASM Example 5 Modified Rules of the Main Machine

R1: Turn On

t := 1;

if light = OFF and switch = UP then

light := TURN_ON(switch); //uses fASM

R2: Turn Off

memory := 1024;

if light = ON and switch = DOWN then

TURN_OFF(); //uses sASM

22


• T RS 0 = (0, ((memory, 0)), ((light, OF F ), (switch, UP )))

• Update set from function ASM: F T RU 1 = (5, ((memory, 128)), ∅)

• Update set from main ASM: RT RU 1 = (1, ((memory, ⊥)), ((light, ON)))

• Combined update set: T RU 1 = RT RU 1 ⊕ F T RU 1 = (1 ⊕ 5, ((memory, ⊥))

⊕ ((memory, 128)), ((light, ON)) ∪ ∅) = (1, ((memory, 128)), ((light, ON)))

• T RS 1 = T RS 0 ◦ T RU 1 = (0, ((memory, 0)), ((light, ON), (switch, UP ))

◦ (1, ((memory, 128)), ((light, ON))) = (1, ((memory, 128)), ((light, ON),

(switch, UP )))

The second sample run can be detailed as follows:

• T RS 0 = (0, ((memory, 0)), ((light, OF F ), (switch, UP )))

• Update set from sub ASM: ST RU 1 = (6, ((memory, ⊥)), ((light, OF F )))

• Update set from main ASM: RT RU 1 = (⊥, ((memory, 1024)), (∅))

• Combined update set: T RU 1 = RT RU 1 ⊕ ST RU 1 = (⊥ ⊕ 6, ((memory,

1024)) ⊕ ((memory, ⊥)), ∅ ∪ ((light, OF F ))) = (6, ((memory, 1024)), ((light,

OF F )))

• T RS 1 = S 0 ◦ T RU 1 = (0, ((memory, 0)), ((light, OF F ), (switch, UP ))) ◦ (6,

((memory, 1024)), ((light, OF F ))) = (6, ((memory, 1024)), ((light, OF F ),

(switch, UP )))

2.6 Parallel Composition

Because concurrency is an integral part of most real-time systems, the specification

formalism must be able to specify concurrent behavior. In the abstract state machine

world, this is achieved through multiple machines running in parallel. In the ASM

literature, concurrency is termed multi-agent ASMs [5]. There are two varieties of

multi-agent ASMs - synchronous and asynchronous. In the synchronous case, two

or more machines execute a single step in parallel and the resulting update sets are

checked for consistency, merged, and applied instantaneously to global state. In other

words, for m machines executing concurrently, each executing n steps, all groups of

step update sets, U ij , must be consistent. U ij denotes the i th step of the j th machine:

((U 11 , U 12 , . . . , U 1m ), . . . , (U n1 , U n2 , . . . , U nm ))

If a group of update sets is consistent for a given step, the updates sets are collected

into a single update set and applied atomically to global state. The process is repeated

for each step.

In the asynchronous case, there is no prespecified order in which a machine executes

a step. In fact, any ASM can perform any number of steps at a given time. This

23


lack of ordering enables the system designer to define the exact semantics of parallel

execution.

To enable specification of multiple parallel activities in a system, the TASM language

allows parallel composition of multiple abstract state machines. Parallel composition

is enabled through the definition of multiple top-level machines, called main

machines. Formally, the specification ASMSP EC is extended to include a set of

main machines MASM as opposed to the single main machine ASM for basic ASM

specifications:

Where:

ASMSP EC = 〈E, AASM, MASM〉

• E is the environment

• AASM is a set of auxiliary ASMs (both sub ASMs and function ASMs)

• MASM is a set of main machines ASM that execute in parallel

The definition of a main machine ASM is the same as from previous sections.

Other definitions also remain unchanged.

The semantics of parallel composition regards the synchronization of the main machines

with respect to the global progression of time. We define tb, the global time of

a run, as a monotonically increasing function over R. Machines execute steps that last

a finite amount of time, expressed through the duration t i of the produced update set.

The time of generation, tg i , of an update set is the value of tb when the update set is

generated. The time of application, ta i , of an update set for a given machine is defined

as tg i + t i , that is, the value of tb when the update set will be applied. A machine whose

update set, generated at global time tg p , lasts t p will be busy until tb = tg p + t p . While

it is busy, the machine cannot perform other steps. In the meantime, other machines

who are not busy are free to perform steps. This informal definition gives rise to update

sets no longer constrained by step number, but constrained by time. Parallel composition,

combined with time annotations, enables the specification of both synchronous

and asynchronous systems.

We define the operator ⊙ for parallel composition of update sets. For a set of update

sets T RU i generated during the same step by i different main machines:

T RU 1 ⊙ T RU 2 = (t 1 , RC 1 , U 1 ) ⊙ (t 2 , RC 2 , U 2 )


⎪⎨ (t 1 , RC 1 ⊙ RC 2 , U 1 ) if t 1 < t 2

= (t 2 , RC 1 ⊙ RC 2 , U 2 ) if t 1 > t 2

⎪⎩

(t 1 , RC 1 ⊙ RC 2 , U 1 ∪ U 2 ) if t 1 = t 2

The operator ⊙ is both commutative and associative. The distribution of the ⊙

operator over the set of resource consumptions is the same as for the ⊗ and ⊕ operators:

24


RC 1 ⊙ RC 2 = (rc 11 , . . . , rc 1n ) ⊙ (rc 21 , . . . , rc 2n )

= (rc 11 ⊙ rc 21 , . . . , rc 1n ⊙ rc 2n )

= ((rr 11 , rac 11 ) ⊙ (rr 21 , rac 21 ), . . . ,

(rr 1n , rac 1n ) ⊙ (rr 2n , rac 2n ))

= ((rr 11 , rac 11 ⊙ rac 21 ), ...

((rr 1n , rac 1n ⊙ rac 2n ))

The parallel composition of resources is assumed to be additive, as in the case of

hierarchical composition using the ⊗ operator:


⎪⎨ rac 1

rac 1 ⊙ rac 2 = rac 2

⎪⎩

rac 1 + rac 2

if rac 2 = ⊥

if rac 1 = ⊥

otherwise

At each global step of the simulation, a list of pending update sets are kept in an

ordered list, sorted by time of application. At each global step of the simulation, the

update set at the front of the list is composed in parallel with other update sets, using

the ⊙ operator and the resulting update set is applied to the environment. Once an

update set is applied to the environment, the step is completed and the global time of

the simulation progresses according to the duration of the applied update set.

Because each ASM step can take arbitrarily long, checking consistency of the update

sets involves a few more criteria (t ij denotes the duration of step i of machine j,

T RU ij denotes the update set for step i of machine j):

• For any pair of update sets occurring at the same global time t: ((t in , RC in , U in ), (t jm , RC jm , U jm ))

if t in < t jm then for all future update sets (t kn , RC kn , U kn ) such that ∑ p

k=i t kn ≤ t jm ,

the update sets ((t jm , RC jm , U jm ), (t kn , RC kn , U kn )) must be consistent.

What this criterion means is that consistency of updates made to global state must

be preserved through overlapping time intervals of parallel machines. For example,

if two machines write to the same environment variable, they need to do so at different

non-overlapping global times. For execution to be well-defined, there must be

no conflicting writes, meaning that overlapping update sets must be consistent. Parallel

composition, combined with time specification, enables the specification of both

synchronous and asynchronous systems.

The extreme cases of this modified formalism resolve to the base case multi-agent

ASMs. In the timed multi-agent ASM formalism, if all concurrent machines take the

same positive amount of time for each step (For all i, j, k : t ij > 0 and t kj > 0 and

t ij = t kj ) at every step, then the system is essentially a synchronous multi-agent ASM

system with linear time progression (with dt = t ij ). If all agents take a zero amount of

time at every step (For all i, j : t ij = 0), then the system is essentially an asynchronous

multi-agent ASM system with no time progression.

25


Clearly, the overlap of update sets will most likely lead to multiple consistency

violations if granularity is coarse and care is not taken into the design of the steps.

However, the consistency violations should yield insight into the parallelism and timing

characteristics of the application being studied. This insight will be preserved as

granularity is increased. The use of the next keyword in specifications changes meaning

slightly in the case of parallel machines. In the multi-agent case, the next keyword

means that a machine waits for a move by another agent, regardless of whether or not

the move affects the given machine’s execution.

Parallel composition also introduces contention between machines for resource

consumption. In the TASM language, no machine is preempted from using a resource.

However, if the resource is exhausted, an exception is thrown and results in update set

inconsistency. The shared resource model is simple and useful to model many resource

types.

Concurrent resource usage is assumed to be additive. For example, if, in a time

interval, two different machines use the same resource (in amounts r 1 and r 2 respectively),

the total amount used would be r 1 + r 2 .

Formally, we introduce the ⊙ operator to denote the parallel composition of two

update sets produced by two main machines that yield update sets with different durations:

• Update set by machine 1: T RU1 = (t1, RC1, U1)

• Update set by machine 2: T RU2 = (t2, RC2, U2)

• State when update set is produced: T RS i = (gt i , RC i , S i )

• if t1 = t2

– Combined update set: T RU = T RU1 ⊙ T RU2 = (t1, RC1 + RC2, U1 ∪

U2)

– T RS i+1 = T RS i ◦ T RU = (gt i + t1, RC i + RC1 + RC2, S i ⊙ (U1 ∪

U2)

• if t1 > t2

– Combined update set: T RU i = T RU1 ⊙ T RU2 = (t1, RC1 + RC2, U1)

– Combined update set: T RU i+1 = T RU1 ⊙ T RU2 = (t2 - t1, RC1, U2)

– T RS i+1 = T RS i ◦ T RU i = (gt i + t1, RC i + RC1 + RC2, S i ⊙ U1)

– T RS i+2 = T RS i+1 ◦ T RU i+1 = (gt i + t2, RC i + RC2, S i+1 ◦ U2)

• if t1 < t2

– Combined update set: T RU i = T RU1 ⊙ T RU2 = (t2, RC1 + RC2, U2)

– Combined update set: T RU i+1 = T RU1 ⊙ T RU2 = (t1 - t2, RC2, U1)

– S i+1 = T RS i ◦ T RU i = (gt i + t2, RC i + RC1 + RC2, S i ◦ U2)

– S i+2 = T RS i+1 ◦ T RU i+1 = (gt i + t1, RC i + RC1, S i+1 ◦ U1)

26


The example is further extended to illustrate the semantics of parallel composition.

An extra main machine is added to represent the control logic for a fan, operating in

parallel with the light. The logic for the fan and the light both utilize memory and

processor. Only the modified sections of the environment definition are shown for

brevity.

TASM Example 6 Environment Definition for Resources and Parallel Composition

RESOURCES:

memory := [0, 16000]; //bytes

processor := [0, 100]; //percentage

VARIABLES:

component_status light := OFF;

switch_status light_switch := DOWN;

component_status fan := OFF;

switch_status fan_switch := DOWN;

The main machine for the light control is shown below:

The main machine for the fan control is shown below:

For the initial environment ((light switch, UP ), (light, OF F ), (fan switch,

UP ), (fan, OF F )), the trace of update sets is shown below. Each machine will execute

a single step that modifies the environment. The update sets for the step of each

machine are shown below:

• Step 1 of machine LIGHT CONTROL : (4, ((memory, 300), (processor, 25)), ((light,

ON)))

• Step 1 of machine FAN CONTROL : (1, ((memory, 100), (processor, 35)), ((fan, ON)))

This example shows how steps from different machines can take a different amount

of time. The value 4 for machine LIGHT CONTROL and the value 1 for machine FAN CONTROL

were taken randomly from the intervals. The beginning of these steps happen at the

same time, but the different durations illustrate the semantics of parallel composition.

The time values of interest can be broken into five different intervals:

• t < 1: Execution of step 1 of both machines

• t = 1: Completion of step 1 of machine FAN CONTROL

• 1 < t < 4: Continued execution of step 1 of machine LIGHT CONTROL

• t = 4: Completion of step 1 of machine LIGHT CONTROL

• t > 4: Waiting for a change in the environment

The combined update sets for each time interval are shown below. The execution

of both machines overlaps only in the interval t ≤ 1. In the other intervals, the behavior

is that of individual machines. Updates to the environment are produced only at the

end of the step:

27


TASM Example 7 Light Main Machine Definition for Resources and Parallel Composition

MAIN MACHINE:

LIGHT_CONTROL

MONITORED VARIABLES:

light_switch;

CONTROLLED VARIABLES:

light;

RULES:

R1: Turn On

t := [4, 10];

memory := 300;

processor := 25;

if light = OFF and light_switch = UP then

light := ON;

R2: Turn Off

t := 6;

memory := 100;

processor := 15;

if light = ON and light_switch = DOWN then

light := OFF;

R3: Else

t := next;

else then

skip;

28


TASM Example 8 Fan Main Machine Definition for Resources and Parallel Composition

MAIN MACHINE:

FAN_CONTROL

MONITORED VARIABLES:

fan_switch;

CONTROLLED VARIABLES:

fan;

RULES:

R1: Turn On

t := [1, 8];

memory := 100;

processor := 35;

if fan = OFF and fan_switch = UP then

fan := ON;

R2: Turn Off

t := 2;

memory := 200;

processor := 25;

if fan = ON and fan_switch = DOWN then

fan := OFF;

R3: Else

t = next;

else then

skip;

29


• t < 1: (((memory, 400), (processor, 60)), ∅)

• t = 1: (((memory, 400), (processor, 60)), ((fan, ON)))

• 1 < t < 4: (((memory, 300), (processor, 25)), ∅)

• t = 4: (((memory, 300), (processor, 25)), ((light, ON)))

• t > 4: (((memory, 0), (processor, 0)), ∅)

Formally, the state evolution can be tracked through the following stages:

• T RS 0 = (1, ((memory, 0), (processor, 0)), ((light, OF F ), (fan, OF F )))

• T RU F AN CONT ROL,1 = (1, ((memory, 100), (processor, 35)), ((fan, ON)))

• T RU LIGHT CONT ROL,1 = (4, ((memory, 300), (processor, 25)), ((light, ON)))

• T RU 1 = T RU F AN CONT ROL,1 ⊙ T RU LIGHT CONT ROL,1 = (1, ((memory,

400), (processor, 60)), ((fan, ON)))

• T RU 2 = T RU F AN CONT ROL,1 ⊙ T RU LIGHT CONT ROL,1 = (3, ((memory,

300), (processor, 25)), ((light, ON)))

• T RS 1 = T RS 0 ◦ T RU 1 = (1, ((memory, 400), (processor, 60)), ((light,

OF F ), (fan, ON)))

• T RS 2 = T RS 1 ◦ T RU 2 = (4, ((memory, 300), (processor, 25)), ((light, ON),

(fan, ON)))

The time history of variable values and resource consumption for the run is also

shown in Figure 2.2.

ON

light status

ON

fan status

OFF

60

25

0

OFF

4

t

1

memory usage

processor usage 400

300

0

1 4

t

1 4

t

t

Figure 2.2: Time history of variable values and resource consumption

30


Table 2.1: Special Operators

Operator Signature Meaning

◦ State × Update Set → State Used to apply an update set to the state

⊗ Update Set × Update Set → Update Set Used to combine two update sets generated through

hierarchical composition, for update sets from

different effect expressions

⊕ Update Set × Update Set → Update Set Used to combine two update sets generated through

hierarchical composition, for update sets between

a parent machine and a child machine

⊙ Update Set × Update Set → Update Set Used to combine two update sets generated through

parallel composition

2.6.1 Thoughts about composition

From the point of view of the effects on the environment, there is no difference whether

or not an update set is generated from a single main ASM or through multiple parallel

main ASMs. The composition of main machines and the use of sub and function

machines is not indistinguishable to the environment. The environment only sees a

single update set, that is produced at each ”step” of the system. Once the composition

has been achieved, the composed system behaves as a single main ASM with no

composition. The difference occurs in the internal merging of update sets. In the case

of hierarchical composition, that is, update sets produced by sub ASMs and function

ASMs, the ⊗ and ⊕ operators are used to obtain the resulting update set from the use

of auxiliary ASMs. For parallel composition, that is, multiple update sets produced

by main ASMs, the ⊙ operator is used to obtain the resulting update set that is to be

applied to the environment. The special operators are listed in table 2.1.

2.6.2 Communication Between Different Machines

To enable communication between different machines, the TASM language provides

communication channels, in the style of the Calculus of Communication Systems (CCS) [15].

A communication channel is defined as a global object, uniquely identified by its name,

that is used by two machines to synchronize. When using a communication channel,

one machine plays the role of sender and the other machine plays the role of receiver.

The syntax for using a communication channel is based on CCS. For an example communication

channel named x, a sender would use x! to send a notification and a receiver

would use x to receive a notification.

Communication channels carry no data and are used solely for synchronization.

Communications are assumed to be instantaneous when both parties are available.

When a sender sends a notification and a receiver is not waiting for it, the sender is

blocked indefinitely. Time elapses in the sender until the receiver becomes available.

Once the communication is received, the sender resumes executing steps. The same

31


logic applies for a receiver awaiting a communication from a sender which is not immediately

available.

2.7 TASM Objects

The concepts outlined above are realized in a suite of logical objects in the TASM

language. This section gives the list of logical objects and their properties. The exact

syntax of how these objects are expressed is described in Chapter 3. The syntax

that was given in the examples above resembles the syntax explained in Chapter 3.

However, the syntax in the examples was a bit simplified to ease the introduction of

concepts.

2.7.1 Specification

In the logical objects, we refer to a specification as a the overarching concept or object

that includes all of the other objects. A specification is the complete document that

results from capturing a system design in the TASM language.

2.7.2 Project

The project is the top level object that contains the high-level metadata of the system

specification. The project has three attributes, the project name, the project description,

and the version of the syntax. The name and description are self-explanatory. The

version of the syntax is used to identify older versions of the syntax to preserve backwards

compatibility. Other attributes of the project that might be added in the future

might include modification times, authors, etc. There is only one project object per

specification.

2.7.3 Environment

The environment is the object that is used to represent the ”outside world”. The environment

object contains the list of user-defined types, which are finite enumerations,

the list of resources which are finite quantities, and the list of variables, which are

the values that affect and are affected by the execution of the various machines. The

environment is the global object that is accessible by all machine instances.

2.7.4 Machine Templates

In the examples that have been given so far, templates were not used. The reason for the

omission of templates is to simplify the examples. However, in the TASM language, a

machine definition, may it be a main, sub, or function machine, is a template. A machine

template is a parameterized version of a machine. The templates are instantiated

by using a constructor given as part of the template definition. The use of templates

enables reuse of specifications and the ability to have multiple versions of a machine

definition for a given system design. A system design becomes a list of instantiated

32


main machine templates. The concept of a machine template is analogous to the concept

of a class in object oriented programming languages. Main machine templates are

instantiated in the System object, for a given configuration.

There are three types of machine templates - main machine templates, function machine

templates, and sub machine templates. Each type of machine template contains

three identical attributes - a set of internal variables, a constructor, and a set of rules.

The internal variables are typed variables that are visible only inside the machine. The

constructor is used to initialize the machine through instantiation and to assign default

values to internal variables. The set of rules is a set of guarded commands that govern

the machine execution and its effects on the environment. Each rule also specifies the

duration of the rule application and the resources consumed during execution of the

rule.

Sub machine templates and function machine templates differ from main machine

templates in that they do not need to be explicitly instantiated. When a sub machine

template or a function machine template is used inside another machine, it is created

automatically without the need to explicitly invoke the constructor.

Main Machine Template

The main machines are the top-level abstract machines that represent a thread of execution.

If more than one main machine is present in a system configuration, the resultant

run is a multi-agent ASM run [5]. Instantiating multiple main machines is the way

to obtain parallel composition. A main machine template contains the three default

attributes of machine templates - internal variables, a constructor, and a set of rules.

Additional attributes of a main machine are a set of monitored variables and a set of

controlled variables. The set of monitored variables is the list of environment variables

that are used in the guarding conditions of the rules. The set of controlled variables is

the list of environment variables that are used in the effect conditions of the rules.

Function Machine Template

A function machine template describes a parameterized version of a function machine.

The idea behind a function machine is a machine with no functional side-effects that

can be used to define abstractions and macros. A function machine is a machine that

takes a set of typed inputs and returns a single typed output. Aside from the three default

attributes of machine templates, a function machine template also contains a set

of input variables and a single output variable. The set of input variables are typed

variables that are used to invoke the machine. The output variable is a typed variable

that is used to return a value from the machine when it is invoked. A function machine

is not allowed to modify the environment and must compute its output solely based on

the input values and the values of its internal variables. The rules of a function machine

are well-defined only if the guard and the rule make no reference to environment

variables.

33


Sub Machine Template

A sub machine is similar to a main machine except that the sub machine does not

execute in its own thread of execution. Instead, a sub machine executes inside of a main

machine and shares the thread of execution of the main machine. Sub machines are

used to achieve hierarchical composition. A main machine can use many sub machines

as part of its definition. A sub machine template contains the same attributes as a main

machine.

2.7.5 System

The system object is used to define instantiations of machine templates and initial conditions

of environment variables. In a sense, the system is used to define the instances

of templates that are to be used for a given design, and the parameters that are to be

used for simulation. A set of machine template instantiations and the set of initial

values for environment variables is termed a configuration. There is only one system

object per project. The set of templates and the environment can be thought of as defining

a library of components that can be used for a system design. A configuration can

be thought of as a specific system design using a subset of the components in the library

and a set of initial conditions.

Configuration

A configuration is a child of the system object. The system object can have multiple

child configurations. A configuration contains a name and a description so that it can be

referenced during simulation. A configuration also contains a list of main machine instantiations,

by invoking the constructors of the main machine templates. Furthermore,

the configuration also contains initial values for some of the environment variables.

The initial values specified in a configuration override the initial values of environment

variables specified in the environment.

34


Chapter 3

Syntax

This chapter describes the syntax of the TASM language. The syntax described in this

section covers two types of syntax - plain-text syntax and XML syntax. The syntax

used in the TASM toolset is referred to as the ”plain-text” syntax, which is a format

that can be expressed using formal language constructs, such as a context-free

grammar. This syntax resembles the syntax of popular programming languages. The

plain-text syntax is also the input format for the compiler and the parser. The plain-text

format will also be used to store the content of a TASM specification on the file system.

The XML syntax contains the same content as the plain-text syntax. However, using

XML provides benefits for translation into another language (e.g. the input language of

the model-checker UPPAAL) to interoperate with outside tools. Furthermore, the use

of XML syntax enables easy creation of specification documents in a readable format,

such as HTML. The attributes of both types of syntax are explained in more details in

their respective sections. This chapter contains three sections. Section 3.1 explains the

basic components of the syntax, such as types, operators, reserved words, and comments.

Section 3.2 details the plain-text syntax, using a formal grammar expressed in

Backus-Naur Form (BNF). Section 3.3 explains the XML syntax, using XML syntax

trees.

3.1 Basic Syntax

This section explains the basic syntactical constructs of the TASM language. More

specifically, this section gives the rules for constructing names, gives the list of reserved

keywords, the list of operators, and the general typing rules. Semantical topics, such as

operator precedence are given formally in Chapter 4. The concepts introduced in this

section are applicable to both the plain-text syntax and the XML syntax.

3.1.1 Notational Conventions

The following notational conventions are used in this section and subsequent sections.

• Each abstract type uses the prefix T ASM

35


• Constants are enclosed in single quotes (e.g. ’a’, ’1’, etc.), except where settheoric

notation is used

The formal grammar uses the basic symbols from BNF (e.g., {}, [], , etc.)

3.1.2 Names

The use of names is crucial in the TASM language; every type of object (variables,

types, resources, machines, etc.) is uniquely identified by its name. We define the

generic abstract type T ASMName to express the restrictions on individual names.

The type TASMName is used in the rest of this document when a name has the listed

restrictions. The TASM language also has a set of reserved keywords that cannot be

used as names. The complete list of keywords is shown in table 3.1.

TASMName is a string of characters

• Each character of TASMName can be either ’a’-’z’ or ’A’-’Z’ or ’ ’ or ’1’-’9’ or

’-’

TASMName must start with ’a’-’z’ or ’A’-’Z’

TASMName has a length: 1-64

TASMName is not a reserved keyword

TASMName is case-sensitive

• Each TASMName is unique in a given TASM specification

The restrictions on the uniqueness of TASMName’s might seem restrictive, especially

in the absence of namespaces, but imposing this restriction removes potential

ambiguities.

3.1.3 Types

The TASM language contains only simple types. There are no data structures, subtypes,

or polymorphic types. The TASM language is also strongly typed; there are no dynamic

types or type inference. All typing rules are enforced at compilation time and type

safety is assured if a TASM specification compiles correctly. The TASM language

supplies three default types:

• Integers = {. . . , −1, 0, 1, . . .}

• Floats = Rational Numbers (e.g., -1.11, -0.5, 0.0, 10.45, etc.)

• Booleans = {T rue, F alse}

36


Table 3.1: Reserved Keywords

Keyword Meaning

t

Used for time annotations

next Used in time annotations to denote a special value of time

now Used to obtain the value of the global clock

new Used to instantiate a machine template

Integer Denotes the integer datatype

Float Denotes the float datatype

Boolean Denotes the boolean datatype

False Denotes a constant in the boolean datatype

True Denotes a constant in the boolean datatype

and Denotes a logical connective

or Denotes a logical connective

not Denotes a unary operator

skip Denotes the production of an empty update set

else Denotes the special ”else rule”

// Used to comment out a given line

TASM also allows the definition of user-defined types, which are analogous to enumerations

in most programming languages. However, user-defined types are not assigned

integer values and are unordered. A user-defined type is a named type that can

be used to provide readable options and type safety. More specifically, a user-defined

type is a named type that contains one ore more named values. For example, we can

define user-defined types to denote the status of a light status or the mode of an airplane:

• light status = {ON, OFF}

• airplane mode = {Idle, Taxi, Takeoff, Cruise, Landing}

User-defined types are unordered sets of one or more elements where elements

must be unique. Each member element is a TASMName. Furthermore, the name of the

type is a TASMName.

The TASM language is a strongly typed language, meaning that all variables are

typed and that type-safety is enforced at compilation time. No type casting is allowed,

even from F loat to Integer. Future versions of the language might allow type casting

through functions supplied by the TASM language.

3.1.4 Arithmetic Operators

For Integer and F loat types, the TASM language provides the four basic arithmetic

operators, applicable only to operands of the same type:

• addition: +

37


• subtraction: −

• multiplication: ∗

• division: /

Operations between operands of disparate types is undefined and results in a compilation

error. For example, addition between an operand of type F loat or an operand

of type Integer results in a compilation error. The arithmetic operators are undefined

for Boolean types and for user-defined types.

The assignment operator is the only operator which is defined for all types. Like

for the other arithmetic operators, the assignment operator is defined only for operands

of the same type:

• assignment: :=

The assignment operator does not return a value (denoted by the special character

’⊥’.

3.1.5 Logical Operators

The following two logical operators are defined for all types. The signature of the

operators is T ype1 × T ype2 → Boolean where T ype1 = T ype2. Operators applied

to operands of different types are undefined and result in a compilation error.

• equal: =

• not equal: ! =

For Integer and F loat types, the TASM language supplies an additional four logical

operators:

• greater than: >

• greater than or equal to: >=

• less than: <

• less than or equal to:


Table 3.2: Operators

Operator Signature Defined for Types

+ T ype1 × T ype2 → T ype3, T ype1 = T ype2 = T ype3 Integer, Float

- T ype1 × T ype2 → T ype3, T ype1 = T ype2 = T ype3 Integer, Float

* T ype1 × T ype2 → T ype3, T ype1 = T ype2 = T ype3 Integer, Float

/ T ype1 × T ype2 → T ype3, T ype1 = T ype2 = T ype3 Integer, Float

:= T ype1 × T ype2 → ⊥, T ype1 = T ype2 All

= T ype1 × T ype2 → Boolean, T ype1 = T ype2 All

!= T ype1 × T ype2 → Boolean, T ype1 = T ype2 All

> T ype1 × T ype2 → Boolean, T ype1 = T ype2 Integer, Float

>= T ype1 × T ype2 → Boolean, T ype1 = T ype2 Integer, Float

< T ype1 × T ype2 → Boolean, T ype1 = T ype2 Integer, Float


etter achieved through two sets of syntax. The semantics of both sets of syntax are

equivalent and are described in Section 4.

The following section explains the formal grammar that is used to express the basic

concepts from the previous section, such as types, constants, variables, expressions, etc.

The formal grammar is used in both the XML and text syntaxes where applicable to

define the format of strings. The formal grammar is given in Backus-Naur Form (BNF)

where the syntactic symbol ’|’ means ”or”, ’[]’ means optional, and ’{}’ means 0 or

more instances (Kleene closure). The special form of the closure operator, denoted

’{} + ’ means 1 or more instances. Any constant is given inside of single quotation

marks. For example, the keyword denoting the type integer is given as ’Integer’. It is

important to distinguish between the syntactical ”optional symbol ’]’ and the constant

denoting the right bracket ”]”.

3.2.1 Basic Grammar

Formally, the BNF grammars for the concepts described so far is given below. The

first part of the basic grammar explains the rules for constructing names, constants,

and types. The second part of the grammar explains the rules for constructing expressions,

variables, and formulas. The TASM language ignores whitespace unless

whitespace is required. When whitespace is required, it is denoted by the token <

T ASMW hitespace >. Tab characters, space characters, new line characters, carriage

return characters, and form feed characters all represent whitespace.

40


TASMUCaseLetter > ::= ′ A ′ | ′ B ′ | . . . | ′ Z ′

< TASMLCaseLetter > ::= ′ a ′ | ′ b ′ | . . . | ′ z ′

< TASMLetter > ::= < T ASMUCaseLetter > | < T ASMLCaseLetter >

< TASMDigit > ::= ′ 0 ′ | ′ 1 ′ | ′ 2 ′ | ′ 3 ′ | ′ 4 ′ | ′ 5 ′ | ′ 6 ′ | ′ 7 ′ | ′ 8 ′ | ′ 9 ′

< TASMCharacter > ::= < T ASMLetter > | < T ASMDigit > | ′ ′

< TASMASCIIChar > ::= All standard ASCII characters

< TASMWhiteSpaceChar > ::= ′ ′ | ′ \t ′ | ′ \n ′ | ′ \r ′ | ′ \f ′

< TASMWhiteSpace > ::= {< T ASMW hiteSpaceChar >} +

< TASMIntLit > ::= [ ′ − ′ ] < T ASMDigit > {< T ASMDigit >}

< TASMFloatLit > ::= [ ′ − ′ ] < T ASMDigit > {< T ASMDigit >}

′ . ′ < T ASMDigit > {< T ASMDigit >}

< TASMBooleanLit > ::= ′ T rue ′ | ′ F alse ′

< TASMStringLit > ::= {< T ASMASCIIChar >}

< TASMName > ::= < T ASMLetter > {< T ASMCharacter >}

< TASMDescription > ::= < T ASMStringLit >

< TASMVariable > ::= < T ASMName >

< TASMUDTypeName > ::= < T ASMName >

< TASMTypeName > ::= ′ Integer ′ | ′ F loat ′ | ′ Boolean ′ | < T ASMUDT ypeName >

< TASMUDTypeMember > ::= < T ASMName >

< TASMUDTypeDef > ::= 41<

T ASMUDT ypeName > ′ := ′

′ { ′ < T ASMUDT ypeMember > { ′ , ′ < T ASMUDT ypeMember >} ′ } ′′ ;

< TASMConstant > ::= < T ASMIntLit > | < T ASMF loatLit > |

< T ASMBooleanLit > | < T ASMUDT ypeMember >


TASMValue > ::= < T ASMV ariable > | < T ASMConstant >

< TASMMachineName > ::= < T ASMName >

< TASMFMachineCall > ::= < T ASMMachineName > ′ ( ′ [< T ASMArithExpr > { ′ , ′ < T ASMArit

< TASMValueExpr > ::= < T ASMV alue > | < T ASMF MachineCall > | ′ now ′

< TASMArithOp > ::= ′ + ′ | ′ − ′ | ′ ∗ ′ | ′ / ′

< TASMArithExpr > ::= < T ASMV alueExpr > |

< T ASMArithExpr >< T ASMArithOp >< T ASMArithExpr > |

′ ( ′ < T ASMArithExpr >< T ASMArithOp >< T ASMArithExpr > ′ ) ′

< TASMBinLogicOp > ::= ′ >= ′ | ′ > ′ | ′ ::= < T ASMBooleanLit > |

< T ASMArithExpr >< T ASMBinLogicOp >< T ASMArithExpr > |

′ ( ′ < T ASMArithExpr >< T ASMBinLogicOp >< T ASMArithExpr >

< TASMLogicBinConn > ::= ′ and ′ | ′ or ′

< TASMLogicUnConn > ::= ′ not ′

< TASMLogicFormula > ::= < T ASMLogicExpr > |

< T ASMLogicF ormula >< T ASMLogicBinConn >< T ASMLogicF o

< T ASMLogicUnConn >< T ASMLogicF ormula > |

′ ( ′ < T ASMLogicExpr > ′ ) ′ |

′ ( ′ < T ASMLogicF ormula >< T ASMLogicBinConn >< T ASMLogicF

′ ( ′ < T ASMLogicUnConn >< T ASMLogicF ormula > ′ ) ′

< TASMExpr > ::= < T ASMArithExpr > | < T ASMLogicExpr > | < T ASMLogicF orm

< TASMVarDecl > ::= < T ASMT ypeName >< T ASMW hitespace >< T ASMV ariable > ′ ; ′

< TASMVarDeclInit > ::= < T ASMT ypeName >< T ASMW hitespace >< T ASMV ariable >

′ := ′ < T ASMConstant > ′ ; ′

42

< TASMNameDescPair > ::= ′ NAME : ′ < T ASMName >< T ASMW hitespace >

′ DESC : ′ < T ASMDescription >

< TASMVarInit > ::= < T ASMV ariable > ′ := ′ < T ASMConstant > ′ ; ′


3.2.2 Project

< TASMProjectDef > ::= ′ P ROJECT : ′ < T ASMNameDescP air >

3.2.3 Environment

< TASMResourceName > ::= < T ASMName >

< TASMResourceDef > ::= < T ASMResourceName > ′ := ′′ [ ′ < T ASMIntLit > ′ , ′ < T ASMIntLi

< TASMChannelName > ::= < T ASMName >

< TASMChannelDef > ::= ′ Channel ′ < T ASMW hiteSpace >< T ASMChannelName > ′ ; ′

< TASMEnvironDef > ::= ′ ENV IRONMENT : ′ < T ASMEnvT ypeDef >

< T ASMEnvV arDef >< T ASMEnvChannelDef >

< T ASMEnvResourceDef >

< TASMEnvTypeDef > ::= ′ T Y P ES : ′ {< T ASMUDT ypeDef >}

< TASMEnvVarDef > ::= ′ V ARIABLES : ′ {< T ASMV arDeclInit >}

< TASMEnvChannelDef > ::= ′ CHANNELS : ′ {< T ASMChannelDef >}

< TASMEnvResourceDef > ::= ′ RESOURCES : ′ {< T ASMResourceDef >}

43


3.2.4 Machine Templates

< TASMTemplateDef > ::= ′ T EMP LAT ES : ′ < T ASMMT emplatesDef >

< T ASMST emplatesDef >

< T ASMF T emplatesDef >

< TASMMTemplatesDef > ::= ′ MAIN MACHINES : ′ {< T ASMMT emplateDef >}

< TASMSTemplatesDef > ::= ′ SUB MACHINES : ′ {< T ASMST emplateDef >}

< TASMFTemplatesDef > ::= ′ F UNCT ION MACHINES : ′ {< T ASMF T emplateDef >}

44


3.2.5 Syntax Common to all Machine Templates

< TASMVariableList > ::= {< T ASMV ariable > ′ ; ′ }

< TASMRuleName > ::= < T ASMName >

< TASMRule > ::= < T ASMRuleName > ′ { ′

[< T ASMT imeSpec >]{< T ASMResourceSpec >} < T ASMRuleDe

< TASMTimeSpec > ::= ′ t ′′ := ′′ [ ′ < T ASMIntLit > ′ , ′ < T ASMIntLit > ′ ] ′′ ; ′ |

′ t ′′ := ′ < T ASMIntLit > ′ ; ′ |

′ t ′′ := ′′ next ′′ ; ′ |

′ t ′′ := ′′ dt ′′ ; ′

< TASMResourceSpec > ::= < T ASMResourceName > ′ := ′′ [ ′ < T ASMIntLit > ′ , ′ < T ASMIntLi

< T ASMResourceName > ′ := ′ < T ASMIntLit > ′ ; ′

< TASMRuleDef > ::= < T ASMRuleGuard >< T ASMW hiteSpace >< T ASMRuleEffect

< TASMRuleGuard > ::= ′ if ′ < T ASMLogicF ormula > ′ then ′

| ′ else ′ < T ASMW hiteSpace > ′ then ′

< TASMRuleEffect > ::= {< T ASMEffectExpression >} +

< TASMEffectExpression > ::= < T ASMAssignment > | < T ASMSubMachineCall > |

< T ASMChannelExpr > | ′ skip; ′

< TASMAssignment > ::= < T ASMV ariable > ′ := ′ < T ASMArithExpr > ′ ; ′

< TASMSubMachineCall > ::= < T ASMMachineName > ′ ( ′′ ) ′′ ; ′

< TASMChannelExpr > ::= < T ASMChannelName >< T ASMChannelOpChar > ′ ; ′

< TASMChannelOpChar > ::= ′ ′ | ′ ! ′

45


3.2.6 Main Machine

< TASMMTemplatesDef > ::= ′ MAIN MACHINE : ′ < T ASMNameDescP air >

< T ASMMV ars >< T ASMConstr >< T ASMRules >

< TASMMVars > ::= < T ASMContV ars >< T ASMMonV ars >< T ASMIntV ars >

< TASMContVars > ::= ′ CONT ROLLED V ARIABLES : ′ < T ASMV ariableList >

< TASMMonVars > ::= ′ MONIT ORED V ARIABLES : ′ < T ASMV ariableList >

< TASMIntVars > ::= ′ INT ERNAL V ARIABLES : ′ {< T ASMV arDeclInit >}

< TASMConstr > ::= ′ CONST RUCT OR : ′ < T ASMMachineName > ′ ( ′ [< T ASMP aramL

{< T ASMV arInit >} ′ } ′

< TASMParamList > ::= < T ASMP aram > { ′ , ′ < T ASMP aramList >}

< TASMParam > ::= < T ASMT ypeName >< T ASMW hiteSpace >< T ASMV ariable >

< TASMRules > ::= ′ RULES : ′ < T ASMRule > {< T ASMW hiteSpace >< T ASMRule >

3.2.7 Sub Machine

< TASMSTemplateDef > ::= ′ SUB MACHINE : ′ < T ASMNameDescP air >

< T ASMSV ars >< T ASMRules >

< TASMSVars > ::= < T ASMMonV ars >< T ASMContV ars >

46


3.2.8 Function Machine

< TASMFTemplateDef > ::= ′ F UNCT ION MACHINE : ′ < T ASMNameDescP air >

< T ASMF V ars >< T ASMRules >

< TASMFVars > ::= < T ASMInV ars >< T ASMOutV ars >< T ASMIntV ars >

< TASMInVars > ::= ′ INP UT V ARIABLES : ′ {< T ASMV arDecl >}

< TASMOutVars > ::= ′ OUT P UT V ARIABLE : ′ < T ASMV arDecl >

3.2.9 Configurations

< TASMConfigurations > ::= ′ CONF IGURAT IONS : ′ {< T ASMConfiguration >}

< TASMConfiguration > ::= ′ CONF IGURAT ION : ′ < T ASMNameDescP air >

< T ASMConfMInit >< T ASMConfV arInit >

< TASMConfMInit > ::= ′ MACHINE INIT IALIZAT IONS : ′ {< T ASMMachineInstance >

< TASMMachineInstance > ::= < T ASMName > ′ := ′′ new ′ < T ASMMachineName >

′ ( ′ [< T ASMConstant > { ′ , ′ < T ASMConstant >}] ′ ) ′′ ; ′

< TASMConfVarInit > ::= ′ V ARIABLE INIT IALIZAT IONS : ′

{< T ASMV arInit >}

3.3 XML Syntax

The XML-based syntax is a convenient format for a variety of reasons. First, XML

provides a format that is easy to parse and manipulate using standard interfaces such

as the Document Object Model (DOM). Second, XML is text-based and can be read

and displayed (in collapsable form) using standard web browsers. The ”readability”

removes the need for special purpose readers for debugging. Third, XML can be used

in conjunction with XSL transformations to convert the XML representation to another

47


epresentation. For example, the XML can be easily converted to HTML documentation

with an appropriate XSL stylesheet. Furthermore, the UPPAAL model checker

uses an XML format as its storage format; it might be possible to convert a TASM

system into a UPPAAL model using XSL transformation. Having an XML format can

enable interoperability with outside tools through XSL transformation. The plain-text

syntax presented in section 3.2 could be used as an interoperability format because its

format is published; however, XML is now recognized as the standard for information

exchange between anonymous entities. This section describes the format of the XML

that is used for exporting a specification written in the TASM language. The resulting

file is a complete TASM specification.

The parent-child-attribute relationships of the XML syntax are described graphically

using XML syntax trees. The nodes of the tree can be of three types – element

nodes, attribute nodes, and text nodes. The graphical representation of each type of

node is depicted in Figure 3.1. One-to-many relation from parent to child nodes are

illustrated using the * character along the tree edge to denote ”zero or more”, and the +

character along the tree edge is used to denote ”one or more”. The complete XML syntax

is described successively, starting with the top-level tree nodes and expanding each

top-level node subsequently. The meaning of each node and associated tag is listed

in a table corresponding to each syntax tree. The mapping between the XML syntax,

the plain-text syntax and the logical objects and concepts (from chapter 2 should be

straightforward unless otherwise noted.

Element

Attribute

Text

Figure 3.1: Tree Nodes for XML Syntax Tree

The top-level of the XML syntax contains four main sections corresponding to the

four main logical objects listed in section 2.7. The syntax tree corresponding to the

top-level node is depicted in figure 3.2. The list of XML tags and attributes is listed in

Table reftablexmltags. The tasm node is the top-level node of the document and contains

the version of the TASM syntax that is used. The syntax will most likely evolve as

the language matures so the version number will be used to ensure backward compatibility.

The sys node represents the ”TASM system”, that is, the list of configurations

that can be used for simulation. The env node represents the ”TASM environment”,

that is, the list of global variables and the list of user-defined types. The tmpls node

represents the list of ”TASM templates”, that is, the list of machine definitions (main

48


Table 3.3: XML Tags for Top Level Syntax Tree

Tag Type Meaning

tasm Element Top level node

version Attribute Version of the TASM syntax

sys Element The list of configurations that can be used for simulation

env Element The definition of the environment

tmpls Element The list of all machine templates

proj Element The definition of the project

machines, sub machines, and function machines) that can be instantiated in the ”TASM

system”.

tasm

version

env

sys

tmpls

proj

Figure 3.2: XML Top Level Syntax Tree

An example XML top-level skeleton is shown in XML example 1.

XML Example 1 Top level XML skeleton







Each child of the tasm node is explained separately. The Project node (proj) is

used to attach a name and a description to the tasm project. The node does not have

any children and contains two attributes. The syntax tree is shown in figure 3.3 and the

tag descriptions are explained in table 3.4.

The Environment node (env) is used to describe the set of user-defined types, the

set of resources, and the set of typed global variables. The node has three children,

one for the definition of types (the types node), one for the definition of resources

(the rsrcs node), and one for the definition of variables (the vars node). The syntax

tree is shown in figure 3.4 and the tag descriptions are explained in table 3.5. Each of

49


proj

name

desc

Figure 3.3: XML Syntax Tree for Project (proj) Node

Table 3.4: XML Tags for Project (proj) Node

Tag Type Meaning

name Attribute The name of the Project

desc Attribute The description of the Project

these nodes, in turn, has a one-to-many relationship to subnodes that have definitions

for individual types, resources, and variables.

An example of the XML for an environment with two user-defined types, two variables,

and one resource is given in XML example 2.

The System node (sys) is used to describe the set of main machines that are executing,

their instantiation, and the initial values of variables in the environment. The

core idea between the ”system” is a ”configuration”, which denotes a specific instance

of the machine templates and initial values in the environment. The idea is that those

”configurations” could be saved, named, and selected when doing simulation. In future

versions of the language, configurations could be extended to include concurrency semantics

and other ”selectable” behavior during simulation. The sys node has only one

children node that holds the list of configurations (the confs node). The confs node

has a one-to-many relationship with conf nodes that each contain a configuration definition.

Each configuration includes a name (the cname attribute), a description (the

cdesc attribute), and initial values for environment variables (the vinits node), and

machine instantiations (the minits node). The syntax tree is shown in figure 3.5 and

the tag descriptions are explained in table 3.6.

An example of the XML for an system with a single configuration is shown in the

XML example 3.

The Templates node (tmpls) is used to describe the set of machine templates that

are available to be instantiated in the system. The tmpls node has as many children

nodes as there are templates. There are three different types of templates - Main machine

templates, Sub machine templates, and Function machine templates. Each type

of template has roughly the same syntax, which are shown separately. The syntax tree

for the top level skeleton of templates is shown in figure 3.6 and the tag descriptions

are explained in table 3.7.

The different syntax for individual template types is explained in subsequent sections.

An example of the XML for a list of templates with 2 Main machines, 1 Function

machine, and 1 Sub machine is shown in XML example 4.

50


env

types

rsrcs

vars

vname

tname

*

type

*

rsrc

*

dvar

vtype

+

mem

rname

vdval

mname

rmin

rmax

Figure 3.4: XML Tags for Environment (env) Node

Table 3.5: XML Syntax Tree for Environment (env) Node

Tag Type Meaning

types Element The list of all types

type Element The parent node of a single type

tname Attribute The name of the type (TASMName)

mem Element A member of the type

mname Text The name of the member (TASMName)

vars Element The list of all variables

dvar Element The parent node of a single variable

vname Attribute The name of the variable (TASMName)

vtype Attribute The type of the variable (TASMName)

vdval Text The default value of the variable

rsrcs Element The list of all resources

rsrc Element The parent node of a single resource

rname Attribute The name of the resource (TASMName)

rmin Attribute The minimum amount of the resource

rmax Attribute The maximum amount of the resource

51


XML Example 2 XML for an environment with two user-defined types




On

Off



Idle

Taxi

Takeoff

Cruise

Landing




On

Idle






XML Example 3 XML for a system with a single configuration



















52


sys

confs

*

conf

name

desc

viname

vinits

minits

* +

vival

vinit

minit

tpname

params

vname

*

param

pindex

pval

Figure 3.5: XML Tags for System (sys) Node

tmpls

masms

sasms

fasms

* * *

masm sasm fasm

Figure 3.6: XML Tags for System (tmpls) Node

53


Table 3.6: XML Syntax Tree for System (sys) Node

Tag Type Meaning

confs Element The list of all configurations

conf Element The parent node of a single configuration

name Attribute The name of the configuration (TASMName)

desc Attribute The description of the configuration (TASMName)

vinits Element The list of all variable initializations

vinit Element The parent node of a given variable initialization

viname Attribute The name of the variable to initialize (TASMName)

vival Attribute The value that the variable must take upon initialization

minits Element The list of all machine instantiations

minit Element The parent node of a single machine instantiation

tpname Attribute The name of the template machine to instantiate

vname Attribute The name of the variable that holds the template instantiation

params Element The list of parameters of the instantiation

param Element A parameter of the instantiation

pindex Attribute The index of the parameter to pass to instantiation

pval Attribute The value of the paramater to pass to instantiation

Table 3.7: XML Syntax Tree for Templates (tmpls) Node

Tag Type Meaning

tmpls Element The list of all templates

masms Element The list of all Main ASM templates

masm Element The parent node of a single Main ASM template

sasms Element The list of all Function ASM templates

sasm Element The parent node of a single Sub ASM template

fasms Element The list of all Function ASM templates

fasm Element The parent node of a single Function ASM template

54


XML Example 4 XML for a list of templates with 2 Main machines, 1 Sub machine,

and 1 Function machine













The Main machine template node (masm) is used to describe the a Main machine.

The masm node has five children nodes to denote the various parts of the machine: the

controlled variables (the cvars node), the monitored variables (the mvars node), the

internal variables (the ivars node), the constructor (the cons node) and the set of

rules (the rls node). The syntax tree for the Main machine template is shown in figure

3.7 and the tag descriptions are explained in table 3.8.

The constructor node cons is explained separately because it contains a long list

of subnodes. It consists of a list of ordered parameters (the cparam node combined

with the cpindex attribute) and what internal variable corresponds (the cpivname

attribute) to each parameter. The syntax tree for the Main machine template is shown

in figure 3.8 and the tag descriptions are explained in table 3.9.

The rules node rs is also explained separately because it is reused for other templates

as well. It consists of a list of rules (the rl node), their names (the rlname

attribute), and their definitions. The definition consists of a rule guard (the guard

node), a rule effect (the effect node), the execution time of the rule (the rtime

node combined with the rtmin attribute and the rtmax attribute), and the resources

consumed during the rule execution (the rrsrcs node and associated definition). The

syntax tree for the rules node is shown in figure 3.9 and the tag descriptions are explained

in table 3.10.

An sample XML for a main machine template that has two monitored variables,

two controlled variables and two rules is shown in XML example 5.

The syntax for a sub ASM template is exactly the same as that for a main ASM

template except for two differences. The first difference is that the top node is sasm in

the sub ASM case as opposed to masm in the main ASM case. The second difference is

that a sub ASM template does not contain a constructor. For a function ASM template,

the syntax is slightly different. The differences come in the presence of input variables,

in addition to monitored variables, and in the presence of a single output variable. The

function ASM template syntax omits the controlled variables tag cvars, but adds the

input variables tag invars and the output variable node ovar.

55


masm

name

desc

cvars

mvars

ivars

cons

rls

*

*

*

rvar

rvar

dvar

vname

vname

vname

vdval

vtype

Figure 3.7: XML Tags for System (masm) Node

Table 3.8: XML Syntax Tree for Main Machine Template (masm) Node

Tag Type Meaning

masm Element Top level node of main machine template

mvars Element The list of all monitored variables

rvar Element A single monitored variable

vname Attribute The name of the monitored variable (TASMName)

cvars Element The list of all controlled variables

rvar Element A single controlled variable

vname Attribute The name of the controlled variable (TASMName)

ivars Element The list of all internal variables

dvar Element A single internal variable

vname Attribute The name of the interval variable (TASMName)

vtype Attribute The type of the interval variable (TASMName)

vdval Text The default value of the internal variable

tvdval Text An expression that resolves to a value to be assigned

to the internal variable as its default value (TASMExpression)

56


cons

cbody

cparams

body

*

cparam

cpivname

cptype

cpindex

Figure 3.8: XML Tags for Template Constructor (cons) Node

Table 3.9: XML Syntax Tree for Template Constructor (cons) Node

Tag Type Meaning

cons Element Top level node of the constructor

cparams Element The list of parameters of the constructor

cparam Element A single parameter of the constructor

cpivname Attribute The name of the internal variable to which the parameter refers (TASMName)

cpindex Attribute The index of the parameter in the constructor

cptype Attribute The type of the parameter in the constructor

cbody Element The body node of the constructor

body Text The body of the constructor

57


ls

rl

*

rlname

guard

effect

rtime

rrscs

tguard

teffect

rtmin

rrname

rtmax

rrmin

*

rrsc

rrmax

Figure 3.9: XML Tags for Template Rules (rs) Node

Table 3.10: XML Syntax Tree for Template Rules (rls) Node

Tag Type Meaning

rls Element Top level node of the rules

rl Element A single rule

rlname Attribute The name of the rule

guard Element The parent note of the rule guard

tguard Text The text that defines the rule guard (TASMRuleGuard)

effect Element The parent note of the rule effect

teffect Text The text that defines the rule effect (TASMRuleEffect)

rtime Element The time that it takes for the rule to be applied

rtmin Attribute The minimum duration of the rule application

rtmax Attribute The maximum duration of the rule application

rrsrcs Element The list of resources consumed during the rule application

rrsc Element A single resource consumed during the rule application

rrname Attribute The name of the resource consumed during the rule application (TASMName)

rrmin Attribute The minimum amount of resource consumed during the rule application

rrmax Attribute The maximum amount of resource consumed during the rule application

58


XML Example 5 XML for main ASM template with 2 monitored variables, 2 controlled

variables, and 2 rules














mv1 = On and mv2 = Cruise

cv1 := Off, cv2 := Taxi



mv1 = Off and mv2 = Landing

cv1 := On, cv2 := Cruise




59


The syntax tree for the function machine template node is shown in figure 3.10 and

the tag descriptions are explained in table 3.11.

fasm

name

desc

invars

ovar

mvars

ivars

rls

*

*

*

pvar

pvar

rvar

dvar

vname

vname

vname

vname

vdval

vtype

vtype

vtype

Figure 3.10: XML Tags for Function ASM Template (fasm) Node

An sample XML for a function machine template that has two internal variables,

two input variables and two rules is shown in XML example 6.

3.4 Well-Formedness Rules

Alongside the formal grammar definition and the XML definition, the syntax of TASM

specifications needs to obey some ”well-formedness” rules. These rule describe required

properties of TASM specifications that cannot be expressed using formal grammars.

These properties include type checking, restrictions on names (e.g., special characters,

uniqueness), references to variable and type members, etc.

3.4.1 Names

All names must be unique within a TASM specification. This includes the names of

variables, types, machine templates, and resources. Moreover, each name must comply

with the length and character restrictions explained in section 3.1. Furthermore, names

introduced by the user must not clash with the list of keywords listed in table 3.1. The

use of names in the TASM language is crucial to type checking, variable references,

and assignments.

60


Table 3.11: XML Syntax Tree for Function Machine Template (fasm) Node

Tag Type Meaning

fasm Element Top level node of function machine template

mvars Element The list of all monitored variables

rvar Element A single monitored variable

mvname Attribute The name of the monitored variable (TASMName)

invars Element The list of all input variables

pvar Element A single input variable

vname Attribute The name of the input variable (TASMName)

vtype Attribute The type of the input variable (TASMName)

ovar Element The parent node of the output variable

pvar Element The output variable definition

vname Attribute The name of the output variable (TASMName)

vtype Attribute The type of the output variable (TASMName)

ivars Element The list of all internal variables

dvar Element A single internal variable

vname Attribute The name of the interval variable (TASMName)

vtype Attribute The type of the interval variable (TASMName)

dval Text An expression that resolves to a value to be assigned

to the internal variable as its default value (TASMExpression)

61


XML Example 6 XML for a function ASM template with 2 internal variables, 2 input

variables, and 2 rules









On

Taxi





in1 = On and in2 = Cruise

out1 := Taxi



in1 = Off and in2 = Landing

out1 := Cruise




62


3.4.2 Typing

All variables are statically typed in the TASM language. In rule guards, all the guards

must evaluate to a Boolean value (True or False). Function machines used in guards

must have an output variable of type Boolean. All application of operators must be

correctly typed. The list of operators is given in table 3.2. All assignments must also

be correctly typed. This includes assignments from function machines, constants, and

variables.

63


Chapter 4

Semantics

Expressing the formal semantics of executable has been a topic of much research in the

computer languages community. Three dominant approaches stand out when expressing

programming language semantics - operational semantics, denotational semantics,

and axiomatic semantics. Denotational semantics has been used successfully for sequential

programs, but the paradigm becomes difficult to work with when concurrency

is introduced. Axiomatic semantics has been used on smaller programs, but it is not

clear that it works well for larger programs or for languages with numerous concepts.

Operational semantics could be used to express the TASM semantics because it has

concepts analogous to the TASM language, namely, that of an abstract machine progressing

through configurations. Operational semantics has been used extensively to

specify language semantics, for both sequential and concurrent programs. However,

because the ASM paradigm is close to the operational semantics paradigm, we attempt

to express the semantics of the TASM language using abstract state machines. The motivation

is twofold. First, ASMs have been used to specify the semantics of executable

languages, including VHDL, Prolog, and SDL. Second, because the TASM language

is built on top of the ASM language, it makes sense to use ASM to express the semantics.

In a sense, if the semantics are expressed properly, the TASM language could be

viewed as ”syntactic sugar” on top of the ASM language.

4.1 Preliminary Concepts

Before embarking on the definition of the semantics, some basic concepts such as operator

precedence, typing, and calling conventions need to be specified.

4.1.1 Operator Precedence

The use of parentheses is strongly encouraged to disambiguate operator precedence for

language users. However, the TASM language defines rules for operator precedence

when parentheses are not used. The precedence rules are listed in Table 4.1.

64


Table 4.1: Operator Precedence

Operator Meaning

∗ Multiplication

/ Division

+ Addition

− Subtraction

>= Greater than or equal to

> Greater than


a ”desugaring” into the syntax of the Lipari guide. For the syntax, we follow the

notational conventions used in both the Lipari guide and the definition of the formal

semantics of SDL [8]. For a detailed list of the ASM syntax used to express the formal

semantics, the reader is referred to the SDL guide [8], pages 25–27.

The key extensions to the TASM language have to do with the addition of time

passage and resource consumption. To illustrate time passage, we adopt the same convention

as in [7, 8] and introduce a global dynamic and monotonic increasing function

called currentTime:

• monitored currentTime: → REAL

This function is used inside of machines to query the value of the current time. The

function is modified by the environment only and returns a monotonically increasing

value greater than 0.0.

4.2.1 Sugaring/Desugaring

The extensions to the TASM language have been introduced as ”syntactic sugar” on top

of the syntax and semantics of the Abstract State Machine language as expressed in the

Lipari guide [10]. In order to map a TASM specification into an ASM specification, we

introduce two domains, namely DT ASM and DASM to denote the domains of specifications

expressed in the TASM language and the ASM language respectively. We

also introduce a function Desug that maps a TASM specification into an ASM specification.

The ”desugaring” function is defined for all individual elements of the TASM

language (specifications, variables, types, rules, etc.) and maps the TASM elements

into elements of the ASM language.

• Desug : DT ASM → DASM

4.2.2 Resource definitions

A resource definition, Rdef, in the environment is desugared into global shared dynamic

functions:

• Desug[[Rdef]] = shared Rdef

The desugaring of the resource definition is a bit more complex with respect to

usage, but the execution semantics of resource usage are detailed in section4.2.6.

4.2.3 Type definitions

Type definitions, T def get desugared into static finite domains:

• Desug[[T def]] = static domain T def

4.2.4 Variables

Controlled and monitored variables inside of machines get desugared into nullary controlled

and dynamic functions, respectively.

66


4.2.5 Rules

The desugaring of the rules is the most complex desugaring in the TASM language, because

this is where time and resource utilization play a role. To illustrate the desugaring

of rules, we define abstract syntax for a rule definition:

• Rules = (R + i )

• R i = (t i r ∗ i if cond i then effect i )

In the TASM, the set of rules for a given machine is implicitly mutually exclusive.

In the ASM language, the mutual exclusion is explicit. The first desugaring of as set of

rules is to generate the explicit mutual exclusion:

• Desug[[Rules]] = Desug[[((t 0 r ∗ 0 if cond 0 then effect 0 ) ... (t n r ∗ n if cond n

then effect n ))]] =

if cond 0 then effect 0

else if cond 1 then effect 1

...

else if cond n then cond n

The else rule guard from the TASM language would get desugared into a simple

else rule guard of the ASM language. The time annotations get desugared into an environment

variable that affects each machine’s execution to simulate ”durative” actions.

Conceptually, once a rule is triggered, a machine sets a specific variable to the duration

of the rule application and will not do anything until the rule duration has elapsed.

Once the rule duration has elapsed, the machine will generate the appropriate update set

atomically and will be free to execute another rule. Desugaring a time annotation for

a rule introduces a new branch if the ”if” conditions to denote the time. We introduce

the concept of a ”fresh” variable to denote a newly generated variable whose name is

using. The desugaring introduces two variables, one to keep the time when the rule

application will finish executing and one to denote that the machine is ”busy” doing

work. We denote these two variables by tcomplete fresh and mbusy fresh . The fresh

underscore is used to indicate that the variable name is introduced by the desugaring

and enforces that it does not clash with existing names. Both of these variables also

desugar into controlled dynamic functions:

• Desug[[tcomplete fresh ]] = controlled tcomplete initially -1

• Desug[[mbusy fresh ]] = controlled mbusy initially False

• Desug[[Rule]] = Desug[[((t i r ∗ i if cond i then effect i )]] =

if/else if cond i ∧ mbusy fresh = F alse then

mbusy fresh := True, tcomplete fresh := currentT ime + getDuration(t i )

else if currentT ime = tcomplete fresh ∧ mbusy fresh = T rue then

effect i , mbusy fresh := F alse, timcomplete fresh := -1

...

67


The function getDuration is a macro that is created using the condition and the

time annotation of the rule. It returns the duration of the rule. If the time annotation

is a single value, it returns that value. Otherwise, if the rule annotation is an interval,

it returns a value randomly selected in the interval. Using a macro will enable the

desugaring to take into account possible concurrency semantics like ”worst-case time”

and ”best-case time” as defined in section 4.2.6. The introduction of the two auxiliary

variables and the time conditions will guarantee that the machine will not produce any

update sets and that no other rules will be enabled while the machine is executing a

rule. This behavior is exactly the desired behavior to simulate ”durative” actions.

Resource annotations get desugared as well, but their usage is a bit different than for

the time annotation. Resources are modeled as shared dynamic functions. Their values

are set during at the beginning of a rule execution and at the end of a rule execution.

We also introduce fresh variables, for each machine to denote resource usage:

• Desug[[Rule]] = Desug[[((t i r ∗ i if cond i then effect i )]] =

if/else if cond i ∧ mbusy fresh = F alse then

mbusy fresh := True,

tcomplete fresh := currentT ime + getDuration(t i ),

r ifresh := getResourceConsumption(r i )

else if currentT ime = tcomplete fresh ∧ mbusy fresh = T rue then

effect i ,

mbusy fresh := F alse,

tcomplete fresh := -1,

r ifresh := 0

...

Function machines are desugared as macros and sub machines are desugared just

like main machines and they are ”inlined” inside the rule where they are invoked.

4.2.6 Execution Semantics

The desugaring of the TASM language into the ASM language is an easy way to express

the formal semantics of the TASM language. In the ASM world, every main

machine represents an ”Agent”, member of the shared domain AGENT. The TASM

language also introduces concurrency semantics that are slightly different than for the

ASM language. In the TASM language, time is used to synchronize the order of execution

between different agents. It is the currentT ime dynamic function that keeps all

of the agents executing in a synchronized order. The time annotations create a partial

order between the moves of agents. The currentT ime function increases monotonically,

at a rate that is congruent with the smallest step of a given main machine. For

example, if the shortest duration of a rule is 3 time units, for all agents in AGENT ,

then the currentT ime function will increment each time by 3 time units, we denote

this smallest value dt, which corresponds to a static function.

The one area that remains to be formally specified is the execution semantics of

resources. For each resource that is defined in the environment, we create an agent that

68


is used to sum up all of the resources used by existing agents. These new agents are

used to ensure that resource usage falls within the specified bounds.

Agent RESOURCE i

controlled last fresh initially 0

controlled totalresource ifresh initially 0

if currentT ime = last fresh + dt then

totalresource ifresh := sum(r i )

else

if totalresource ifresh > resource imax then

RESOURCE EXHAUST ED

The role of the sum macro is to sum up all of the resource annotations from executing

agents. The RESOURCE EXHAUST ED macro simply halts execution to

note that a given resource has been exhausted.

69


Bibliography

[1] M. Anlauff. XASM - An Extensible, Component-Based Abstract State Machines

Language. In Y. Gurevich, P. Kutter, M. Odersky, and L. Thiele, editors, Abstract

State Machines - ASM 2000, International Workshop on Abstract State Machines,

pages 1–21. TIK-Report 87, 2000.

[2] E. Börger. Why Use Evolving Algebras for Hardware and Software Engineering

In M. Bartošek, J. Staudek, and J. Wiedermann, editors, Proceedings of the 22nd

Seminar on Current Trends in Theory and Practice of Informatics, SOFSEM ’95,

volume 1012 of Lecture Notes in Computer Science, pages 236–271, Milovy,

Czech Republic, 1995. Springer-Verlag.

[3] E. Börger. The Origins and the Development of the ASM Method for High Level

System Design and Analysis. Journal of Computer Science, 8(5):2–74, 2001.

[4] E. Börger, P. Päppinghaus, and J. Schmid. Report on a Practical Application of

ASMs in Software Design. In Abstract State Machines: Theory and Applications,

volume 1912, pages 361–366. Springer-Verlag, 2000.

[5] E. Börger and R. Stärk. Abstract State Machines. Springer-Verlag, 2003.

[6] E. M. Clarke and J. Wing. Formal Methods: State of the Art and Future Directions.

ACM Computing Surveys, 28(3):626–643, 1996.

[7] J. Cohen and A. Slissenko. On Verification of Refinements of Asynchronous

Timed Distributed Algorithms. In Y. Gurevich, P. Kutter, M. Odersky, and

L. Thiele, editors, International Workshop on Abstract State Machines, pages

100–114. Springer-Verlag, 2000.

[8] R. Eschbach, U. Glässer, R. Gotzhein, and A. Prinz. On the Formal Semantics of

Design Languages: A Compilation Approach using Abstract State Machines. In

Y. Gurevich, P. Kutter, M. Odersky, , and L. Thiele, editors, Proceedings of the

International Workshop on Abstract State Machines – ASM 2000, volume 1912 of

Lecture Notes in Computer Science, pages 242–265, Monte Verita, Switzerland,

2000. Springer-Verlag.

[9] N. E. Fuchs. Specifications are (Preferably) Executable. IEE/BCS Software Engineering

Journal, 7(5):323–334, 1992.

70


[10] Y. Gurevich. Evolving Algebras 1993: Lipari Guide. Specification and Validation

Methods, pages 9–36, 1995.

[11] http://www.coreasm.org. The coreASM Engine.

[12] http://www.research.microsoft.com/foundations/asml. ASML: The Abstract

State Machine Language.

[13] http://www.tydo.de/AsmGofer. ASM Gopher.

[14] http://www.uni-paderborn.de/cs/asm/ASMToolPage/asm workbench.html. The

ASM Workbench.

[15] R. Milner. Communication and Concurrency. Prentice Hall, 1980.

[16] H. Rust. Using Abstract State Machines: Using the Hypperreals for Describing

Continuous Changes in a Discrete Notation. In Abstract State Machines – ASM

2000, pages 341–346. Springer-Verlag, March 2000.

[17] K. Winter. Model Checking for Abstract State Machines. Journal of Universal

Computer Science, 3(5):689–701, 1997.

71

More magazines by this user
Similar magazines