20
DOI 10.1007/s00165-003-0017-2 BCS © 2003 Formal Aspects of Computing (2003) 15: 370–389 Formal Aspects of Computing Redesign of a Systems Engineering Language: Formalisation of χ Victor Bos 1 and Jeroen Kleijn 2 1 Software Construction Laboratory, Turku Centre for Computer Science (TUCS), Turku, Finland 2 Heineken Technical Services, Research & Development, Zoeterwoude, The Netherlands Abstract. This paper describes the redesign of a systems engineering language called χ. This is an engineering language designed to specify and analyse industrial systems. The main objective of this redesign was to enable mathematical reasoning about χ specifications. We discuss the original χ language, the requirements and design decisions, and the resulting syntax and semantics of the new version of χ, called χ σ . In particular, we elaborate on semantical aspects of χ σ ’s time model. Keywords: Formal semantics; Industrial systems; Operational semantics; System analysis; Systems engineering; Verification 1. Introduction This paper discusses the redesign of a systems engineering language called χ. The paper contains the essential results of [BoK02a] and is a revised and extended version of [BoK02c]. This work has been carried out at the Eindhoven University of Technology, The Netherlands, within the Systems Engineering Group of the Mechanical Engineering Department, and the Formal Methods Group of the Mathematics and Computing Science Depart- ment. The χ language is developed to specify and analyse industrial systems, like factories and machines, and it is inspired by CSP [Hoa85]. The main analysis technique of χ is simulation. The goal of the redesign is to improve analysis techniques by formal, or mathematical, reasoning. This will enable systems engineers to analyse their designs more rigorously and, therefore, can lead to more reliable designs of industrial systems. Starting with its earliest versions [MoR95, Are96], χ was developed with real-life applications in mind. Tool development and industrial case studies were given more attention than a thorough investigation into the theoret- ical issues of χ. For instance, to model continuous processes of production systems, χ has had hybrid extensions from the beginning, even though the mathematical meaning of many language constructs, like delay statements and differential equations, was unclear. In fact, formal semantics of hybrid languages is still an active research area. Despite the lack of a thorough mathematical core, χ is a powerful modelling language for which efficient simulators exist [AlN98, Fab99, BeR00]. In order to get some idea of its application domain, we mention some examples. For a complete overview see http://se.wtb.tue.nl/. Correspondence and offprint requests to: Victor Bos, Turku Centre for Computer Science, DataCity, Lemmink¨ aisenkatu 14 A, FIN-20520 Turku, Finland. Email: vbos@abo.fi

Redesign of a Systems Engineering Language: Formalisation of ?

Embed Size (px)

Citation preview

Page 1: Redesign of a Systems Engineering Language: Formalisation of ?

DOI 10.1007/s00165-003-0017-2BCS © 2003Formal Aspects of Computing (2003) 15: 370–389

Formal Aspectsof Computing

Redesign of a Systems Engineering Language:Formalisation of χVictor Bos1 and Jeroen Kleijn2

1Software Construction Laboratory, Turku Centre for Computer Science (TUCS), Turku, Finland2Heineken Technical Services, Research & Development, Zoeterwoude, The Netherlands

Abstract. This paper describes the redesign of a systems engineering language called χ. This is an engineeringlanguage designed to specify and analyse industrial systems. The main objective of this redesign was to enablemathematical reasoning about χ specifications. We discuss the original χ language, the requirements and designdecisions, and the resulting syntax and semantics of the new version of χ, called χσ. In particular, we elaborateon semantical aspects of χσ’s time model.

Keywords: Formal semantics; Industrial systems; Operational semantics; System analysis; Systems engineering;Verification

1. Introduction

This paper discusses the redesign of a systems engineering language called χ. The paper contains the essentialresults of [BoK02a] and is a revised and extended version of [BoK02c]. This work has been carried out at theEindhoven University of Technology, The Netherlands, within the Systems Engineering Group of the MechanicalEngineering Department, and the Formal Methods Group of the Mathematics and Computing Science Depart-ment. The χ language is developed to specify and analyse industrial systems, like factories and machines, and it isinspired by CSP [Hoa85]. The main analysis technique of χ is simulation. The goal of the redesign is to improveanalysis techniques by formal, or mathematical, reasoning. This will enable systems engineers to analyse theirdesigns more rigorously and, therefore, can lead to more reliable designs of industrial systems.

Starting with its earliest versions [MoR95, Are96], χ was developed with real-life applications in mind. Tooldevelopment and industrial case studies were given more attention than a thorough investigation into the theoret-ical issues of χ. For instance, to model continuous processes of production systems, χ has had hybrid extensionsfrom the beginning, even though the mathematical meaning of many language constructs, like delay statementsand differential equations, was unclear. In fact, formal semantics of hybrid languages is still an active researcharea. Despite the lack of a thorough mathematical core, χ is a powerful modelling language for which efficientsimulators exist [AlN98, Fab99, BeR00]. In order to get some idea of its application domain, we mention someexamples. For a complete overview see http://se.wtb.tue.nl/.

Correspondence and offprint requests to: Victor Bos, Turku Centre for Computer Science, DataCity, Lemminkaisenkatu 14 A, FIN-20520Turku, Finland. Email: [email protected]

Page 2: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 371

• discrete (re-entrant) flow lines: design of a multi-process multi-product wafer fab [Cam00, HWR98, RCH98](Philips), balancing of a car assembly line [Gov97] (Volvo/Mitsubishi);

• hybrid (jumbled) flow [BHR02]: design of a fruit juice blending and packaging plant [Fey00] (Riedel);• control architectures: agent-based control of systems [MoR97, MSR99], flexible manufacturing systems

[MRN95];• machinery: scheduling algorithms for medical equipment [MGR00] (TNO).

As the number of successful case studies increased, its developers as well as some industrial partners gained moreconfidence in the χ modelling language. It also became apparent that χ lacked analysis features crucial for someapplications. For instance, mere simulation cannot provide guarantees as it comes to behavioural propertieslike deadlock or live lock. The reason is that simulation-based analysis investigates some possible behaviours,whereas these properties depend on all possible behaviours. Therefore, a more rigorous approach to analysis of χspecifications was required.

Reasoning about behavioural issues of specified systems is often done using formal methods. For example,formal methods are often used for the analysis of mission-critical systems, see [Rus95, GLW98]. They enableverification of properties by mathematical proof, that is, they enable mathematical reasoning. Furthermore, byusing standard mathematical techniques, like abstraction and induction, general properties can be proved withouthaving to analyse all possible behaviours in isolation.

This paper describes the redesign of χ in which the discrete part of the language is formalised. This resultedin a formal language called χσ and a translational semantics of (discrete) χ into χσ. As this paper shows, therewere many issues involved in formalising the discrete part of χ. Therefore, we ignored the continuous languageconstructs. However, formalising the continuous part of χ is active research [SBM03].

Formalisation of real-life specification, design, or programming languages has been actively researched prob-ably as long as these kinds of languages have existed. We cannot give a thorough overview of all formalisedlanguages that exist today. However, we would like to mention two specific formal languages, because, like χ theyare strongly influenced by CSP. The first one is Occam [BoD93, JoG88, PoM88, RoH86]. Occam was designedto simplify the programming of parallel computers. This immediately explains some of the differences betweenOccam and χ. For instance, Occam has data structures directly related to computer hardware, like bits and bytes,that do not exist in χ. Another difference is that at the time Occam was developed, many results from SOS theoryto simplify the definition of an operational semantics did not exist. Consequently, the formal semantics of Occamis more laborious than the formal semantics of χ we present here. The other language we want to mention isthe international standard E-LOTOS [JGL97, JGL95]. E-LOTOS, an enhancement of LOTOS [Bri88], has beenused to design and analyse telecommunication protocols and distributed systems. The (dynamic) semantics ofE-LOTOS is described in a similar style as the semantics of χ we present in this paper. However, the semanticsof E-LOTOS’s behavioural constructs is interwoven with the semantics of E-LOTOS’s static constructs. In theapproach we take, a clear separation of behavioural and static constructs exists. Both approaches have advantagesas well as disadvantages. To name one of each, a more strict separation of the static and the dynamic part, aswe have, makes the semantics simpler. However, the approach taken by the designers of E-LOTOS allows for auniform treatment of functions (with result values) and processes.

This paper is organised as follows. The original engineering language χ is discussed in Section 2. In Section 3,we discuss requirements and design decisions. Formalising χ led to a new version called χσ, which is discussedin Section 4. In Section 5, we discuss some examples that show how our design decisions worked out. Next, inSection 6, we compare χ to χσ. Finally, we draw conclusions in Section 7.

2. The Engineering Language χ

In this section we briefly describe the engineering language χ. The developers of χ were strongly influenced byCSP. Consequently, the main building blocks of χ are sequential processes. Each process is specified using a lan-guage similar to Dijkstra’s guarded command language [Dij76]. The syntax of this language is given in Table 1.Processes can be put in parallel in systems and these systems can be put in parallel with other systems or processes.Processes and systems communicate with each other via channels. Channels are one-place buffers; the old valueof a channel is lost as soon as a new value is written into it. Furthermore, each channel is uni-directional andconnects exactly two processes.

Using the names of the syntactical classes defined in Table 1, the process statements PS have the followinginformal meaning:

Page 3: Redesign of a Systems Engineering Language: Formalisation of ?

372 V. Bos and J. J. T. Kleijn

Table 1. Syntax of χ statements

x : variable, a : channel, e(r) : (real number) expression, b : Boolean expression

PS ::� skip do-nothing statement| x :� e assignment statement (x �≡ τ )| PS1 ; PS2 concatenation statement| ES event statement| [GP ] selection statement| ∗[GP ] repetitive selection statement| [GC ] selective waiting statement| ∗[GC ] repetitive selective waiting statement

ES ::� �er delay statement| a ! e send statement| a ? x receive statement

GP ::� b −→ PS guarded command alternative| GP [] GP guarded command alternatives

GC ::� b ; ES −→ PS selective waiting alternative| GC [] GC selective waiting alternatives

• The term skip denotes the do-nothing or no-op statement.• The term x:�e denotes the assignment statement. It changes the value of variable x to the value of expression e.• The term PS1 ; PS2 denotes the sequential composition of the statements PS1 and PS2, meaning that

statement PS2 is executed after the execution of statement PS1 has finished.• The event statements ES are: a delay statement, a send, and a receive statement. The delay statement �er

enables a process to delay �er time units. The send statement a ! e can send the value of expression e viachannel a to the other process connected to this channel. The receive statement a ? x can receive a value viachannel a and assign it to variable x.

• The selection statement offers a choice between several guarded alternatives. The alternatives are separatedby the ‘[]’ symbol. Each alternative has syntax b −→ PS and is called a guarded command (b is a Booleanexpression denoting the guard). The selection statement chooses one of the guarded commands of which theguard b evaluates to true non-deterministically. If no guard evaluates to true, the selection statement abortsor deadlocks, meaning the process is in an error state from which no further progress (not even progress oftime) can be made.

• A repetitive selection statement executes a selection statement as many times as possible. The repetitionterminates if no guard evaluates to true. So, a repetitive selection statement never deadlocks.

• A selective waiting statement is somewhat like a selection statement, but here, an alternative has syntaxb ; ES −→ PS, where ES is an event statement. The construct waits until at least one event statementfollowing a guard b that evaluates to true can be executed. Then it chooses non-deterministically one of thesealternatives. As with the selection statement, the selective waiting statement deadlocks if none of the guardsis true.

• A repetitive selective waiting statement executes a selective waiting statement as many times as possible.As with the repetitive selection statement, the repetitive selective waiting statement terminates if no guardevaluates to true.

The following abbreviations are allowed:

• in a selective waiting: true ; ES can be abbreviated to ES, and• b ; ES −→ skip can be abbreviated to b ; ES.

Regarding the binding power of the operators, we make the following remarks. Firstly, the binding powerof ‘ ; ’ is greater than the binding power of ‘−→’. So, a statement b −→ S1 ; S2, where S1 and S2 are of thesyntactic class PS of Table 1, should be read as b −→ (S1 ; S2). Secondly, the four choice statements (selection,repetitive selection, selective waiting, and repetitive selective waiting) delimit their arguments explicitly. Therefore,no additional binding power definitions are needed.

The specification of a process type has the following general form:

proc name(parameterList) � |[variableDeclarations | PS]|.where parameterList contains a comma separated list of formal parameters. Parameters are typed using thesyntax p : type. Ports are normal types preceded by a ‘!’ or a ‘?’ to indicate their output or input character,respectively. Variables are declared in variableDeclarations. Since this is the only place where variables can bedeclared, variables in χ are always local to a specific process.

Page 4: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 373

EMGgm me

Fig. 1. System GME.

proc G(out : !bool) �|[ ∗[out ! true [] out ! false ] ]|

proc M(in : ?bool, out : !bool, t1, t2 : int) �|[ x : bool| ∗[in ? x

; [x −→ �t1 [] ¬x −→ �t2 ]; out ! x]

]|

proc E(in : ?bool) �|[ x : bool| ∗[in ? x ]]|

syst GME(t1, t2 : int) �|[ gm, me : −bool| G(gm) ‖ M(gm, me, t1, t2) ‖ E(me)]|

Fig. 2. Process description of system GME in χ.

As mentioned before, χ has systems to define parallel components. These components communicate witheach other via channels. The specification of a χ system has the following general form:

syst name(parameterList) � |[ declarations| name1(parameterList) ‖ . . . ‖ namen(parameterList)]| ,

where parameterList contains a comma separated list of formal parameters. Systems can have channels. Channeltypes are normal types preceded by a ‘−’. Channels are declared in declarations. Since this is the only place wherechannels can be declared, channels in χ are always local to a specific system. Since the ‘‖’ operator of χ can occuronly at the system level, there is no need to define the binding power of this operator with respect to the other(process level) operators.

As mentioned before, each channel is uni-directional and connects exactly two processes and/or systems. Toenable communication between two processes (or systems), one of them should define an input port as a formalparameter (e.g., in : ?bool) and the other should have an output port as a formal parameter (e.g., out : !bool).These ports have to be of the same type (e.g., bool). Next, a system is defined in which a local channel of thesame type as the input and output ports is declared (e.g., me : −bool). In this system, the two processes are putin parallel with one end of the channel connected to the input port and the other end of the channel connectedto the output port. The example in Fig. 1 shows this in more detail. System GME consists of a generator G,a machine M , and an exit E. The generator and exit represent the environment of machine M . The generatorgenerates products to be processed by the machine and the exit consumes these processed products. Machine Mis capable of processing the two different kind of products (modelled by true and false). The machine receives itsproducts via channel gm. Depending on the type of product, processing takes t1 or t2 time units. When finished,a product is sent to the exit via channel me. Figure 2 lists the corresponding χ specification.

3. Requirements and Design Decisions

As mentioned at the end of Section 1, our main objective is to redesign χ such that rigorous mathematicalreasoning about χ models is possible. The approach we took is to design a language, called χσ, with a formalsemantics and to define a translation from χ into this formal language. For the design of χσ, as for every designactivity, it is important to clearly formulate the requirements. Based on the requirements and the available tech-niques and knowledge, design decisions can be made in order to come to an actual realisation. The requirementsfor χσ are listed below.

1. Maintain look and feel of χ. Since χσ is a redesign, it should resemble χ closely.2. Support mathematical reasoning. Since formal verification is based on mathematical reasoning, it is clear

that χσ should support this.

Page 5: Redesign of a Systems Engineering Language: Formalisation of ?

374 V. Bos and J. J. T. Kleijn

3. Small number of language primitives. By reducing the number of language primitives, mathematical reasoningwill become less complicated.

4. Separation of concerns. By separation of concerns we mean orthogonal and single-purpose language primi-tives.

We conclude by explaining the most important design decisions we took. Based on the fact that χ was inspiredby CSP, a process algebra, we decided to formalise it in a style often used for process algebras. That is, we defineda structured operational semantics (SOS, see [Plo81]), together with an equivalence relation on processes. Sub-sequently, we derived properties of processes with which we can perform calculations. Here we will call theseproperties laws, after [Ros98, HoJ98]. Meta-reasoning with the operational semantics and these laws is possiblein the sense that general, abstract properties of processes can be derived. The framework that resulted enables usto reason mathematically about χσ specifications and therefore Requirement 2, Support mathematical reasoning,is met.

We also decided to replace as many χ primitives as possible by common process algebra operators. Themain reason for this is that process algebra operators generally satisfy Requirement 4, Separation of concerns.Consequently, most of χσ’s operators are known from existing process algebras, although there might be somesyntactical differences. The syntactical differences have been chosen to satisfy Requirement 1, Look and feel of χ.In particular, they are known from ACP-style process algebras [BaW90]. ACP is closely related to CCS [Mil80]. Asmany process algebras don’t support programming variables and assignments, we defined several new operators,including an assignment and a state operator. The state operator keeps track of variable values. This is illustratedby an example in Section 5.

In χσ, the distinction between processes and systems has been removed; everything is a process. We tookthis decision based on Requirement 3, Small number of language primitives. A consequence is that variable andchannel declarations can now be mixed. Another consequence is that the parallel composition operator is at thesame level as and can be combined freely with the other process operators.

Another reduction of language primitives we made is the removal of input and output ports. In χσ, there arechannels only. Furthermore, these channels are bi-directional and can be attached to more than two processes.The notation of an actual channel with name ‘m’ is changed from −m in χ into ∼m in χσ.

As explained above, channels are one-place buffers. So, like variables, a channel is a storage location for values.Since the function of the state operator is to keep track of such values, we decided to use the state operator tokeep track of the values of variables as well as channels. This decision was taken in the light of Requirement 3,Small number of language primitives, and 4, Separation of concerns. We illustrate χσ’s communication mechanismby an example in Section 5. We are aware of the fact that there are other mechanisms to formalise communicationchannels. For example, the π-Calculus [MPW92, Par01] also has communication channels that are one-placebuffers. We think we could have used the solution of the π-calculus for the communication channels of χσ andit would be interesting to investigate how this would work out. However, our current solution, based on statestacks, has the advantage that it works both for channels and variables and therefore no additional languageprimitives need to be introduced.

To incorporate time in χσ, many aspects had to be taken into account. Since a clear understanding of all rele-vant timing aspects requires some knowledge of χ’s semantical model, a discussion is postponed until Section 4.3.How timing in χσ worked out is explained by some examples in Section 5.

4. The Specification Formalism χσ

In this section we introduce the specification formalismχσ. The complete definition ofχσ can be found in [BoK02a].We describe its main processes and operators, and the resulting mathematical framework.

4.1. States and Stacks

To formalise the local variables and local channels of χ in χσ, we chose to take all declarations (which in χσ

means both variable and channel declarations) of the same process together into one list of declarations: a state.These states are then stacked in order to have a scoping mechanism: if the value of a particular variable or channelis needed, this variable or channel is looked up starting at the top of the stack. In the remainder of this section,we provide notations and functions to define and manipulate states and stacks of states.

Page 6: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 375

We assume there is a countable, infinite number of distinct identifiers, which are typically denoted by i, i′, . . . .Identifiers can be used to denote variables or channels, but not more than one of these entities at the same time.Identifiers denoting variables are typically denoted by x, x′, . . . and identifiers denoting channels are typicallydenoted by m, m′, . . . . Variable and channel identifiers are associated with values. Values are typically denotedby c, c′, . . . . The association of an identifier and a value is called a valuation and denoted by i → c. Valuationsare typically denoted by v, v′, . . . .

States are lists of valuations and are typically denoted by s, s′, . . . . Furthermore, it is required that the iden-tifiers occurring in the valuations be mutually distinct. The empty state is denoted by λs and a non-empty stateis constructed from a valuation v and a state s and is denoted by v : s. The set of all states is called State.

The function dom returns the domain of a state, that is, it returns the set of identifiers in the state. A variableis defined in a state if and only if it is in the domain of the state. If it is not in the domain, it is undefined in thatstate. Substitution on states, s[c/i], is defined by

λs[c/i] � λs,(i → c : s)[c′/i′] � i → c′ : s if i � i′,(i → c : s)[c′/i′] � i → c : s[c′/i′] if i �� i′.

Expressions are typically denoted by e, e′, . . . . It is outside the scope of this article to discuss χσ expressions indetail. An algebraic specification in Membership Equational Logic [Mes98, BJM97] of χσ expressions is givenin [BoK02a]. Consequently, there exists a congruence relation on expressions. We need this fact when we discussour equivalence relation on χσ processes, see Section 4.2. If e is an expression and s a state, then the evaluationof e in s is written as s(e). By evaluating an expression, a value may result. However, since an expression e cancontain variables that are undefined in a state s, it is possible that evaluation s(e) is not a value, but remains anexpression.

The set function updates the value of an identifier in a state, or, if the identifier does not occur in the state,adds the identifier and the value to a state. It is defined by

set(s, λs) � s,set(s, i → c : s′) � set(s[c/i], s′) if i ∈ dom(s),set(s, i → c : s′) � set(i → c : s, s′) if i �∈ dom(s)

States can be stacked in so-called state stacks. These state stacks are typically denoted by σ, σ′, . . . . Theempty state stack is denoted by λσ. A non-empty state stack is constructed by a state s and a state stack σ and isdenoted by s :: σ. The set of all state stacks is called Stack. In the remainder of this document, we mostly refer tostate stacks by simply using the word stack. In a stack, the same identifier can occur more than once, but only indifferent states of the stack.

As for states, the function dom returns the domain of a stack, that is, it returns the set of identifiers in the(states of the) stack. A variable is defined in a stack if and only if it is in the domain of the stack. If it is not inthe domain, it is undefined in that stack. Substitution is generalised on stacks as follows:

λσ[c/i] � λσ,(s :: σ)[c/i] � s[c/i] :: σ if i ∈ dom(s),(s :: σ)[c/i] � s :: σ[c/i] if i �∈ dom(s)

Similarly, evaluation of expressions is generalised to stacks. For instance, if e is an expression and σ a stack,then σ(e) is the evaluation of e in σ. We do not need a set function on stacks.

4.2. A Semantical Model for χσ

The syntax and semantics of χσ are defined in a Structured Operational Semantics style (SOS). So, a set of deduc-tion rules describes how χσ processes evolve into other χσ processes. These rules define for each χσ process alabelled transition system (LTS) consisting of a set of states S, a set of binary relations on states RS×S (repre-senting labelled transitions), and a set of unary relations on states RS (representing labelled states). The states ofLTSs are χσ processes. The set of all χσ processes is called P . The syntax of processes is defined in Section 4.4. Ifa χσ process evolves into another χσ process, it performs either an action or a delay. Therefore, we have two typesof binary transitions: action transitions and delay transitions. Furthermore, χσ processes can have the ability toterminate. Therefore, we also have a unary termination relation. The names we use for the binary relations areparameterised by σ, σ′ ∈ Stack and � ∈ Action ∪ R>0, with Action the set of actions, and R>0 the set of all

Page 7: Redesign of a Systems Engineering Language: Formalisation of ?

376 V. Bos and J. J. T. Kleijn

5

4

a

1

3

3

3

0 2

b c

(a) No time factorisation.

4

3

a

2

3

0 1

b c

(b) Time factorisation.

1

0

a

(c) Maximal progress.

Fig. 3. Time factorisation and maximal progress.

positive real numbers. Typically, actions are denoted by a, a′, . . . and positive real numbers by d, d′, . . . . Thesyntax of actions is defined in Section 4.4. Binary relations r ∈ RS×S are denoted by 〈 , σ 〉 a−→ 〈 , σ′ 〉 (action

transitions) and 〈 , σ 〉 �d−→ 〈 , σ′ 〉 (delay transitions), where the underscores denote the argument positions. The

names we use for the unary relations are parameterised by a stack σ with σ ∈ Stack and denoted by 〈 , σ 〉↓. A χσ

LTS, is an LTS (S, RS×S , RS), such that S ⊆ P . Note that until now we have only defined the names (or syntax)we use for the unary and binary relations of our LTSs; the relations themselves are defined in Section 4.4 usingdeduction systems. The reason for having structured names for binary and unary relations is that SOS theory toprove properties of the operational semantics is usually applicable only for binary and unary relations.

Note that an LTS and a process term induce a graph with the states being nodes and transitions being edges.These graphs are called process graphs. Process graphs are displayed as in Fig. 3. Action transitions are rep-resented by solid edges labelled by an action. Delay transitions are represented by dashed edges labelled by apositive real number. A node representing a state that can terminate is coloured grey. Finally, the initial state hasa double circle.

We use standard strong bisimulation [GlW96, Mil83, BaZ82, Par81] as our equivalence on processes:

Definition 1 (Strong Bisimulation) . A strong bisimulation on processes is a relation R ∈ P × P such that for all( p, q) ∈ R the following holds:

1. ∀ σ : 〈 p, σ 〉↓ ⇔ 〈 q, σ 〉↓,

2. ∀ σ, a, p′, σ′ : 〈 p, σ 〉 a−→ 〈 p′, σ′ 〉 ⇒ ∃ q′ : 〈 q, σ 〉 a−→ 〈 q′, σ′ 〉 ∧ (p′, q′) ∈ R,

3. ∀ σ, a, q′, σ′ : 〈 q, σ 〉 a−→ 〈 q′, σ′ 〉 ⇒ ∃ p′ : 〈 p, σ 〉 a−→ 〈 p′, σ′ 〉 ∧ (p′, q′) ∈ R,

4. ∀ σ, d , p′, σ′ : 〈 p, σ 〉 �d−→ 〈 p′, σ′ 〉 ⇒ ∃ q′ : 〈 q, σ 〉 �

d−→ 〈 q′, σ′ 〉 ∧ (p′, q′) ∈ R,

5. ∀ σ, d , q′, σ′ : 〈 q, σ 〉 �d−→ 〈 q′, σ′ 〉 ⇒ ∃ p′ : 〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉 ∧ (p′, q′) ∈ R.

Two processes p and q are strongly bisimilar, denoted by p ↔ q, if there exists a bisimulation relation R suchthat (p, q) ∈ R.

In [BoK02a], we proved that strong bisimulation is a congruence for all process operators of χσ. The proofdepends on a specific congruence theorem for a syntactic class of deduction systems. There are many differentsyntactic formats for deduction rules; see [AFV01] for an overview. The most general format described in thatoverview is the panth format. The ‘p’ of panth indicates that, in addition to binary relations, the format allowspredicates (unary relations). The ‘n’ of panth indicates that, in addition to positive formulae, the format allowsnegative formulae in premises of deduction rules. We made use of an even more general syntactic format developedby Middelburg [Mid01] which is called the relaxed panth format. In addition to the predicates and the negativepremises, this format supports variable binding operators and, which is more important in our case, given-sorts.Given-sorts are data types for which a well-established semantics with equivalence relation exists. The semanticsof these data types need not have to be defined in an SOS style, i.e., with deduction rules. Under certain restric-tions, the relaxed panth format allows usage of the given-sorts data types in the SOS definition of the other (notgiven-sorts) data types. In our case the χσ data types are treated as given-sorts and the χσ processes as the notgiven-sorts. As mentioned before, there exists a congruence relation on the data types of χσ. The congruence

Page 8: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 377

theorem of the relaxed panth format states that if the restrictions on given-sorts are not violated and the deductionrules adhere to the syntactic format and are stratifiable (meaning that no deduction rule depends negatively onitself), strong bisimulation is a congruence.

4.3. A Time Model for χσ

This section discusses timing aspects that we had to take into consideration. For example, we had to decidewhether to implement a discrete or continuous time model. Also, we had to decide in which way passage of timeinteracts with the ability to perform actions and the ability to terminate.

Discrete versus continuous time. A discrete time implementation describes time by viewing the time domain as anenumeration of time slices. Different time slices need not necessarily represent the same amount of real physicaltime. In a continuous time implementation all timing is measured on a continuous time scale. In Section 3, wementioned that χ has continuous time and therefore χσ too. Continuous time models always raise the question:what about Zeno behaviour? In our terminology, Zeno behaviour is an infinite sequence of delay transitions inwhich time never reaches a given fixed time bound. This is possible, e.g., if each delay transition is half the sizeof the previous time step. In χσ, processes can have Zeno behaviour. However, as far as we know it is impossibleto specify a process which has Zeno behaviour only. In Section 5 we discuss some examples related to Zenobehaviour in χσ.

Monotonicity of delays. In χσ’s time model, any delay can be split into smaller delays of which the accumulativevalue is equal to the original delay. Furthermore, performing such smaller delays successively results in the sameprocess as performing one big delay. We call this time property monotonicity.

Time factorisation and maximal progress. Time factorisation is the property that progress of time as such cannotdetermine a choice [BaB96, BaM01]. Another name for time factorisation is time determinacy [Yi91]. Maximalprogress is the property that time cannot progress if actions can be executed [Yi91, NiS94]. For example, considera process that can perform an action a, or delay for 3 time units and perform action b, or delay for 3 time unitsand perform action c. The process graph for the case that time factorisation is not implemented is depicted inFig. 3(a). (We apologise for the confusing numbering of states; it was generated automatically.) Here, we see thatprogress of time does make a choice. The process graph for the case that time factorisation is implemented isdepicted in Fig. 3(b). As can be seen, progress of time does not make a choice. The choice to perform action bor c is preserved until after the delay. The process graph for the case that maximal progress is implemented isdepicted in Fig. 3(c). It is obvious that here the opportunity to delay is lost.

Note that the common interpretation of time factorisation does not prohibit a choice to be made between twoalternatives that do not necessarily delay for the same amount of time. So, it does not prohibit the execution of alarge delay, thereby losing alternatives that cannot perform that large delay. Consider for example a process thatcan delay for 3 time units and perform action a, or delay for 5 time units and perform action b. The process graphfor the case that time factorisation is not implemented is depicted in Fig. 4(a) and the case that time factorisationis implemented is depicted in Fig. 4(b). Note that we use monotonicity to account for the delay of 2 time units.As can be seen, time factorisation does not prohibit the delay of 5 time units to be executed at once. Anotherpossible interpretation is the one depicted in Fig. 4(c). In that case time factorisation establishes that progress oftime never determines a choice. So, the opportunity to perform action a after 3 time units prohibits delays greaterthan 3.

We decided to implement time factorisation so that progress of time can never determine a choice (the inter-pretation as depicted in Fig. 4(c)). So, if two or more alternatives can delay, then they will delay together. Asa consequence, opportunities for action performance or termination cannot be ignored, i.e., skipped by takinglarger delay transitions. In addition, if maximal progress is desired, a special operator (the maximal progressoperator), see below, should be used. This operator prohibits delay transitions if action transitions are possible.

Notice that the selection statement of the original χ language has no time factorisation, whereas the selectivewaiting statement does have time factorisation. Moreover, time factorisation of the selective waiting statementonly applies to the event statements following the guards.

Time additivity. In [KLL96], time additivity is defined as follows. If a process p can evolve into a process q bydelaying t time units and process q can evolve into process r by delaying t′ time units, then p can evolve into r

Page 9: Redesign of a Systems Engineering Language: Formalisation of ?

378 V. Bos and J. J. T. Kleijn

4

1

5

3

3

0 2

b a

(a) No time factorisation.

4

1

5 3

3

0

2

b

a2

(b) Time factorisation(interpretation 1).

4

3

3

0

2 1

b

a 2

(c) Time factorisation(interpretation 2).

Fig. 4. Different interpretations of time factorisation.

3

2

3

0 1

2 a

(a) No time additivity

3

0

5 2

3

1

2 a

(b) Time additivity

Fig. 5. Time additivity.

by delaying t + t′ time. For example, consider a process that can delay for 3 time units and can then choose toperform an action a or delay for 2 more time units. Figure 5(a) shows the process graph of this process in casetime additivity is not implemented. In case we do have time additivity, that process can also delay for 5 time unitsfrom the start and ignore the opportunity to perform action a after 3 time units. This is depicted in Fig. 5(b).Since this contradicts our interpretation of time factorisation, we chose not to implement time additivity in χσ.

4.4. Structured Operational Semantics for χσ

Below, we discuss χσ processes and operators. Processes are typically denoted by p, p′, . . . , q, q′, . . . , and r, r′, . . . .The atomic processes of χσ are called atomic because they do not have process arguments. More complex processesare constructed using the χσ process operators. Recall from Section 4.4 that the operational semantics is definedin terms of unary termination relations 〈 , σ 〉↓ and binary transition relations 〈 , σ 〉 a−→ 〈 , σ′ 〉. Therefore, thededuction rules we present in Tables 2–10 are in fact schemes for deduction rules.

The atomic processes we introduce are listed below. Their deduction rules are given in Table 2.

• The deadlock process δ, which cannot do anything (it even stops time).• The empty process ε, which can terminate.• The skip process skip, which can perform the internal action τ .• The delay process �e, which can delay for e time units.• The assignment process x :� e, which assigns the value of expression e to variable x.• The send process m ! e, which can send the value of expression e via channel m.• The receive process m ? x, which can receive the value of channel m and assign it to x.

Page 10: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 379

Table 2. SOS rules for atomic processes

〈 ε, σ 〉↓1

σ(e) � 0

〈 �e, σ 〉↓2

〈 skip, σ 〉 τ−→ 〈 ε, σ 〉3

σ(e) � c

〈 x :� e, σ 〉 aa(x,c)−−−−−→ 〈 ε, σ[c/x] 〉4

σ(e) � c

〈 m ! e, σ 〉 sa(m,c)−−−−−→ 〈 ε, σ[c/m] 〉5

σ(m) � c

〈 m ? x, σ 〉 ra(m,x)−−−−−→ 〈 ε, σ[c/x] 〉6

〈 m ! e, σ 〉 �

d−→ 〈 m ! e, σ 〉7

〈 m ? x, σ 〉 �

d−→ 〈 m ? x, σ 〉8

0 < d � σ(e)

〈 �e, σ 〉 �

d−→ 〈 �e − d , σ 〉9

Table 3. Deduction rules for the guarded operator

σ(e) � true, 〈 p, σ 〉↓〈 e :→ p, σ 〉↓

10σ(e) � true, 〈 p, σ 〉 a−→ 〈 p′, σ′ 〉

〈 e :→ p, σ 〉 a−→ 〈 p′, σ′ 〉11

σ(e) � true, 〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉〈 e :→ p, σ 〉 �

d−→ 〈 p′, σ′ 〉12

Since the deadlock process δ denotes ‘no behaviour’, there are no deduction rules for the deadlock process. Rule 1states that the empty process can terminate. Rule 2 states that a delay process can terminate if the argument of thedelay process evaluates to zero. Rules 3 through 6 state that skip, x :� e, m ! e, and m ? x can perform the internalaction τ , the assignment action aa(x, c), the send action sa(m, c), and the receive action ra(m, x), respectively.Note that the send process sets the value of a channel and the receive process gets the value of a channel. Besidestheir corresponding actions, the processes m ! e and m ? x can also perform a delay d . This is defined by Rules 7and 8. Rule 9 describes transition behaviour of the delay process. It states that a delay process can perform adelay greater than zero, but smaller than or equal to the value of the argument of the delay process. In additionto the atomic processes, χσ has eight process operators:

the guard: :→the alternative composition: []the sequential composition: ;the repetition: ∗

the parallel composition: ‖the state operator: |[ | ]|the maximal progress operator: π( )the encapsulation operator: ∂ ( )

Ordering the first five operators on decreasing binding power results in the sequence ‘∗’, ‘ ; ’, ‘:→’, ‘[]’, ‘‖’. Forthe other operators we do not need to define the binding power, because they explicitly delimit their arguments.The operational semantics of these operators is discussed in the following paragraphs.

The guard operator has signature :→ : bool×P → P , with bool the set of Boolean expressions. A processe :→ p behaves like p if the guard e evaluates to true, otherwise, it behaves like δ. The deduction rules for theguard operator are listed in Table 3. Rule 10 states that a guarded process can terminate if the guard evaluates totrue and if its process argument p can terminate. Rule 11 states that a guarded process can perform an action ifthe guard evaluates to true and if its process argument can perform that action. In the same way, Rule 12 statesthat a guarded process can perform a delay if the guard evaluates to true and if its process argument can performthat delay.

The alternative composition operator has signature [] : P × P → P . A process p [] q either executes p or qwhere the choice is non-deterministic. Passage of time is handled more subtly due to the fact that we want ouroperators to exhibit certain time properties, as described in Section 4.3. The deduction rules for the alternativecomposition operator are listed in Table 4. Rule 13 states that an alternative composition of two processes p andq can terminate if one of the processes p or q can terminate. Rule 14 states that an alternative composition of twoprocesses can perform an action if one of the two processes can perform that action. Rules 15 and 16 describe howthe alternative composition of two processes delays. Rule 15 states that if one of the two processes can perform adelay and the other cannot, then the alternative composition can perform that delay but loses the alternative thatcould not delay. On the other hand, if both processes can perform the same delay, then its alternative compositioncan perform that delay too and both alternatives are preserved. This is stated in Rule 16. At first reading, this rule(and maybe even Rule 15) might look suspicious, because σ and σ′ occur in both premises. It is well known thatsuch rules often break congruence properties of equivalence relations on processes. However, as explained before,σ and σ′ are part of the name of the binary relations. In other words, σ and σ′ are (some of the) meta-variableswe use to write schemas of deduction rules for purely binary or unary relations.

The sequential composition operator has signature ; : P × P → P . A process p ; q behaves like pfollowed by q; process q is allowed to start if p can terminate. As with the alternative composition operator

Page 11: Redesign of a Systems Engineering Language: Formalisation of ?

380 V. Bos and J. J. T. Kleijn

Table 4. SOS rules for the alternative composition operator

〈 p, σ 〉↓〈 p [] q, σ 〉↓, 〈 q [] p, σ 〉↓

13〈 p, σ 〉 a−→ 〈 p′, σ′ 〉

〈 p [] q, σ 〉 a−→ 〈 p′, σ′ 〉, 〈 q [] p, σ 〉 a−→ 〈 p′, σ′ 〉14

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q, σ 〉 ��−→

〈 p [] q, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q [] p, σ 〉 �

d−→ 〈 p′, σ′ 〉15

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q, σ 〉 �

d−→ 〈 q′, σ′ 〉〈 p [] q, σ 〉 �

d−→ 〈 p′ [] q′, σ′ 〉16

Table 5. SOS rules for the sequential composition operator

〈 p, σ 〉↓, 〈 q, σ 〉↓〈 p ; q, σ 〉↓

17〈 p, σ 〉 a−→ 〈 p′, σ′ 〉

〈 p ; q, σ 〉 a−→ 〈 p′ ; q, σ′ 〉18

〈 p, σ 〉↓, 〈 q, σ 〉 a−→ 〈 q′, σ′ 〉〈 p ; q, σ 〉 a−→ 〈 q′, σ′ 〉

19〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 p, σ 〉� ↓〈 p ; q, σ 〉 �

d−→ 〈 p′ ; q, σ′ 〉20

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q, σ 〉 ��−→〈 p ; q, σ 〉 �

d−→ 〈 p′ ; q, σ′ 〉21

〈 p, σ 〉↓, 〈 q, σ 〉 �

d−→ 〈 q′, σ′ 〉, 〈 p, σ 〉 ��−→〈 p ; q, σ 〉 �

d−→ 〈 q′, σ′ 〉22

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 p, σ 〉↓, 〈 q, σ 〉 �

d−→ 〈 q′, σ′ 〉〈 p ; q, σ 〉 �

d−→ 〈 (p′ ; q) [] q′, σ′ 〉23

Table 6. SOS rules for the repetition operator

〈 p∗, σ 〉↓24

〈 p, σ 〉 a−→ 〈 p′, σ′ 〉〈 p∗, σ 〉 a−→ 〈 p′ ; p∗, σ′ 〉

25〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉〈 p∗, σ 〉 �

d−→ 〈 p′ ; p∗, σ′ 〉26

previously discussed, also here passage of time is handled more subtly. The deduction rules for the sequentialcomposition operator are listed in Table 5. Rule 17 states that if processes p and q can terminate, then also thesequential composition p ; q can. Rule 18 states that if process p can perform an action, then the sequentialcomposition p ; q can also perform the action. Rule 19 states that if process p terminates and process q canperform an action, then the sequential composition p ; q can also perform the action. The delay behaviour ofthe sequential composition operator is quite intricate. The reason for this is that we want to make sure that allprocess operators exhibit certain time properties; see Section 4.3. As a consequence, we distinguish three differentcases for a sequential composition p ; q. In the first case, only the delay behaviour of p is relevant, as defined byRules 20 and 21. Note that possible delay behaviour of q is irrelevant since either p cannot terminate (Rule 20)or q cannot delay (Rule 21). In the second case, only the delay behaviour of q is relevant since p can terminatebut not delay, as defined by Rule 22. Finally, if both p and q can delay and p can also terminate, then they haveto delay together, as defined by Rule 23. In Section 5 we give an example of a sequential composition of twoprocesses that delay together.

The repetition operator has signature ∗ : P → P . A process p∗ executes p zero or more times, i.e., the repe-tition operator is the unary Kleene star [Kle56, CEW58]. According to Rule 24, a repetition process can alwaysterminate. Also, if p can execute an action or a delay, then p∗ can execute this action or delay too, as defined byRules 25 and 26. In these rules, the repetitive character becomes clear; namely, the original repetition process p∗occurs as the second argument of a sequential composition.

The parallel composition operator has signature ‖ : P × P → P . A process p ‖ q, with p and q processes,executes p and q concurrently in an interleaved fashion. The deduction rules for the parallel composition operatorare listed in Table 7. If both processes p and q can terminate, then the parallel composition p‖q can also terminate,as defined by Rule 27. If process p can perform an action, then both the parallel composition p ‖ q and q ‖ pcan perform the action as well, as defined by Rule 28. Furthermore, if processes p and q can perform matchingsend and receive actions, then the parallel compositions p ‖ q and q ‖ p can perform a communication actionca(m, x, c), as defined by Rule 29. The delay behaviour of the parallel composition is defined by Rules 30 and 31.

Page 12: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 381

Table 7. SOS rules for the parallel composition operator

〈 p, σ 〉↓, 〈 q, σ 〉↓〈 p ‖ q, σ 〉↓

27〈 p, σ 〉 a−→ 〈 p′, σ′ 〉

〈 p ‖ q, σ 〉 a−→ 〈 p′ ‖ q, σ′ 〉, 〈 q ‖ p, σ 〉 a−→ 〈 q ‖ p′, σ′ 〉28

〈 p, σ 〉 sa(m,c)−−−−−→ 〈 p′, σ′ 〉, 〈 q, σ′ 〉 ra(m,x)−−−−−→ 〈 q′, σ′′ 〉

〈 p ‖ q, σ 〉 ca(m,x,c)−−−−−−→ 〈 p′ ‖ q′, σ′′ 〉, 〈 q ‖ p, σ 〉 ca(m,x,c)−−−−−−→ 〈 q′ ‖ p′, σ′′ 〉29

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q, σ 〉↓, 〈 q, σ 〉 ��−→

〈 p ‖ q, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q ‖ p, σ 〉 �

d−→ 〈 p′, σ′ 〉30

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 q, σ 〉 �

d−→ 〈 q′, σ′ 〉〈 p ‖ q, σ 〉 �

d−→ 〈 p′ ‖ q′, σ′ 〉31

Table 8. Sos rules for the state operator

〈 p, s :: σ 〉↓〈 |[ s | p ]|, σ 〉↓

32〈 p, s :: σ 〉 a−→ 〈 p′, s′ :: σ′ 〉

〈 |[ s | p ]|, σ 〉 a−→ 〈 |[ s′ | p′ ]|, σ′ 〉33

〈 p, s :: σ 〉 �

d−→ 〈 p′, s′ :: σ′ 〉〈 |[ s | p ]|, σ 〉 �

d−→ 〈 |[ s′ | p′ ]|, σ′ 〉34

If only one argument of a parallel composition p ‖ q can delay, then the parallel composition can only delay ifthe other argument can terminate. This is defined by Rule 30. Note that in this case, by delaying the undelayableargument is lost (it terminated). If both arguments can delay, then they delay together, as defined by Rule 31.

The state operator has signature |[ | ]| : State × P → P . A process |[ s | p ]| introduces a state s containingvariables and channels. The deduction rules for the state operator are listed in Table 8. The semantics of the stateoperator process |[ s | p ]| under a stack σ is similar to the semantics of its process argument p under the stacks :: σ (s pushed onto σ). So, in order to determine if |[ s | p ]| can terminate under a stack σ, we have to determineif p terminates under stack s :: σ. This is defined by Rule 32. The same ‘push s on σ’ approach determines theaction and delay behaviour of the state operator, as defined by rules 33 and 34, respectively.

Although we mentioned in Section 3 that the state operator of χσ is a new operator, it is in fact an instantiationof the ACP state operator described in [BaB88, BaB91] and later generalised in [Bla96]. The ACP state operatoris written as λs(p), where s is an element of some state set S (not necessarily the same as the set State of χσ

states) and p an ACP process. The process algebra ACP is parameterised by a set of (atomic) actions called A.The operational semantics of λs(p) is defined by

pa−→ p′

λs(p)action(a,s)−−−−−−→ λeffect(a,s)(p

′),

where a ∈ A, the function action : A × S → A returns an action, and the function effect : A × S → S returnsa state. Our state operator is an instantiation of the ACP state operator in the following way. Take S � State,A � Stack × (Action ∪ R>0) × Stack, and define

action((s :: σ, a, s′ :: σ′), s) � (σ, a, σ′) effect((s :: σ, a, s′ :: σ′), s) � s′action((s :: σ, d , s′ :: σ′), s) � (σ, d , σ′) effect((s :: σ, d , s′ :: σ′), s) � s′

where s, s′ ∈ State; σ, σ′ ∈ Stack; a ∈ Action; and d ∈ R>0. These are partial definitions of action and effect,but they can be made total (which is required for the ACP state operator). Another technicality that has to beaddressed is the combination of the ACP state operator with successful termination predicates 〈 , σ 〉↓ for all σ.

The maximal progress operator has signature π : P → P . A process π p enforces maximal progress; that is,π p can delay only if p can delay and p cannot perform an action. The deduction rules for the maximal progressoperator are listed in Table 9.

The encapsulation operator has signature ∂ ( ) : ˙(Action) × P → P , where ˙(Action) denotes the powerset of Action. A process ∂A(p) behaves like p, except that actions in A are encapsulated, i.e., prohibited. Thisoperator can be used, for example, prevent send and receive actions occurring in isolation. The deduction rulesfor the maximal progress operator are listed in Table 10. Termination behaviour of ∂A(p) is the same as the

Page 13: Redesign of a Systems Engineering Language: Formalisation of ?

382 V. Bos and J. J. T. Kleijn

Table 9. SOS rules for the maximal progress operator

〈 p, σ 〉↓〈 π(p), σ 〉↓

35〈 p, σ 〉 a−→ 〈 p′, σ′ 〉

〈 π(p), σ 〉 a−→ 〈 π(p′), σ′ 〉36

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉, 〈 p, σ 〉 �−→〈 π(p), σ 〉 �

d−→ 〈 π(p′), σ′ 〉37

Table 10. SOS rules for the encapsulation operator

〈 p, σ 〉↓〈 ∂A(p), σ 〉↓

38〈 p, σ 〉 a−→ 〈 p′, σ′ 〉, a �∈ A

〈 ∂A(p), σ 〉 a−→ 〈 ∂A(p′), σ′ 〉39

〈 p, σ 〉 �

d−→ 〈 p′, σ′ 〉〈 ∂A(p), σ 〉 �

d−→ 〈 ∂A(p′), σ′ 〉40

Table 11. Some χσ laws

1. �0 � ε2. p [] δ � p3. p [] p � p4. p [] q � q [] p5. (p [] q) [] r � p [] (q [] r)6. p ; ε � p

7. ε ; p � p8. δ ; p � δ9. (p ; q) ; r � p ; (q ; r)10. (p [] q) ; r � p ; r [] q ; r11. p ‖ ε � p12. p ‖ q � q ‖ p

13. (p ‖ q) ‖ r � p ‖ (q ‖ r)14. |[ λs | p ]| � p15. |[ s0 | |[ s1 | p ]| ]| � |[ set(s0, s1) | p ]|16. π(π(p)) � π(p)17. �e ; p [] �e + e′ � �e ; (p [] �e′)

termination behaviour of p; see Rule 38. Action behaviour of ∂A(p) is the same as for p, provided the concerningaction is not in A; see Rule 39. Finally, Rule 40 defines the delay behaviour of ∂A(p); as delay behaviour cannotbe encapsulated, it is the same as for p.

To conclude this section, we make some remarks about the role of the internal τ action in χσ. In general,an internal action like τ , which was first introduced by Milner [Mil80], is a way to abstract from implemen-tation details. That is, abstraction renames certain (implementation) actions into τ actions. After abstraction,it is possible to formally analyse specification–implementation correctness. In addition to an internal action,a suitable equivalence is required that treats τ differently from other atomic actions. In the mentioned workby Milner, branching bisimulation is proposed as a candidate equivalence relation. In a setting with time, aswe have, timed branching bisimulation is usually the best candidate. Coming up with a proper definition oftimed branching bisimulation (such that it is a congruence) is a complex task, as can be seen from publishedresults [GlW96, Bas96, Gla94, Klu93]. Furthermore, to the best of the authors’ knowledge, congruence theorems,like the one based on the panth format, do not exist for timed branching bisimulation. Therefore, we chose toleave the definition of timed branching bisimulation as a topic for further research. Having said that, we thinkthere is still a legitimate role for τ in χσ. Namely, we use it to break time factorisation of alternative compositions,which is required in the translations of certain χ statements, as will be discussed in Section 6. We could have usedan assignment action for this purpose too, but then we would have to make sure the variable of the assignmentaction is defined and does not interfere with user-defined variables. Although technically this is possible, thesolution with a τ action is preferred. The translation from χ statements into χσ processes is described in Section 6and Table 12.

4.5. Properties

Table 11 presents some χσ laws: equalities between processes. Recall that the set function in law 15 is defined inSection 4.1. We derived these equalities from the operational semantics by showing that the left-hand side andright-hand side are bisimilar processes according to Definition 1. With these laws, calculations on processes arepossible, as we illustrate in Section 5.

Due to monotonicity, according to which a delay transition can be split into arbitrary many smaller delaytransitions, a process that can delay can perform uncountably many delays. This hampers efficient tool supportbecause computation of all possible (delay) transitions is impossible. However, due to time confluence, we canreduce this set of uncountably many delay transitions into one delay. Informally, the time confluence lemmapresented below says that if a maximal progress process can perform two different delays, then after the smallestdelay the only option is to continue delaying and end up in the state reached by the largest delay. In particular,after the smallest delay, it is not possible to perform actions or to terminate. Therefore, instead of analysing all

Page 14: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 383

0 1aa(x,5)

32aa(y,4)aa(y,10)

Fig. 6. Graph of process S.

delays it suffices to analyse only one delay. In this way, a reduction from an uncountable set of delay transitionsto one delay transition is realised.

Lemma 2 (Time confluence lemma) . Let p be a maximal progress process: p ≡ πq for some process q. Suppose

〈 p, σ 〉 � d ′−→〈 p′, σ′ 〉 and 〈 p, σ 〉 � d ′′−→〈 p′′, σ′′ 〉 and d ′ < d ′′. Then 〈 p′, σ′ 〉 � d ′′−d ′−−−→〈 p′′, σ′′ 〉 and 〈 p′, σ′ 〉� ↓ and 〈 p′, σ′ 〉 �−→.

A proof of the time confluence lemma can be found in [BoK02a]. The time confluence lemma holds only formaximal progress processes. However, all processes of the original language χ exhibit maximal progress. Giventhat χ can be used to model many realistic systems, the lemma is widely applicable.

5. Examples

In this section, several examples are discussed. The first example illustrates χσ’s programming variables. Fur-thermore, we show how SOS rules are deployed to derive transitions. The second example illustrates communi-cation. There, the interaction between the state operator and the parallel composition operator is explained. Theremaining examples concern timing aspects. There, we show how the χσ laws of Table 11 can be used to performcalculations on processes.

Consider a process S with two nested states. The outermost state has two variables, x and y, whereas theinnermost state has only one variable, y:

S � |[ x → 3 : y → 1 : λs | |[ y → 2 : λs | x :� x + y ; y :� x × y ]| ; y :� x − y ]|.The behaviour of this process is depicted in Fig. 6. As can be seen, first the assignment action aa(x, 5) is

performed, thereby updating the value of x in the outermost state to 5. Note that the value of y in the expressionx + y is obtained from the innermost state. After that, it performs action aa(y, 10) and updates the value of y inthe innermost state to 10. The last action S performs is action aa(y, 4), thereby updating the value of y in theoutermost state to 4. Note that the value of y in the innermost state does not influence this final assignment to y.The first transition of process S is derived as follows. Using Rule 4, we have

〈 x :� x + y, y → 2 : λs ::x → 3 : y → 1 : λs :: λσ 〉aa(x,5)−−−−→

〈 ε, y → 2 : λs ::x → 5 : y → 1 : λs :: λσ 〉According to Rule 18 we have

〈 x :� x + y ; y :� x × y, y → 2 : λs ::x → 3 : y → 1 : λs :: λσ 〉aa(x,5)−−−−→

〈 ε ; y :� x × y, y → 2 : λs ::x → 5 : y → 1 : λs :: λσ 〉Applying Rule 33 then gives us

〈 |[ y → 2 : λs | x :� x + y ; y :� x × y ]|, x → 3 : y → 1 : λs :: λσ 〉aa(x,5)−−−−→

〈 |[ y → 2 : λs | ε ; y :� x × y ]|, x → 5 : y → 1 : λs :: λσ 〉Next, by applying Rule 18 we get

〈 |[ y → 2 : λs | x :� x + y ; y :� x × y ]| ; y :� x − y, x → 3 : y → 1 : λs :: λσ 〉aa(x,5)−−−−→

〈 |[ y → 2 : λs | ε ; y :� x × y ]| ; y :� x − y, x → 5 : y → 1 : λs :: λσ 〉

Page 15: Redesign of a Systems Engineering Language: Formalisation of ?

384 V. Bos and J. J. T. Kleijn

Finally, we apply Rule 33 again and find the transition we were looking for:

〈 |[ x → 3 : y → 1 : λs | |[ y → 2 : λs | x :� x + y ; y :� x × y ]| ; y :� x − y ]|, σ 〉aa(x,5)−−−−→

〈 |[ x → 5 : y → 1 : λs | |[ y → 2 : λs | ε ; y :� x × y ]| ; y :� x − y ]|, σ 〉Similar derivations can be made for the remaining transitions of Fig. 6.

The following example illustrates communication. Consider process

C � |[ ∼m → 0 : λs | ∼m ! 1 ‖ |[ x → 2 : λs | ∼m ? x ]| ]|This process has a local channel ∼m with value 0 and consists of two parallel subprocesses. One of these pro-cesses tries to send value 1 over channel ∼m. The other process is able to receive a value over ∼m and store it invariable x (which is initialised to 2). According to Rules 5, 6, 29 and 33, we can derive the following transitionfor arbitrary σ:

〈 |[ ∼m → 0 : λs | ∼m ! 1 ‖ |[ x → 2 : λs | ∼m ? x ]| ]|, σ 〉ca(∼m,x,1)−−−−−−−→

〈 |[ ∼m → 1 : λs | ε ‖ |[ x → 1 : λs | ε ]| ]|, σ 〉So, process C can perform communication action ca(∼m, x, 1) and thereby communicate value 1 over chan-nel ∼m. Note that both the value of the channel and the value of the variable are updated.

As mentioned above, the following examples illustrate timing aspects of χσ. First we shall discuss Zeno behav-iour of χσ processes in more detail. Suppose a process p can perform a delay transition, e.g., p ≡ �2, which means

〈 p, σ 〉 �2−→ 〈 �0, σ 〉. Due to monotonicity of delays, p can choose to perform a delay of size 1: 〈 p, σ 〉 �

1−→ 〈 �1, σ 〉.Clearly, this can be continued as follows: 〈 �1, σ 〉 �

0.5−−→ 〈 �1.5, σ 〉 �0.25−−→ 〈 �1.75, σ 〉 �

0.125−−−→ . . . , which is an infinitesequence of delay transitions in which time never progresses beyond 2. This illustrates that χσ processes canexhibit Zeno behaviour. In Section 4.3, we mentioned that it is not possible, as far as we know, to define a χσ

process that has Zeno behaviour only. By this we mean a process of which all sequences of transitions are infinitesequences of delay transitions such that in none of the sequences time progresses beyond any fixed bound. The�2 processes of the example have, in addition to the given infinite sequence, infinitely many finite sequences of

delay transitions, e.g., 〈 �2, σ 〉 �2−→〈 �0, σ 〉 and 〈 �2, σ 〉 �

1−→〈 �1, σ 〉 �1−→〈 �0, σ 〉. This shows that �2 does not have

Zeno behaviour only. A process that has infinite sequences of delay transitions only is (�2)∗. However, among

the (infinite) sequences of this process is the sequence 〈 (�2)∗, σ 〉 �2−→〈 �0 ; (�2)∗, σ 〉 �

2−→〈 �0 ; (�2)∗, σ 〉 �2−→ . . . .

Clearly, in this sequence, time progresses beyond any fixed bound. So, also (�2)∗ does not have Zeno behaviouronly. A process that has infinite sequences only and in which time never progresses beyond a certain bound is|[ x → 1 : λs | (�x ; x :� x/2)∗ ]|. One of the sequences is

〈 |[ x → 1 : λs | (�x ; x :� x/2)∗ ]|, σ 〉� 1−→〈 |[ x → 1 : λs | �x − 1 ; x :� x/2 ; (�x ; x :� x/2)∗ ]|, σ 〉 aa(x,0.5)−−−−−→〈 |[ x → 0.5 : λs | ε ; (�x ; x :� x/2)∗ ]|, σ 〉� 0.5−−→〈 |[ x → 0.5 : λs | �x − 0.5 ; x :� x/2 ; (�x ; x :� x/2)∗ ]|, σ 〉 aa(x,0.25)−−−−−−→. . .

This is an infinite sequence in which time progresses but never reaches 2. However, it is not Zeno behaviour,because delay transitions alternate with action transitions. We expect that there are no χσ processes with Zenobehaviour only.

We will now look at some other time aspects of χσ. Consider the following processes:

TF � �3 [] �4, TF � �3 ; skip [] �4 ; skip,TF � (�3 [] �4) ; skip,

TF � �3 ; skip [] �4,TF � �3 ; (skip [] �1)

The graph of process TF is depicted in Fig. 7(a). It shows that both alternatives delay together and that theability to terminate after a delay of 3 time units cannot be ignored. Note that the process graphs show only themaximal delay transition for processes that can delay. For these processes, there is actually a dense set of delaytransitions. However, due to time confluence, only the maximal delay transition is relevant.

Page 16: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 385

2

1

3

0

1

(a) Graph of processes TF.

3

2

3

1

0

tau

tau

1

(b) Graph of processes TF and TF.

0

1

3

2

tau 1

(c) Graph of processes TF and TF.

Fig. 7. Time factorisation.

2

1

3

0

1

(a) Graph of process MP.

2

1

3

0

tau

(b) Graph of processes MP.

2

1

3

0

tau

(c) Graph of processes MP.

Fig. 8. Maximal progress.

Processes TF and TF are equal according to Law 10. Consequently, their process graphs are identical, whichis depicted in Fig. 7(b). Also here, we see that both alternatives delay together and that the ability to performaction τ after 3 time units cannot be ignored. The same goes for the processes TF and TF. They are equalaccording to Law 17 and their process graph is depicted in Fig. 7(b).

Let us next reconsider the processes TF, TF, and TF under maximal progress:

MP � π(�3 [] �4), MP � π((�3 [] �4) ; skip), MP � π(�3 ; (skip [] �1))

The graph of process MP, as depicted in Fig. 8(a), is identical to the graph of process TF. Here the max-imal progress operator has no effect because process TF does not perform any actions. However, the maximalprogress operator does have effect when applied to the processes TF and TF. Their process graphs are depictedin Figs 8(b) and 8(c). As can be seen, the alternative to delay for 1 time unit is lost because of the opportunity toperform the internal action τ . As a consequence, under maximal progress the processes TF and TF are equal.

Besides the alternative composition operator also the sequential composition operator accounts for timefactorisation. This we can illustrate by looking at the following process:

TF � (�3 [] ε) ; �4

Since the first argument of the sequential composition can delay as well as terminate, and the second argumentcan also delay, we have in fact two delay alternatives which should delay together.

The graph of process TF is depicted in Fig. 9. At first sight, it may not be obvious that this process graph cor-responds to the behaviour specified in process TF. Therefore, consider the following computation (the numbers

above equality signs refer to the laws of Table 11): TF � (�3[]ε) ; �4 10� �3 ; �4[]ε ; �4 7� �3 ; �4[]�3+1 17�

Page 17: Redesign of a Systems Engineering Language: Formalisation of ?

386 V. Bos and J. J. T. Kleijn

0 23

3 131

Fig. 9. Graph of process TF.

Table 12. Translation of compound χ statements into χσ processes

χ statement: S χσ process: T(S) χ statement: S χσ process: T(S)

[ b1 −→ S1[] b2 −→ S2

...[] bn −→ Sn]

( b1 :→ skip ; T(S1)[] b2 :→ skip ; T(S2)

...[] bn :→ skip ; T(Sn))

[ b1 ; s1 −→ S1[] b2 ; s2 −→ S2

...[] bn ; sn −→ Sn]

( b1 :→ T(s1) ; skip ; T(S1)[] b2 :→ T(s2) ; skip ; T(S2)

...[] bn :→ T(sn) ; skip ; T(Sn))

∗[ b1 −→ S1[] b2 −→ S2

...[] bn −→ Sn]

( b1 :→ skip ; T(S1)[] b2 :→ skip ; T(S2)

...[] bn :→ skip ; T(Sn)) ∗ ; ¬(b1 ∨ b2 ∨ . . . ∨ bn) :→ ε

∗[ b1 ; s1 −→ S1[] b2 ; s2 −→ S2

...[] bn ; sn −→ Sn]

( b1 :→ T(s1) ; skip ; T(S1)[] b2 :→ T(s2) ; skip ; T(S2)

...[] bn :→ T(sn) ; skip ; T(Sn)) ∗ ; ¬(b1 ∨ b2 ∨ . . . ∨ bn) :→ ε

�3 ; (�4 [] �1) 4� �3 ; (�1 [] �4) 6� �3 ; (�1 ; ε [] �1 + 3) 17� �3 ; �1 ; (ε [] �3). So, we see thatTF � �3 ; �1 ; (ε [] �3), which corresponds directly to the graph of Fig. 9.

6. Comparing χ and χσ

In this section, we compare χ and χσ. The main difference is that the formal semantics of χσ is defined directly,whereas the formal semantics of χ is described by a translation into χσ. The main part of this translation is givenin Table 12, which is discussed below. In fact χ can be seen as a dialect of χσ with some syntactic macros whichcan all be assembled in χσ.

In addition, χσ’s language constructs are more orthogonal than χ’s. For instance, χσ does not make a dis-tinction between processes and systems; everything is a process and the parallel composition operator can bemixed freely with other process operators. Also, recall that χ has four different selection constructs: the selectionstatement, the repetitive selection statement, the selective waiting statement, and the repetitive selective waitingstatement. In contrast, χσ has just one selection construct: the alternative composition operator. The behavioursof the various χ selection statements can be encoded in χσ using the alternative composition operator, the guardoperator and the repetition operator.

Despite these differences, we think the look and feel of the languages are the same. This is confirmed by thefact that there exists a rather straightforward translation between the languages [BoK02a]. Although we cannotgive the complete translation here, we will discuss the translation of χ process statements in more detail.

The simple χ process statements, i.e., skip, x :� e, �e, m ! e, and m ? x, are translated into the syntacticallyequivalent χσ processes. Here, we assume that χ expressions can be translated into χσ expressions. Send andreceive statements are translated into send and receive processes, respectively. Send and receive statements in χdelay until both parties are ready to communicate: urgent communication. However, in χσ send and receiveprocesses can delay even if both parties are ready to communicate: delayable communication. We can enforceurgent communication in χσ by the maximal progress operator.

Table 12 defines the translation of compound χ process statements. Note that Table 12 introduces skip pro-cesses that are not present in the respective χ statements. The reason for this is that guarded command statementsand selective waiting statements in χ make a choice after the guards are evaluated, but before the statementsfollowing the ‘−→’ are executed. So, a choice is made ‘at the “−→” symbol’. In contrast, the alternative com-position of χσ makes a choice by executing an action of one of its alternatives. By translating the ‘−→’ into askip process, the selection of an alternative in χ is translated into an explicit action, τ , in χσ. Here we see therole of τ hinted at at the end of Section 4.4: breaking possible time factorisation. If this action was not includedin the translation, it would be possible to have a χ statement without time factorisation and the associated χσ

translation with time factorisation.

Page 18: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 387

G(out : chan) �(true :→ out ! true ; skip[]true :→ out ! false ; skip)∗ ; false :→ ε

M(in, out : chan, t1, t2 : int) �|[ x : bool → ⊥ : λs| (true :→ in ? x ; skip

; (x :→ skip ; �t1 [] ¬x :→ skip ; �t2); out ! x)∗ ; false :→ ε

]|

E(in : chan) �|[ x : bool → ⊥ : λs| (true :→ in ? x ; skip)∗ ; false :→ ε]|

GME(t1, t2 : int) �π(∂A(|[ ∼gm → ⊥ : ∼me → ⊥ : λs

| G(∼gm) ‖ M(∼gm, ∼me, t1, t2) ‖ E(∼me)]|))

where A � {sa(∼gm, c), ra(∼gm, x) | c ∈ {true, false}}∪ {sa(∼me, c), ra(∼me, x) | c ∈ {true, false}}

Fig. 10. Process description of system GME in χσ .

In the repetitive guarded command and the repetitive selective waiting, the body is repeated as long as atleast one of the guards is true. If none of the guards is true, the repetition terminates successfully. To capture thisbehaviour, the translation is a sequential composition of a repetition process and an ‘exit’ process. The repetitionprocess contains the translation of the body of the loop, which is the translation of a guarded command or aselective waiting statement. The exit process contains an empty process guarded by the negation of the disjunctionof the guards of the alternatives.

To illustrate the translation from χ into χσ, Fig. 10 shows the χσ version of the GME system described inSection 2. With respect to this example, we make the following remarks. In χσ, concrete channels are denoted byidentifiers prefixed with the ‘∼’ symbol. So, ∼gm and ∼me are concrete channels. Further, an infinite repetitionis constructed using the construction (. . . )∗ ; false :→ ε, with the body substituted at the dots. This is accordingto the translation, because the guards of the χ alternatives are not present and therefore, by convention, assumedto be true. This construction can be seen in the specifications of G, M and E. The false :→ ε ensures thesequential composition process cannot terminate. To prevent the occurrence of a send action without a matchingreceive action (and vice versa), the encapsulation operator ‘∂A’ is used (as in process GME). Finally, maximalprogress needs to be specified explicitly, using the ‘π’ operator (as in process GME).

7. Conclusions

This paper discusses the redesign of the systems engineering language χ, which resulted in a new version called χσ.The reason for this redesign was the lack of analysis techniques in χ based on rigorous, mathematical reasoning.The need for such techniques arose from particular real-life case studies. Although largely successful, these casestudies showed that in some situations simulation-based analysis cannot provide sufficiently reliable results.Therefore, the main objective of redesigning χ was to enable mathematical reasoning.

As with any design activity, there were conflicting requirements. For instance, on the one hand we would liketo maintain χ’ s look and feel as much as possible. On the other hand, we would like to use standard operatorsknown from process algebras. This resulted in χσ having more or less standard process algebra operators whichare expressed in χ syntax.

The time model of χσ differs slightly from that of most timed process algebras. That is, it does have timefactorisation (or time determinacy) and a maximal progress operator, but it does not have time additivity. Due tothe absence of time additivity, we were able to formulate the time confluence lemma. Based on this lemma, tran-sition systems of (translated) χ processes with uncountably many delay transitions can be reduced to transitionsystems with at most one delay transition per state.

Another way in which χσ differs from many process algebras is its data model. Like χ, χσ has an imperativeprogramming style. Programming variables can be introduced by the state operator. This operator keeps track ofthe values associated with variables. Besides variables, the state operator also administers the values of commu-nication channels. Furthermore, since state operators can be nested, variables and channels adhere to commonscoping rules.

Page 19: Redesign of a Systems Engineering Language: Formalisation of ?

388 V. Bos and J. J. T. Kleijn

The redesign of χ has been successful, since both the operational semantics and the process laws providea solid framework that supports mathematical reasoning. Although the examples we gave show a little of howto reason formally about systems specified in χσ, they are too small to make claims about effectiveness of χσ

with respect to real production systems. However, we can make this claim based on several larger case studieswith χσ that have been performed. These case studies are described in [BoK02a]. In one particular case study,which is also described in [BoK02b], we analysed a controller of a batch-oriented coating system. The goal of thecontroller was to make batches as large as possible while at the same time refresh the coating chemicals at certainbounded time intervals. After writing the specification and implementation in χσ, we computed their state spacesusing the χσ tools and we used existing model checker tools to show that these state spaces are equivalent. Inaddition to mathematical reasoning with χσ, these case studies also showed that this reasoning can be supportedeffectively by tools.

In addition to more case studies, future work could focus on improving the formal framework and tool devel-opment. By improving the formal framework, we mean both simplifications of and extensions to the currentformal semantics. One possible simplification could be the removal of state stacks. In [BaB02], a process algebrawith programming language constructs like assignments and local variables is described without the need forstacks. It looks like this approach could easily be applied to χσ. An extension which is currently under devel-opment is the inclusion of differential equations in the formalism. This enables specification of hybrid systems.Some early results of this research are described in [SBM03].

References

[AFV01] Aceto, L., Fokkink, W. J. and Verhoef, C.: Structural operational semantics. In Bergstra et al. [BPS01], chapter 3, pages 197–292.[AlN98] Alberts, W. T. M. and Naumoski, G.: A Discrete-Event Simulator for Systems Engineering. PhD thesis, Technische Universiteit

Eindhoven, 1998.[Are96] Arends, N. W. A.: A Systems Engineering Specification Formalism. PhD thesis, Technische Universiteit Eindhoven, 1996.[Bas96] Basten, T.: Branching bisimilarity is an equivalence indeed! Information Processing Letters, 58(3):141–147, 1996.[BaB88] Baeten, J. C. M. and Bergstra, J. A.: Global renaming operators in concrete process algebra. Information and Computation,

78(3):205–245, 1988.[BaB91] Baeten, J. C. M. and Bergstra, J. A.: Recursive process definitions with the state operator. Theoretical Computer Science,

82(2):285–302, 1991.[BaB96] Baeten, J. C. M. and Bergstra, J. A.: Discrete time process algebra. Formal Aspects of Computing, 8(2):188–208, 1996.[BaB02] Baeten, J. C. M. and Bos, V.: Formalizing programming variables in process algebra. TUCS Technical Report 493, Turku Centre

for Computer Science, December 2002.[BoD93] Borger, E. and Durdanovic, I.: Correctness of compiling occam to transputer code. Computer Journal, 36(5), 1993.[BHR02] van Beek, D. A., van den Ham, A. and Rooda, J. E.: Modelling and control of process industry batch production systems. In

Proceedings of the 2002 IFAC World Congress, Barcelona, 2002. To appear.[BJM97] Bouhoula, A., Jouannaud, J.-P. and Meseguer, J.: Specification and proof in membership equational logic. In M. Bidoit and

M. Dauchet, editors, Proceedings TAPSOFT’97, volume 1214 of Lecture Notes in Computer Science, pages 67–92, Springer1997.

[BoK02a] Bos, V. and Kleijn, J. J. T.: Formal Specification and Analysis of Industrial Systems. PhD thesis, Technische Universiteit Eindho-ven, March 2002.

[BoK02b] Bos, V. and Kleijn, J. J. T.: Formal specification and analysis of production systems. International Journal of Production Research,40(15):3879–3894, 2002.

[BoK02c] Bos, V. and Kleijn, J. J. T.: Redesign of a systems engineering language: formalisation of χ. In G. Luettgen, F. Maraninchiand M. Mendler, editors, Proceedings of the ETAPS 2002 Satellite Workshop: Semantic Foundations of Engineering Languages(SFEDL’02), pages 100–118, April 2002.

[Bla96] Blanco, J. O.: The State Operator in Process Algebra. PhD thesis, Technische Universiteit Eindhoven, 1996.[BaM01] Baeten, J. C. M. and Middelburg, C. A.: Process algebra with timing: real time and discrete time. In Bergstra et al. [BPS01],

chapter 10, pages 627–684.[BPS01] Bergstra, J. A., Ponse, A. and Smolka, S. A., editors.: Handbook of process Algebra. Elsevier Science, 2001.[BeR00] van Beek, D. A. and Rooda, J. E.: Languages and applications in hybrid modelling and simulation: Positioning of χ. Control

Engineering Practice, 8(1):81–91, 2000.[Bri88] Brinksma, E.: On The Design of Extended LOTOS, a Specification Language for Open Distributed Systems. PhD thesis, Uni-

versity of Twente, November 1988.[BaW90] Baeten, J. C. M. and Weijland, W. P.: Process Algebra. Number 18 in Cambridge Tracts in Theoretical Computer Science.

Cambridge University Press, 1990.[BaZ82] de Bakker, J. W. and Zucker, J. I.: Processes and the denotational semantics of concurrency. Information and Control, 54(1/2):

70–120, 1982.[Cam00] van Campen, E. J. J.: Design of a Multi-Process Multi-Product Wafer Fab. PhD thesis, Technische Universiteit Eindhoven, 2000.[CEW58] Copi, I. M., Elgot, C. C. and Wright, J. B.: Realization of events by logical nets. Journal of the ACM, 5:181–196, 1958.[Dij76] Dijkstra, E. W.: A Discipline of Programming. Prentice-Hall Series in Automatic Computation. Prentice-Hall, 1976.[Fab99] Fabian, G.: A Language and Simulator for Hybrid Systems. PhD thesis, Technische Universiteit Eindhoven, 1999.

Page 20: Redesign of a Systems Engineering Language: Formalisation of ?

Redesign of a Systems Engineering Language 389

[Fey00] Fey, J. J. H.: Design of a Fruit Juice Blending and Packaging Plant. PhD thesis, Technische Universiteit Eindhoven, 2000.[Gla94] van Glabbeek, R. J.: What is branching time and why to use it? In The Concurrency Column, Bulletin of the EATCS, 53, pages

190–198, 1994.[GLW98] Groote, J. F., Luttik, B. and van Wamel, J., editors.: Third International Workshop on Formal Methods for Industrial Critical

Systems, CWI Amsterdam, The Netherlands, May 1998.[Gov97] Govaarts, J. A.: Efficiency in a lean assembly line: a case study at NedCar Born. Master’s thesis, Stan Ackermans Institute,

Eindhoven, October 1997.[GlW96] van Glabbeek, R. J. and Weijland, W. P.: Branching time and abstraction in bisimulation semantics. Journal of the ACM,

43(3):555–600, 1996.[HoJ98] Hoare, C. A. R. and Jifeng, H.: Unifying Theories of Programming. Prentice-Hall Series in Computer Science. Prentice-Hall,

1998.[Hoa85] Hoare, C. A. R.: Communicating Sequential Processes. Prentice-Hall, 1985.[HWR98] Haagh, P. A. M., Wilkens, A. U., Rulkens, H. J. A., van Campen, E. J. J. and Rooda, J. E.: Application of a layout design

method to the dielectric decomposition area in a 300 mm wafer fab. In Proceedings of the Seventh International Symposium onSemiconductor Manufacturing, pages 69–72, Tokyo, Japan, October 1998.

[JoG88] Jones, G. and Goldsmith, M.: Programming in occam 2. Prentice-Hall, 1988.[JGL95] Jeffrey, A. S. A., Garavel, H., Leduc, G., Pecheur, C. and Sighireanu, M.: Towards a proposal for datatypes in e-lotos. In Revised

Working Draft on Enhancements to LOTOS (v2), 1995. ISO/IEC JTC1/SC21/WG7 N1053, Annex A.[JGL97] Enhancements to LOTOS, final committee draft on enhancements to LOTOS, November 1997. Source: ISO/IEC

JTC1/SC21/WH7. Project: WI 1.21.20.2.3. Available from http://lotos.site.uottawa.ca/elotos/.[Kle56] Kleene, S. C.: Representation of events in nerve nets and finite automata. In C. E. Shannon and J. McCarthy, editors, Automata

Studies, pages 3–42, Princeton University Press, 1956.[KLL96] Katoen, J-P., Latella, D., Langerak, R., Brinksma, E. and Bolognesi, T.: A consistent causality based view on a timed process

algebra. In Third AMAST Workshop on Real-Time Systems, March 1996.[Klu93] Klusener, A. S.: Models and Axioms for a Fragment of Real Time Process Algebra. PhD thesis, Technische Universiteit Eindho-

ven, 1993.[Mes98] Meseguer, J.: Membership algebra as a logical framework for equational specification. In F. Parisi-Presicce, editor, Proceedings

of WADT’97, volume 1376 of Lecture Notes in Computer Science, pages 18–61, Springer, 1998.[MGR00] van de Mortel-Fronczak, J. M., Gorter, R. J. A. and Rooda, J. E.: A case study in simulation-based system specification design.

In Proceedings of ESM’2000, pages, 232–238, Ghent, Belgium, May 2000.[MoR95] van de Mortel-Fronczak, J.M. and Rooda, J. E.: Application of concurrent programming to specification of industrial systems.

In Proceedings of INCOM’95, pages 421–426, Beijing, China, October 1995.[MoR97] van de Mortel-Fronczak, J. M. and Rooda, J. E.: Heterarchical control systems for production cells: a case study. In Proceedings

of MIM’97, pages 243–248, Vienna, Austria, February 1997.[MRN95] van de Mortel-Fronczak, J. M., Rooda, J. E. and van den Nieuwelaar, N. J. M.: Specification of a flexible manufacturing system

using concurrent programming. International Journal of Concurrent Engineering: Research & Applications, 3(3):187–194, 1995.[MSR99] van de Mortel-Fronczak, J. M., Schmitz, J. P. M. and Rooda, J. E.: Experimental comparison of control architectures. In K.

Mertins, O. Krause and B. Schallock, editors, Proceedings of APMS’99, pages 530–537, Berlin, Germany, September 1999.[Mid01] Middelburg, C. A.: Variable binding operators in transition system specifications. Journal of Logic and Algebraic Programming,

47(1):15–45, 2001.[Mil80] Milner, R.: A calculus of communicating systems. In Lecture Notes in Computer Science, volume 92. Springer, 1980.[Mil83] Milner, R.: Calculi for synchrony and asynchrony. Theoretical Computer Science, 25(3):267–310, 1983.[MPW92] Milner, R., Parrow, J. and Walker, D.: A calculus of mobile processes. Information and Computation, 100:1–77, 1992.[NiS94] Nicollin, X. and Sifakis, J.: The algebra of timed processes ATP: theory and application. Information and Computation,

114:131–178, 1994.[Par81] Park, D. M. R.: Concurrency and automata on infinite sequences. In Proceedings 5th GI (Gesellschaft fur Informatik) Confer-

ence, volume 104 of Lecture Notes in Computer Science, pages 167–183, Karlsruhe, Germany, 1981.[Par01] Parrow, J.: An introduction to the π-calculus. In Bergstra et al. [BPS01], chapter 8, pages 479–543.[Plo81] Plotkin, G. D.: A structural approach to operational semantics. Technical Report DAIMI FN-19, Arhus University, Computer

Science Department, 1981.[PoM88] Pountain, D. and May, D.: A Tutorial Introduction to OCCAM Programming. INMOS BSP Professional Books, 1988.[RCH98] Rulkens, H. J. A., van Campen, E. J. J., van Herk, J. and Rooda, J. E.: Batch size optimization of a furnace and pre-clean area by

using dynamic simulations. In Proceedings of the Advanced Semiconductor Manufacturing Conference, ASMC, pages 439–444,Boston, September 1998.

[RoH86] Roscoe, A. W. and Hoare, C. A. R.: The laws of occam programming. Technical Report PRG-53, Programming ResearchGroup, Oxford, 1986.

[Ros98] Roscoe, A. W.: The Theory and Practice of Concurrency. Prentice-Hall Series in Computer Science. Prentice Hall, 1998.[Rus95] Rushby, J.: Formal methods and their role in the certification of critical systems. Technical Report CSL-95-01, SRI International,

Menlo Park, CA, March 1995.[SBM03] Schiffelers, R. R. H., van Beek, D. A., Man, K. L., Reniers, M. A. and Rooda, J. E.: A hybrid language for modeling, simulation

and verification. In IFAC Conference on Analysis and Design of Hybrid Systems, Saint-Malo Brittany, France, 2003. To appear.[Yi91] Yi, W.: CCS+time = an interleaving model for real time systems. In J. Leach Albert, B. Monien and M. Rodrıguez Artalejo, edi-

tors, Automata, Languages, and Programming (ICALP91), volume 510 of Lecture Notes in Computer Science, pages 217–228,Madrid, Spain, July 1991.

Received October 2002Accepted in revised form June 2003