ArticlePDF Available

Executable rewriting logic semantics of Orc and formal analysis of Orc programs

April 2015
Journal of Logical and Algebraic Methods in Programming 84(4)

DOI:10.1016/j.jlamp.2015.03.003

License
CC BY-NC-ND 4.0

Authors:

King Fahd University of Petroleum and Minerals

The Orc calculus is a simple, yet powerful theory of concurrent computations with great versatility and practical applicability to a very wide range of applications, as it has been amply demonstrated by the Orc language, which extends the Orc calculus with powerful programming constructs that can be desugared into the underlying formal calculus. This means that for: (i) theoretical, (ii) program verification, and (iii) language implementation reasons, the formal semantics of Orc is of great importance. Furthermore, having a semantics of Orc that is executable is essential to provide: (i) a formally-defined interpreter against which language implementations can be validated, and (ii) a (semi-)automatic way of generating a wide range of semantics-based program verification tools, including model checkers and theorem provers.

Parameter subsort structure

…

The subsort structure of Orc expressions

…

Rewrite rules in R sos Orc for basic expressions

…

Rewrite rules in R sos Orc for the combinators

…

Schematic diagrams of the equational propagation of information in an expression tree

…

Figures - uploaded by Musab Alturki

Content may be subject to copyright.

Content uploaded by Musab Alturki

Content may be subject to copyright.

Available via license: CC BY-NC-ND 4.0

Content may be subject to copyright.

Accepted Manuscript

Executable rewriting logic semantics of Orc and formal analysis of

Orc programs

Musab A. AlTurki, José Meseguer

PII: S2352-2208(15)00033-4

DOI:

http://dx.doi.org/10.1016/j.jlamp.2015.03.003

Reference: JLAMP 42

To appear in: Journal of Logical and Algebraic Methods in Programming

Received date: 8 November 2013

Revised date: 29 January 2015

Accepted date: 26 March 2015

Please cite this article in press as: M.A. AlTurki, J. Meseguer, Executable rewriting logic

semantics of Orc and formal analysis of Orc programs, Journal of Logical and Algebraic

Methods in Programming (2015), http://dx.doi.org/10.1016/j.jlamp.2015.03.003

This is a PDF ﬁle of an unedited manuscript that has been accepted for publication. As a

service to our customers we are providing this early version of the manuscript. The manuscript

will undergo copyediting, typesetting, and review of the resulting proof before it is published

in its ﬁnal form. Please note that during the production process errors may be discovered which

could affect the content, and all legal disclaimers that apply to the journal pertain.

Executable Rewriting Logic Semantics of Orc and

Formal Analysis of Orc Programs

Musab A. AlTurki

a,1,∗

, Jos´e Meseguer

b,2

King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia

The University of Illinois at Urbana-Champaign, Urbana IL 61801, USA

Abstract

The Orc calculus is a simple, yet p owerful theory of concurrent computations

with great versatility and practical applicability to a very wide range of applica-

tions, as it has been amply demonstrated by the Orc language, which extends the

Orc calculus with powerful programming constructs that can be desugared into

the underlying formal calculus. This means that for: (i) theoretical, (ii) program

veriﬁcation, and (iii) language implementation reasons, the formal semantics of

Orc is of great importance. Furthermore, having a semantics of Orc that is ex-

ecutable is essential to provide: (i) a formally-deﬁned interpreter against which

language implementations can be validated, and (ii) a (semi-)automatic way of

generating a wide range of semantics-based program veriﬁcation tools, including

model checkers and theorem provers.

This work proposes a formal executable semantics for Orc in rewriting logic,

to support formal veriﬁcation of Orc programs and to make possible semantics-

based correct-by-construction Orc implementations. While being a very simple

calculus, Orc has a quite subtle semantics, so that fully capturing all its seman-

tic aspects is highly nontrivial. The two main sources of subtlety are: (i) its

real-time semantics, and (ii) the priority of internal computations within an

Orc expression over external computations that process responses from exter-

nal sites. In this paper, we show a simple and elegant way of handling these

two sources of subtlety in rewriting logic using an order-sorted type system

supporting subtypes and subtype polymorphism, and “tick” rewrite rules for

capturing time. Moreover, our rewriting semantics incorporates useful seman-

tic equivalences between Orc programs as equations and equational attributes,

making the semantics both more abstract and more eﬃcient. The semantics of

Orc is given in two diﬀerent styles: (i) an SOS style, which is directly based

on the original SOS of Orc, whose correctness follows immediately by construc-

∗

Corresponding author

Email addresses: musab@kfupm.edu.sa (Musab A. AlTurki), meseguer@cs.illinois.edu

(Jos´e Meseguer)

Supported by KFUPM Grant JF121005.

Supported by AFOSR Contract FA8750-11-2-0084 and NSF Grants CCF 09-05584 and

CNS 13-19109.

Preprint submitted to Journal of Logic and Algebraic Programming April 2, 2015

tion, and (ii) a reduction s emantics, which is much more eﬃciently executable

and analyzable, as shown through several experiments, and whose correctness

is proved using a strong bisimulation theorem. The paper also presents MOrc,

a simulator and model checking tool based on the rewriting semantics of Orc

and Real-Time Maude. MOrc facilitates formal veriﬁcation of Orc programs,

and allows for user-deﬁned state predicates and LTL formulas, with no need for

any prior knowledge of Maude or its rewriting logic foundations.

Keywords: Rewriting logic, Orc, executable semantics, Maude, formal

analysis, service orchestration, MOrc

1. Introduction

The Orc concurrency calculus [59, 61, 82] is very remarkable in that it com-

bines great simplicity and mathematical elegance with great versatility and prac-

tical applicability to a very wide range of concurrent programming [61, 42], web-

based programming [61], business processes [22], and distributed cyber-physical

system applications. Indeed, the great elegance and naturalness with which ap-

plications in all these areas can be programmed has been amply demonstrated

by the Orc language [41, 60], which extends the Orc calculus with powerful

programming constructs. The Orc language’s relationship to the Orc calculus

can b e viewed as the analogue of the relationship between a purely functional

language and the lambda calculus: in both cases, all the language’s constructs

can be desugared into the underlying formal calculus, which is crucial for both

ease of reasoning and ease of developing correct implementations.

All this means that for: (i) theoretical, (ii) program veriﬁcation, and (iii)

language implementation reasons, the formal semantics of Orc is of great im-

portance. Furthermore, there is by now overwhelming evidence in various ap-

proaches to formal semantics that the by far most useful semantic deﬁnitions

are executable formal semantic deﬁnitions, for two main reasons. First, many

complex languages do not have a formal semantics at all, but have at best

lengthy and ambiguous standards in natural language and various compilers,

often exhibiting diﬀerent behaviors. In such a case, a “paper semantics” is of

very limited use, since the language’s complexity makes it in practice virtually

impossible to validate whether such a semantics (which cannot be compared to

any other one by the language’s lack of a formal semantics) really captures the

intended, informal semantics described in its standard. By contrast, an exe-

cutable formal semantics automatically provides a formally-deﬁned interpreter,

so that the semantic deﬁnition can be validated against the language’s standard

and against other mature language implementations to ensure that the informal

semantics has been correctly formalized. Indeed, this is exactly the approach

advocated in the rewriting logic semantics project [51, 56, 73, 57], where large

languages have been given an executable semantics in rewriting logic, including

Java and the JVM [27, 28], Scheme [49], Verilog [50], and, more recently, C [26].

The case of C is a good illustration of why an eﬃcient executable semantics is

essential, since the work in [26] is the ﬁrst formal semantics ever given of the

entire C language, a semantics which has been validated against the entire gnu

C compiler torture suite and has uncovered bugs in several C to ols.

A second reason why an executable formal semantics is enormously more

useful than a “paper semantics” is that a wide range of program veriﬁcation

tools, including model checkers, [51, 56, 57], theorem provers [57, 70] and static

analysis tools [56, 57] can be based directly on such an executable formal se-

mantics in the sense of both being generated from the executable semantics and

embodying such a semantics. This, in turn, has two main advantages: (i) us-

ing languages such as Maude [21] many of these program analysis tools can be

generated automatically and for free from the semantic deﬁnition: for example,

the JavaFAN model checkers for Java and the JVM are automatically generated

that way and compare favorably with well-known Java model checkers [27, 28],

and (ii) there is no gap between the formal semantics and the program analysis

tools, since the tools are based on the program semantics. This is by no means

the case for most formal tools, which embody such a semantics only implicitly

and sometimes erroneously. For example, the work in [26] has uncovered sev-

eral semantic errors in well-known theorem provers for C, and the work in [50]

uncovered similar problems in mature Verilog tools.

The goal of this work is to propose a formal executable semantics for Orc in

rewriting logic [52], and to exploit such an executable semantics in the above-

mentioned ways to support formal veriﬁcation of Orc programs and to make

possible semantics-based correct-by-construction Orc implementations. Com-

pared with a language such as C, the task is in several ways much simpler, since

Orc is a much simpler language than C, and has from the very beginning been

designed as a formal calculus with an SOS semantics [61]. However, Orc, while

being a very simple calculus, has a quite subtle semantics, so that fully captur-

ing all its semantic aspects is highly nontrivial. In fact, it is not at all clear

that this can be done in just any semantic framework. The sources of subtlety

include the following:

1. Real Time. Orc is a real-time calculus, where the passage of time is

essential and where sophisticated real-time concurrent applications can

be develop ed. Any semantic framework not supporting such a real-time

semantics will be useless.

2. Internal vs. External Computation. An Orc expression evaluates

its constructs internally; but the evaluation may involve making calls to

external sites and eventually receiving answers from such site calls, so

that the internal evaluation can proceed. For example, an Orc expression

may invoke both the CNN and BBC web sites with a given timeout, and

then send zero, one, or two emails to a given user with the respective

contents of the web sites which responded before the speciﬁed timeout.

To avoid undesirable behaviors, internal computations should always be

given priority over external ones. In [61], this is modeled by having two

transition relations in Orc’s SOS semantics, ֒→

and ֒→

We show in Section 5 that these two sources of subtlety can be handled in a

quite simple and elegant way by our rewriting logic semantics. Sp eciﬁcally, we

show that using an order-sorted type structure [32], supporting subtypes and

subtype polymorphism, completely solves subtlety (2), so that a single transition

relation enforces the desired priority of internal over external computation. The

solution of subtlety (1) is even simpler: the addition of a single additional “tick”

rule, modeling time elapse, to the semantic rules describing Orc’s instantaneous

computations and the proper deﬁnition of time execution semantics and time

delays are all that is needed to obtain a real-time semantics.

Another imp ortant feature of Orc’s rewriting logic semantics is that it in-

corporates eleven useful semantic equivalences between Orc programs listed in

Section 3.4; this makes the semantics both more abstract and more eﬃcient. The

point is that the rewriting semantics of Orc is a rewrite theory (Σ

Orc

∪

Orc

), where R

Orc

are the transtion rules, and (Σ

Orc

∪ B

Orc

)isan

equational theory capturing the eleven semantic equivalences as ﬁve equational

axioms (“structural equivalences”) B

Orc

, and six other equations E

Orc

,which

are conﬂuent and terminating modulo B

Orc

. Furthermore, all these semantic

equations and rewrite rules satisfy all the required executability properties and

are indeed executable in Maude [21] and its Real-Time Maude extension [64],

giving rise to an Orc interpreter.

An executable formal semantics of Orc is useful b oth for formal analysis

purposes, such as model checking Orc programs, and for deriving a correct-by-

construction Orc implementation. However, for both these purposes executabil-

ity of the rewrite theory expressing Orc’s semantic deﬁnition is not enough:

eﬃcient executability is needed. That is, both a formal tool like an Orc model

checker and a semantics-based Orc implementation, such as the one presented

in [6], should have acceptable performance. Since our Orc rewriting logic se-

mantics closely follows Orc’s SOS semantics, the resulting rewrite theory, though

executable and capable even of model checking nontrivial Orc programs, is how-

ever ineﬃcient. The main reason is the chosen SOS format: since in small step

SOS each inference rule may have one or more preconditions that are them-

selves transitions, the corresponding rewrite rule modeling such an inference

rule must be conditional. Execution of conditional rewrite rules is intrinsically

ineﬃcient, both because of the recursive nature of the conditions, which may

invoke other rules and conditions, and because of the non-deterministic nature

of the transitions, which requires breadth ﬁrst search to satisfy conditions.

Fortunately, as explained in [73], rewriting logic semantics can faithfully

model many diﬀerent deﬁnitional styles, so that a much more eﬃcient semantic

deﬁnition may be attained using a diﬀerent style. This suggests using a reduc-

tion semantics style, where virtually all semantic rules will be unconditional.

This is exactly the task undertaken in Section 6, where a reduction semantics for

both Orc’s synchronous SOS semantics and its real-time semantics by adding a

single additional “tick” rule are developed. This of course raises the issue of the

equivalence between the original small-step styled deﬁnition and new reduction

semantics. This we prove in Section 6.5, in the form of a strong bisimulation the-

orem between the two semantic deﬁnitions. The reduction semantics is indeed

much more eﬃcient than the small step style one, as shown by the performance

comparisons when executed in Maude, which are presented in Section 6.6.

As already mentioned, and as substantiated in Section 6.6, one key use

of Orc’s reduction style semantics is to obtain an eﬃcient model checker for

Orc. Since Real-Time Maude directly supports execution and model checking

of invariants using the trewrite and search commands, and also LTL model

checking, the Real-Time Maude implementation of the reduction style semantics

already provides both an Orc simulator and an Orc model checker for free.

However, an Orc user needs to have some familiarity with the underlying Real-

Time Maude system to model check Orc programs. This is because, at the

very least, the state predicates to be used in invariants and in LTL formulas

need to be deﬁned. To make the Orc model checker more easily usable, the

MOrc tool described in Section 7 has been developed. MOrc is a web-based

tool that allows the user to enter Orc programs to it, and also to deﬁne both

state predicates and LTL formulas in an Orc-based manner, with no need for

any prior knowledge of the underlying Real-Time Maude or its rewriting logic

foundations. A user can then either execute an Orc program in MOrc or

request from MOrc to model check any LTL formula or invariant. Internally,

of course, what the MOrc tool does is to translate the Orc program and the

given formula into their Real-Time Maude representation in the reduction style

semantics, and then report back to the user the result of an execution or of a

model checking command.

We ﬁnish the paper with a discussion of related work in Section 8, and with

some concluding remarks in Section 9.

Compared with our previous work in [3, 5], the work presented here pro-

vides new results and substantial improvements and extensions. Speciﬁcally,

since the initial versions in [3, 5], both the SOS-based and the reduction rewrit-

ing semantics of Orc have been thoroughly reﬁned and extended to achieve a

more complete, elegant, and eﬃciently executable speciﬁcation. In particular,

using order-sorted structures for Orc values and order-sorted declarations for

Orc expressions and action labels, and using membership equations enables a

simpler and more elegant speciﬁcation of the synchronous semantics of Orc that

can be executed and analyzed more eﬃciently than with just the many-sorted

speciﬁcations used before. It also enables a concise representation of the new

otherwise Orc combinator and its semantics. Furthermore, unlike previous ver-

sions, which were restricted to modeling discrete time domains, the semantics is

now capable of handling dense time domains, using ideas from real-time rewrite

theories [67] and Real-Time Maude [64], with implementations in both (Core)

Maude and Real-Time Maude. Moreover, the rewriting semantics speciﬁcation

we present here incorporates as equational properties some fundamental alge-

braic laws about Orc expressions, making the semantics both more abstract and

eﬃcient. We also provide detailed proofs showing that both rewriting semantics

speciﬁcations satisfy some desirable executability properties. As a side-eﬀect

to these improvements to the rewriting semantics speciﬁcation, we present a

set of SOS rules deﬁning a self-contained transition relation specifying the syn-

chronous semantics of Orc, in which no external rule application constraints

are necessary, by exploiting the connection between order-sorted theories and

context-free grammars. Finally, we describe a new web-based tool, MOrc,

based on the reduction rewriting semantics speciﬁcation of Orc, which enables

expressive formal analysis of Orc programs, while requiring minimal knowledge

of the internal Maude representation.

2. Preliminaries on Rewriting Logic and Maude

Rewriting logic [52] is a general semantic framework that is well suited for

giving formal deﬁnitions of programming languages and systems, including their

concurrent and real-time features (see [56, 73, 57, 67] and references there). The

unit of sp eciﬁcation in rewriting logic is a rewrite theory, which gives a formal

description of a concurrent system including its static state structure and its

dynamic behavior. Assuming that t, u, v and w (and their decorated variants)

are terms and s is a sort, a rewrite theory, in its most general form, is a tuple

R =(Σ,E ∪ B, R, φ), consisting of: (i) a theory (Σ,E ∪ B)inmembership

equational logic (MEL) [53], where Σ is a MEL signature having a set of kinds,

a family of sets of operators, and a kind-indexed family of disjoint sets of sorts,

E is a set of Σ-sentences, which are universally quantiﬁed Horn clauses with

atoms that are either equations (t = t

′

) or memberships (t : s), and B is a set of

equational axioms, such as commutativity, and/or associativity and/or identity

axioms for some operators in Σ; (ii) a set R of universally quantiﬁed labeled

conditional rewrite rules of the form:

(∀X) r : t → t

′



= u

′

∧



: s

∧



→ w

′

(⋆)

where r is a label; and (iii) a function φ :Σ→P(N) t hat assigns to each

operator symbol f in Σ of arity n>0 a set of positive integers φ(f) ⊆{1,...,n}

representing frozen argument positions where rewrites are forbidden.

While the MEL theory (Σ,E ∪ B) speciﬁes the user-deﬁned syntax and

equational axioms, which deﬁne the system states as elements of the initial

algebra associated to (Σ,E∪ B), a rule r : t → t

′

if C in R gives a general pattern

for a possible concurrent transition in its state (modulo the restrictions imposed

by φ), with the intuition that an instance θ(t)oft (with θ a substitution)

may rewrite to θ(t

′

) in the state of the system whenever the condition θ(C)is

satisﬁed. Such rewrites are deduced according to the inference rules of rewriting

logic, which are described in detail in [18]. Using these inference rules, a rewrite

theory R proves a statement of the form (∀X) t → t

′

, meaning that, in R,any

instance of the state term t can reach the corresponding instance of the state

term t

′

in a ﬁnite number of, possibly concurrent, steps. A detailed discussion

of rewriting logic as a uniﬁed model of concurrency and its inference system can

be found in [52] (see also the survey [54]). [18] gives a precise account of the

most general form of rewrite theories and their models.

2.1. Real-Time Rewrite Theories

A real-time rewrite theory [67] extends an ordinary rewrite theory with sup-

port for modeling real-time behaviors of systems. In particular, in a real-

time rewrite theory R

=(Σ

∪ B

,φ): (i) the equational theory

(Σ

∪B

) contains a sort for Time specifying the time domain, which can be

either dense or discrete, and declares a system-wide operator that encapsulates

the whole system being modeled into a special sort GlobalSystem for managing

time elapse, and (ii) the set of rewrite rules R

is the disjoint union of two sets

and R

,whereR

consists of instantaneous rewrite rules having the form (⋆)

above and representing instantaneous transitions in the system, and R

consists

of tick rewrite rules modeling system transitions that take a non-zero amount

of time to complete. A tick rewrite rule has the following form

r : {t}

−→ { t

′

} if C

where τ is a term of sort Time representing the duration of time required to com-

plete the transition speciﬁed by the rule. The global operator {

} encapsulates

the whole system into the sort GlobalSystem to ensure the correct propagation

of the eﬀects of time elapse to every part of the system. A detailed discussion of

real-time rewrite theories and their semantics, including a detailed explanation

of how they can be reduced to ordinary rewrite theories by explicitly introducing

a global clock as part of the global state, can be found in [67, 64].

2.2. Maude and Real-Time Maude

Maude [21] is a high-performance implementation of rewriting logic and its

underlying MEL sublogic. A basic unit of speciﬁcation in Maude can be ei-

ther a functional module, corresponding to a MEL theory E =(Σ,E ∪ B), or

a system module, deﬁning a rewrite theory R =(Σ,E ∪ B, R,φ). A functional

module may contain module inclusion assertions, sort and subsort declarations,

operator symbols declarations (optionally with some equational attributes, in-

cluding equational axioms B such as associativity, commutativity and/or iden-

tity), and conditional equations and membership axioms. Admissible functional

modules, which are modules that satisfy some reasonable executability require-

ments, including ground conﬂuence and termination (modulo the axioms B)and

sort-decreasingness of the equations, can be executed in Maude by equational

simpliﬁcation modulo axioms using the equations E as simpliﬁcation rules from

left to right and Maude’s matching algorithms modulo B to simplify a term to its

canonical form with a least sort. Equational simpliﬁcation modulo axioms of an

admissible functional module yields an operational semantics, deﬁned by the al-

gebra of canonical forms Can

Σ/E,B

, for its corresponding theory that coincides

with its mathematical, initial algebra semantics, given by the initial algebra

Σ/E∪B

(see Sections 4.6–4.8 in [21] and cited references there). Simpliﬁcation

modulo axioms B can be performed by the reduce command in Maude.

An admissible system module, which may additionally contain possibly con-

ditional rewrite rules, must satisfy the executability requirements for its equa-

tional part in addition to the ground coherence of the rules R with respect

to the equations in E modulo B, and to admissibility conditions on the rules,

which ensure that all variables in the rules can be instantiated by (incremental)

matching. Such admissible modules can be executed in Maude by rewriting

with rules (abiding by the restrictions imposed by φ) and oriented equations

modulo the axioms B, which in this case corresponds exactly to the mathemat-

ical semantics of R, which rewrites with R modulo the equational theory E ∪ B

(see Section 6.3 in [21] and [18, 80]). Rewriting of system modules can be per-

formed in Maude by means of the rewrite command, which applies a rule-fair

strategy to explore a possible behavior of the system, or the search command,

which explores the entire reachable state space of the system, to ﬁnd states in-

stantiating a given pattern and satisfying a given semantic condition, following

a breadth-ﬁrst strategy. Furthermore, Maude provides a linear temporal logic

(LTL) model checker for verifying safety and liveness properties.

While real-time rewrite theories with deterministic tick rules can be speciﬁed

in Maude and analyzed using its standard analysis tools, a more expressive and

ﬂexible implementation and analysis of such theories, for both discrete and con-

tinuous time domains, is provided by Real-Time Maude (RTM) [66], which is an

extension to Maude written using its reﬂective features. RTM modules provide

the data types, operators, and execution strategies that enable the speciﬁcation

of timed modules with built-in or user-deﬁned time domains. Time tick rewrite

rules are in general non-deterministic, since the amount of time τ by which a sys-

tem may advance its clock may be non-deterministic. Therefore, tick rules are in

general not directly executable, and, for this reason, RTM provides a number of

time sampling strategies, such as the general maximal sampling strategy (which

advances time until the next instant when some instantaneous rewrite rule be-

comes enabled), which can be used to execute timed modules. Furthermore,

RTM comes equipped with a range of formal analysis tools for timed modules,

including timed rewriting (the command trewrite), timed and untimed search

(tsearch and utsearch), and time-bounded and time-unbounded LTL model

checking (the command mc). A complete description of RTM and its formal

analysis features can be found in [66].

3. The Orc Theory

Orc [59, 61] is a timed theory for orchestration of services. It provides an

expressive and elegant programming model for describing timed, concurrent

computations. A site in Orc represents a service, which may range in complex-

ity from a simple function to a complex web search engine, depending on the

orchestration problem. A site may also represent the interaction with a human

being, most commonly within the context of business workﬂows [78]. A site,

when called, may pro duce, or publish,atmostonevalue. Asitemaynotre-

spond to a call, either by design or as a result of a communication problem. For

example, if CNN is a site that returns the news page for a given date d,then

the site call CNN (d) might not respond b ecause of a network failure or it may

choose to remain silent because of an invalid input value d. Site calls are strict,

i.e., they have a call-by-value semantics.

Being a timed theory, diﬀerent site calls in Orc may occur at diﬀerent times.

A site call may be purposefully delayed using the internal site Rtimer(t), which

E ∈ ExpressionName x ∈ Variable w ∈ Value ∪{stop}

Orc program ::=



d ; f

d ∈ Declaration ::= E(x)  f

f, g ∈ Expression ::= 0 | p(p) | E(p)

| f | g | f

>x> g | g <x< f | f ; g

p ∈ Parameter ::= x | w

Figure 1: Syntax of Orc

publishes a signal after t time units. Furthermore, responses from calls to ex-

ternal sites may experience unpredictable delays and communication failures,

which could aﬀect whether and when other site calls are made. Unlike external

sites, however, responses from internal sites, such as Rtimer, are assumed to

have completely predictable timed behaviors; for example, Rtimer(t) will pub-

lish a signal in exactly t time units. Orc also assumes a few more internal sites,

which are needed for eﬀective programming in Orc. They are: (1) the if (b)

site, which publishes a signal if b is true and remains silent otherwise, (2) let(x),

which publishes a tuple of the list of values in x,orthevalueofx itself if |x| =1,

and (3) Clock , which publishes the current time value.

3.1. Syntax of Orc

An Orc expression describes how site calls (and responses) are combined

in order to perform a useful computation. Orc expressions are built up from

site calls using four combinators, which were previously shown in [61, 41] to

be capable of expressing a wide variety of timed, distributed computations suc-

cinctly and elegantly. The abstract syntax of Orc is shown in Figure 1. We

assume a syntactic category Value that contains not only standard Orc values,

such as numeric and boolean values and the signal value, but also site names

as a distinguished sub-category SiteName of values that can be called (i.e.,

SiteName ⊂ Value ). We also assume a special site response value stop,which

may be used to indicate termination of a site call without necessarily publishing

a standard Orc value.

An Orc program consists of an optional list of declarations, giving names

to expressions, followed by an Orc expression to be executed. An expression

can be either: (1) the silent expression (0), which represents a site that never

responds; (2) a parameter or an expression call having an optional list of actual

parameters as arguments; or (3) the composition of two expressions by one of

the following four composition operators:

Symmetric parallel composition, f | g, which models concurrent execu-

tion of independent threads of computation. For example, CNN (d) | BBC (d),

where CNN and BBC are sites, calls b oth sites concurrently and may publish

up to two values, depending on the publication behavior of the individual sites.

Sequential composition, f

>x> g, which executes f , and for each value

w published by f creates a fresh instance of g,withx bound to w, and runs

that instance in parallel with the current evaluation of f >x> g. For example, if

Email(x) is a site that sends an e-mail message with contents x to a ﬁxed address

a, then the expression CNN (d) >x> Email(x) may cause a news page to be sent

to a.IfCNN (d) does not publish a value, Email(x) is never invoked. Similarly,

the expression (CNN (d) | BBC (d)) >x> Email(x) may result in sending zero,

one, or two messages to a.

Asymmetric parallel composition, f <x< g, which executes f and g

concurrently but terminates g once g has published its ﬁrst value, which is then

bound to x in f. For instance, the expression Email(x)

<x< (CNN (d) | BBC (d))

sends at most one message, depending on which site publishes a value ﬁrst. If

neither site publishes a value, the variable x is not bound to a concrete value

and, therefore, the call to Email is never made.

Otherwise composition, f ; g, which attempts to execute f to completion.

If f terminates without ever publishing a value, g is then executed. Otherwise,

if f publishes a value during its execution, g is ignored. For example, suppose

CNN publishes a stop value when called with invalid date values. Then, if d

is a valid date value, the composition CNN (d) ; Email(err

msg) never invokes

Email and may publish the news page from CNN . Otherwise, if d is invalid, an

e-mail is sent and the value published by Email is the value published by the

composition.

A variable x occurs bound in an expression g when g is the right (resp. left)

subexpression of a sequential composition f >x> g (resp. an asymmetric parallel

composition g <x< f). If a variable is not bound in either of the two above

ways, it is said to be free. We use the syntactic sugar f ≫ g (resp. g ≪ f)for

sequential composition (resp. asymmetric parallel composition) when no value

passing from f to g takes place, which corresp onds to x not being a free variable

in g. To minimize use of parentheses, we assume the following precedence order

(from highest to lowest):

≫ , | , ≪ , ; .

3.2. Small Examples

We now list a few example Orc expressions, borrowed from [61]. Many more

examples and larger programs can be found in [61, 39, 22, 42, 60]. The Orc

expression below speciﬁes a timeout t on the call to a site M:

let(x) <x< M() | Rtimer (t).

Upon executing the expression, both sites M and Rtimer are called. If M

publishes a value w before t time units, then w is the value published by the

expression. But if M publishes w in exactly t time unites, then either w or

signal is published. Otherwise, signal is published.

Another example is the standard programming idiom of the two-branch con-

ditional if b then f else g, which can be written in Orc as the expression

if (b) ≫ f | if (¬b) ≫ g. Given the behavior of the internal site if , only one of

the expressions f and g is executed, depending on the truth value of b.

A third example is the following Orc expression declaration, which deﬁnes

an expression that recursively publishes a signal every t time units, indeﬁnitely.

Metronome(t)  let(signal) | Rtimer (t)

≫ Metronome(t).

h fresh

M(v)

Mv,h

֒−→ ?h

(SiteCall)

h?v

֒−→ !v

(SiteRetV)

h?stop

֒−→ 0

(SiteRetN)

֒−→ 0

(Publish)

E(x)  f ∈ D

E(p)

֒−→ [p/x]f

(Def)

֒−→ f



f ; g

֒−→ f



(OtherV)

֒−→ f



f ; g

֒−→ f



; g

(OtherN)

֒−→ f



f | g

֒−→ f



| g

(Sym)

֒−→ f



f >x> g

֒−→ (f



>x> g) | [v/x]g

(Seq1V)

֒−→ f



f >x> g

֒−→ f



>x> g

(Seq1N)

֒−→ f



g <x< f

֒−→ [v/x]g

(Asym1V)

֒−→ f



g <x< f

֒−→ g <x< f



(Asym1N)

֒−→ g



g <x< f

֒−→ g



<x< f

(Asym2)

Figure 2: Instantaneous, asynchronous structural operational semantics of Orc

The expression named Metronome can be used to repeatedly initiate an in-

stance of a task every t time units. For example, the expression Metronome(10)

≫ UpdateLocation() calls on the task of updating the current location of a mo-

bile user every ten time units.

3.3. Operational Semantics of Orc

A structural operational semantics for the instantaneous (untimed) behav-

iors of Orc was originally given by Misra and Cook [61]. Figure 2 lists an

updated set of small-step SOS rules, based on the original SOS speciﬁcation,

that includes rules for the semantics of the otherwise combinator and stop site

responses. The semantics uses two forms of internal expressions to represent

intermediate transitional steps in the execution of an Orc expression, namely

“!v”, which publishes the value v ∈ Value ,and“?h”, with h a handle name,

which is used to uniquely identify an unﬁnished site call.

The SOS semantics speciﬁes the possible behaviors of an Orc expression as a

labeled transition system with four label schemes corresponding to four types of

actions an Orc expression may take: (1) publishing a value, !v, (2) calling a site,

Mv, h,withh a fresh handle name uniquely identifying this site call instance,

(3) making an unobservable transition, τ, which may represent an expression

call or a substitution event, and (4) consuming a site response, h?w,withh the

handle for the corresponding site call and w ∈ Value ∪{stop}. In Figure 2,

n ranges over labels for non-publishing events, namely labels of types (2)–(4),

while l ranges over all labels. In addition to the SOS rules in Figure 2, the SOS

semantics assumes some structural properties of Orc expressions that will be

discussed in Section 3.4.

Two important reﬁnements to the SOS speciﬁcations that are of central rel-

evance to this work were proposed. First, as discussed by Misra and Cook in

[61], the SOS semantics is highly non-deterministic, allowing internal transitions

within an Orc expression (value publishing, site calls, and τ transitions) and the

external interaction with sites in the environment (through site return events)

to be interleaved in any order. This high degree of non-determinism may be

undesirable. For example, in the expression let(x) <x< Rtimer (1) ≫ N() | M (),

which is supposed to give M priority over N,thecalltoM may actually be de-

layed in this semantics, thus defeating the purpose of prioritizing it over the call

to N. In order to rule out such undesirable behaviors, a synchronous semantics

was proposed in [61] by placing further constraints on the application of SOS

semantic rules. The synchronous semantics was arrived at by distinguishing be-

tween internal and external events, and splitting the SOS transition relation ֒→

into two sub-relations ֒→

,and֒→

, and characterizing set-theoretically, the

complementary subsets of expressions (quiescent vs. non-quiescent) to which

they are respectively applied. In previous work [3], we have presented two dif-

ferent approaches, namely, strategy expressions and equational conditions, in

which this splitting into ֒→

and ֒→

can be faithfully captured in a rewriting

logic semantics of Orc by enforcing an execution strategy that gives transitions

corresponding to internal actions precedence over the external site return ac-

tion. In Section 4.2, we describe a third, typed approach, based on sorts and

subsorts, that is both more elegant and, in practice, more eﬃciently executable

than the two previous approaches just mentioned.

A second reﬁnement of the Orc SOS, by Wehrman et. al [82], endowed the

original SOS speciﬁcation with timing semantics in a way similar to timed pro-

cess algebras [12]. This was achieved mainly by reﬁning the SOS transition

relation into a relation on time-shifted Orc expressions and timed labels of the

form (l, t), where t is the amount of time taken by a transition. In this extended

relation, a transition step of the form f

(l,t)

֒−→ f

′

states that f may take an action

l to evolve to f

′

in time t,and,ift = 0, no other transition could have taken

place during the t time period. To properly reﬂect the eﬀects of time elapse,

parts of the expression f may also have to be time-shifted by t. However, for

simplicity of presentation, the semantics described in [82], abstracted away the

non-publishing events as unobservable transitions and considered only the asyn-

chronous semantics of Orc. Sections 5 and 6 present a rewriting logic approach

to capturing timed behaviors of Orc expressions, which also takes into account

the synchronous semantics of Orc as described above.

3.4. Some Algebraic Properties

Orc was shown to possess several desirable structural properties, either using

bisimulations based on the original and timed SOS semantics [40, 81], or, alter-

natively, using graph isomorphisms in a tree-based denotational semantics [37].

We focus our attention here on the subset of these algebraic properties shown

in Figure 3. Our choice of this subset is motivated by the fact that the equa-

tions (6)–(11) are conﬂuent and terminating modulo the axioms (1)–(5), so that

(f | g) | h = f | (g | h)(1)

f | g = g | f (2)

f | 0 = f (3)

(f ; g) ; h = f ; (g ; h)(4)

f ;0= 0; f = f (5)

>x> f = 0 (6)

<x< 0 =[stop/x]f (7)

!v ; f =!v (8)

M(p)=0 if stop ∈ p (9)

w(p)=0 if w/∈ SiteName (10)

! stop = 0 (11)

Figure 3: Some algebraic properties of Orc expressions

equality under (1)–(11) becomes decidable by rewriting. Furthermore, since a

rewrite theory R =(Σ,E,R) has both rules R and equations E, so that states

are equivalence classes modulo E, we can obtain a more abstract and more ef-

ﬁcient rewriting logic semantics of Orc by adding equations (1)–(11) to the set

E of equations in the rewrite theory R axiomatizing Orc.

Associativity, commutativity and identity axioms for symmetric parallel

composition were proved in [40, 81, 37]. Associativity and right identity ax-

ioms of the otherwise combinator can also be proved by strong bisimulation

(see [7]), and its left identity is assumed as a structural equivalence rule that

is required to achieve its intended semantics. Proofs of the identities (6) and

(9)–(11) are trivial, since both sides of these identities have no behavioral tran-

sitions, and are, thus, strongly bisimilar. The remaining two laws, namely (7)

and (8), are also easy to show, and their proofs are given in [7].

Other algebraic properties of Orc expressions, which were shown in [40, 81,

37], are not suitable for algebraic simpliﬁcation purposes because, when viewed

as equations, they either fail to satisfy executability requirements, such as con-

ﬂuence and/or coherence with the Orc semantic rules, or they do not necessarily

compute simpler normal forms. In particular, algebraic laws shown using weak

bisimulations that ignore τ transitions, such as the law f

>x> let(x)=f [81],

may break coherence of the semantic rules when used as equational properties,

since they may cause an Orc expression to miss some behavioral transitions.

Other identities may result in equations that are not conﬂuent, such as the re-

stricted left associativity law of sequential composition [40, 81], where FV (h)

computes the set of free variables in h:

>x> (g >y> h)=(f >x > g) >y> h if x/∈ FV (h)

(consider for example the term f

x> (f

y> (f

z> f

)), with x/∈

FV(f

) ∪ FV(f

)andy/∈ FV(f

)). Finally, some identities, when used as

oriented equations, may compute normal forms that are not necessarily struc-

turally simpler than the original expressions, such as, for example, the law

of distributivity of parallel composition over sequential composition [40, 81]:

(f | g) >x> h = f >x> g | g >x> h. For execution purp oses, such equa-

tions add extraneous “simpliﬁcation” steps that may adversely aﬀect execution

performance without actually arriving at simpler normal forms.

ParamList

ResValueList Param

ValueList ResValue Var

Value SpecialValue

SiteName OrcValue

Figure 4: Parameter subsort structure

4. The Orc Semantic Infrastructure

The diﬀerent styles of the rewriting logic semantics of Orc share a common

infrastructure, which can be speciﬁed as a MEL sub-theory R

Ω

=(Σ

Ω

∪

Ω

) ⊂R

sos

Orc

and R

Ω

⊂R

red

Orc

describing the structures for the semantic entities

and the common behaviors that are needed for a complete speciﬁcation of Orc’s

semantics. Below, we describe the most important components of the equational

theory R

Ω

, on which all later developments are based.

4.1. Parameters and Substitution

We assume a sort Var for Orc variables. To account for substitution of vari-

ables with other parameters, we use the CINNI calculus of explicit substitution

[74]. This is consistent with our choice of a ﬁrst-order representation of Orc in

rewriting logic and does not impair readability, since the CINNI notation is just

a slight reﬁnement of the usual textbook notation for higher-order syntax with

explicit names. A more detailed discussion of the Orc instance of CINNI can be

found in [7].

In addition, we assume a sort Param for Orc parameters, which, according to

Orc’s syntax in Figure 1, are either variables of sort Var or site response values

(including the special value stop)ofthesortResValue. Furthermore, response

values other than stop are identiﬁed as either standard data types, such as

integers and booleans, of sort OrcValue, or as site names of sort SiteName,

which are values representing sites that can also be called. This classiﬁcation of

parameters is crucial to the semantics and is neatly captured by the subsorted

structure illustrated in Figure 4, in which a separate sort SpecialValue is used

to represent stop, and three list super-sorts are declared.

4.2. Orc Expressions

The set of Orc expressions that can be constructed from the syntax of Fig-

ure 1, in addition to the internal publishing and handle expressions of the forms

!w and ?h, is represented by a sort Expr, which is subsorted into the (single-

ton) zero expression subsort ZExpr, containing only 0 (which is declared as

Expr

NZExpr ZExpr

AExpr IExpr

Figure 5: The subsort structure of Orc expressions

0 : → ZExpr), and the subsort of non-zero expressions, NZExpr. This distinc-

tion between 0 and other expression will simplify the speciﬁcation and will help

achieve a more eﬃciently executable semantics.

In the synchronous semantics of Orc, the contrast between internal actions

(publishing of values, site calls, and τ transitions) and the external action of

a site return induces a corresponding distinction b etween expressions that can

make an internal transition and others that cannot. To capture the synchronous

semantics, we make this distinction explicit in the type structure by introducing

the notions of active (AExpr)andinactive (IExpr) Orc expressions. Intuitively,

an expression is active if it contains as a sub-expression a value publishing, a

site call, or an expression call sub-expression that is enabled, and is inactive

otherwise. This notion is made more precise in the following deﬁnition.

Deﬁnition 1 (Active and inactive Orc expressions). The set of active expres-

sions F

is the smallest set of non-zero expressions generated by the following

rules:

1. M(v), E(p),and!v are in F

2. If f ∈F

,thenf >x> g ∈F

and f ; g ∈F

3. If f ∈F

or g ∈F

,thenf | g ∈F

and g <x< f ∈F

A non-zero expression f is called active if f ∈F

; otherwise, f is inactive.

Note that this notion of active expressions corresponds exactly to that of

non-quiescent expressions in [61] (see Section 5.4 there). This notion can be

elegantly captured in the type structure of the rewriting semantics by further

subsorting NZExpr into two subsorts: AExpr, for active expressions, and IExpr

for inactive expressions. The subsorting structure of Orc expressions is shown

in Figure 5. Since any non-zero Orc expression must either be active or inactive

(and cannot be both), the subsorts partition the sort NZExpr.Thisisachieved

by a combination of subsort-overloaded function symbol declarations for Orc’s

syntax, along with appropriate equational axioms and frozenness information,

and a few simple membership axioms based on Deﬁnition 1, as we explain below.

Basic Orc expressions. An expression call E(p), which is always active,

has a corresponding declaration of the form

( ):ExprName × ParamList →

AExpr, whereas a parameter call expression p(p), which has the general decla-

ration

( ):Param × ParamList → Expr, is active if and only if p is a site name

M ∈ SiteName and p is a list of values v ∈ ValueList, and hence the subsort-

overloaded declaration

( ):SiteName × ValueList → AExpr. For Inactive calls,

which are calls that fail to satisfy the condition above (and are not semantically

equivalent to 0), a third declaration

( ):Var × ValueList → IExpr and two

membership predicates

M(p):IExpr if p/∈ ValueList ∧ stop /∈ p

x(p):IExpr if p/∈ ValueList ∧ stop /∈ p

capture precisely when a parameter call is inactive. Given the parameter subsort

structure in Figure 4, this declaration and the two membership predicates deﬁne

inactive parameter calls as those in which either: (1) the called parameter is

a site name and the list of arguments contains at least one variable and no

stop values, or (2) the called parameter is a variable and the argument list may

contain variables or non-stop values. Note that, by identities (9) and (10) in

the structural equivalence properties of Figure 3, the other cases, in which the

called parameter is a value or the argument list contains a stop value, are all

semantically equivalent to 0, and are, therefore, of the sort ZExpr.

The other basic expressions, comprising handle expressions ?h and publish-

ing expressions !p are similarly speciﬁed. In particular, handle expressions ?h are

always inactive and are simply speciﬁed by the declaration ?

: Handle → IExpr.

Publishing expressions !p, which are active when p ∈ Value and inactive when

p ∈ Var, are speciﬁed by the following subsort-overloaded family of declarations:

: Param → Expr ! : Value → AExpr ! : Var → IExpr

Note that the third case, when p is stop, is equivalent to 0, according to identity

(11) in Figure 3, and, therefore, has sort ZExpr.

Composed Orc expressions. To complete the speciﬁcation of active and

inactive expressions, function symbol declarations for the four Orc combinators

are also subsort-overloaded according to Deﬁnition 1. Sp eciﬁcally, the symmet-

ric parallel composition combinator has the following subsort-overloaded family

of declarations (where the equational axioms of associativity, commutativity,

and identity are speciﬁed by the equational attributes assoc, comm, id below,

and the ditto keyword speciﬁes the same equational attributes for other subsort-

overloaded typings of the same operator):

| : Expr × Expr → Expr [assoccommid: 0]

| : AExpr × Expr → AExpr [ditto]

| : IExpr × IExpr → IExpr [ditto]

which precisely state that a symmetric parallel composition is active if at least

one of its subexpressions is active, and is inactive otherwise. Similarly, the

following declarations specify the sequential composition operator:

> > : Expr × Var × Expr → Expr [frozen(3)]

> > : AExpr × Var × Expr → AExpr [ ditto]

> > : IExpr × Var × Expr → IExpr [ditto]

Since the right subexpression of a sequential composition has no behavioral

transitions, the sequential combinator symbol is declared frozen on its third ar-

gument (using the frozen attribute); i.e., we deﬁne φ(

> > )={3},sothatno

rewriting is allowed on the third argument. The declarations state that a se-

quential composition is active (resp. inactive) if and only if its left subexpression

is active (resp. inactive). The operator declarations for the asymmetric parallel

combinator

< < are similar to those of symmetric composition, while the

declarations for the otherwise combinator

; are similar to those of sequential

composition, except that the symbol is declared frozen on its second argument,

and with identity 0.

Algebraic properties. To fully account for the algebraic properties of Orc

expressions, the semantic infrastructure includes equations that correspond to

the algebraic identities (6)–(11) in Figure 3. As mentioned ab ove, identities

(1)–(5) are speciﬁed as equational axioms of the respective Orc combinators,

declared by the assoc, comm and id attributes in their operators’ declarations.

4.3. Orc Conﬁgurations

A state in the execution of an Orc program is deﬁned by an Orc conﬁguration,

which (as in [62]) is a pair f,r,wheref is the Orc expression to be executed

and r is a record structure consisting of ﬁve semantic ﬁelds: (1) a label ﬁeld

lbl : l, (2) an environment for expression names env : σ, (3) a pool of pending

messages msg : ρ, (4) a set of currently used handle names hdl : η,and(5)a

clock clk : t. A more detailed description of these ﬁelds follows.

Clock. Time is abstracted by the sort Time, which is speciﬁed as a totally

ordered set with a least element zero. A supersort TimeInf of Time also includes

∞ as a top element, which is useful for specifying the proper timed semantics

of Orc. An instantiation of the sort TimeInf can, therefore, be either discrete

or dense. In our speciﬁcations we assume a dense time domain implemented by

the non-negative rationals and maintained by the clock ﬁeld in a conﬁguration.

Environment. An environment, which is maintained to resolve references

to expression names, is a term of sort Env, which is deﬁned as a set of decla-

rations (terms of sort Decl,withDecl < Env), formed with an asso ciative and

commutative set union operator

, with the empty set as its identity element.

Initially, an environment is created out of the declaration list



d of an Orc pro-

gram



d ; f so that the following conditions hold: (1) a later declaration in the

list



d hides all previous declarations with the same expression name; and (2) all

declarations in the resulting environment are visible to each other. This implies

that an expression name has a unique deﬁning declaration in an environment,

and that (mutual) recursion is directly available.

Handles. A handle is a name of sort Handle that uniquely identiﬁes a

pending site call, which is a call awaiting a response from the environment.

Since, by the SiteCall SOS rule of Figure 2, fresh handle names need to be

generated, a conﬁguration maintains in its handles ﬁeld a set η of currently

used handles against which new names may be created. Sets of handles, of

sort HandleSet, are constructed by an associative, commutative comma-denoted

union operator, with the empty set of handles as its identity element.

Messages. We maintain a message pool (MsgPool) as a multiset of mes-

sages, constructed by the empty juxtaposition operator with the empty set as

the identity element. A message, which is a term of the sort Msg,iseithera

site call message of the form [M, v, h], representing the parameters of the call

along with a handle name identifying the site call, or a simulated site response

of the form [w, h], with w the site response corresponding to the call identiﬁed

by h, that is waiting in the message pool to be consumed by the Orc expression.

Although the environment in the SOS semantics of Orc is treated as a “black

box” with unpredictable responses from remote sites, simulation of environment

responses is needed to arrive at an executable speciﬁcation. Simulation of re-

sponses is achieved by automatically converting a site call message [M,v, h]into

a potential response message [app(M, v, γ ),h], where app is a partial function

that can simulate a resp onse based on the intended semantics of M .Itmay

also associate a delay γ to site responses. Such a potential response message

cannot be processed until the delay is zero, at which point the message is re-

placed by a proper response message [w, h], with w the site response evaluated

by the function app. For instance, a site call message [CNN , 1,h] is immedi-

ately converted into the potential response message [app(CNN , 1, 5),h], with 5

a message delay. Then, after ﬁve time units have passed, the message becomes

[app(CNN , 1, 0),h], which, according to the semantics of site calls to CNN sp ec-

iﬁed by the function app, is equivalent to the response message [signal,h]. The

partial function app provides a ﬂexible and modular mechanism for specifying

delays and site call semantics [7].

Labels. The label ﬁeld keeps track of the last event generated as a result

of a conﬁguration evolving into another, which is needed in the SOS semantics

for inferring one-step transitions. To represent the four labels in the SOS rules

in Figure 2, we deﬁne a sort Label, and declare four operators of this sort:

 ,  : SiteName × ValueList × Handle → Label τ :→ Label

? : Handle × Value → Label ! : Value → Label.

We also use a special constant ǫ :→ Label to represent absence of a label.

Therefore, the general form of an Orc conﬁguration is: f, lbl : l | env :

σ | msg : ρ | hdl : η | clk : t. Given an Orc program



d ; f,itsinitial

conﬁguration, which can be constructed by an operator [

]:Program → Conﬁg,

is of the form:

f, lbl : ǫ | env : init(



d) | msg : ∅|hdl : ∅|clk :0

where init is a function that initializes an environment structure from a list of

declarations



d according to the description given above.

Additionally, as part of the semantic infrastructure, we deﬁne two notions

about Orc conﬁgurations (borrowed from Real-Time Maude [64]) that will be

useful for deﬁning the timed behaviors of Orc for both the SOS-based and the

reduction rewriting semantics. The ﬁrst is the notion of eager conﬁgurations,

which are conﬁgurations that can make an instantaneous (internal or external)

transition, i.e., conﬁgurations of the form f,r where either f is active or r

has a pending site response that can be consumed. This notion is made more

precise in the following deﬁnition, where

f ranges over active Orc expressions

and

f over inactive expressions.

Deﬁnition 2 (Eager Orc conﬁguration). An Orc conﬁguration C is eager if C

is of one of the following forms: (i) 

f,r;or(ii)

f,msg : ρ[w, h] | r with h a

handle in

This notion is easily captured by a (partial) predicate eager : Conﬁg → [Bool]

that evaluates to true if and only if the given conﬁguration is eager using two

equations corresponding to cases (i) and (ii) in Deﬁnition 2 above. The second

notion is that of the maximal time elapse (or mte) of an Orc conﬁguration,

which speciﬁes the maximum time shift until the next point in time when an

instantaneous event (corresponding to the evaluation of an Orc expression as

opposed to just advancing time on the conﬁguration) may be enabled.

Deﬁnition 3 (mte of an Orc conﬁguration). The maximum time elapse (mte)

of an Orc conﬁguration f, msg : ρ | r is the minimum time delay across all

messages in ρ if ρ is non-empty, and is ∞ otherwise.

The time shift needed to advance the clock of an Orc conﬁguration to the

next point in time when an instantaneous action becomes enabled is determined

by a function mte : Conﬁg → TimeInf, which is deﬁned equationally according

to the deﬁnition above.

5. The SOS-based Rewriting Semantics R

sos

Orc

We now present an executable rewriting logic semantics of Orc that is based

directly on the SOS semantics of Orc of Section 3.3. This semantics is obtained

by mapping the SOS rules in Figure 2 into a corresponding rewrite theory

sos

Orc

=(Σ

∪ B

,φ

) according to Meseguer and Braga’s semantics-

preserving transformation from Modular SOS [62] to rewriting logic. An initial

version of the SOS-based rewriting semantics of Orc appeared in [3], where

we described two diﬀerent ways of capturing Orc’s synchronous semantics: (1)

strategy expressions, and (2) additional equational conditions. The semantics

in [3] also captured timed behaviors in Orc, although timing, as speciﬁed there,

was limited to discrete time domains, such as the natural numbers.

Since the initial version in [3], the rewriting semantics of Orc given by R

sos

Orc

has been thoroughly reﬁned and extended to achieve a more complete, elegant,

and eﬃciently executable speciﬁcation. First, using order-sorted structures for

Orc values, a concise representation of the new otherwise combinator and its

semantics has been achieved. Moreover, order-sorted declarations for Orc ex-

pressions and action labels, and membership equations enable a simpler and

more elegant speciﬁcation of instantaneous actions that can be executed and

analyzed more eﬃciently than with just the many-sorted speciﬁcations used be-

fore. Furthermore, the semantics is now capable of handling dense time domains,

SiteCall : ·M (v), lbl : l | msg : ρ | hdl : η | r

→?h, lbl : Mv, h|msg : ρ[M,v, h] | hdl : η, h | r if h := fresh(η)

SiteRetV : ·?h, lbl : l | msg : ρ[v, h] | hdl : η, h | r

→!v, lbl : h?v | msg : ρ | hdl : η | r

SiteRetN : ·?h, lbl : l | msg : ρ[stop,h] | hd

l : η, h | r

→0, lbl : h?stop | msg : ρ | hdl : η | r

Publish : ·!v, lbl : l | r→0, lbl :!v | r

Def : ·E(p), lbl : l | env : σ, E(x)  f | r →[p/x]f, lbl : τ | env : σ, E(x)  f | r

Figure

6: Rewrite rules in R

sos

Orc

for basic expressions

using ideas from real-time rewrite theories [67] and Real-Time Maude [64], with

implementations in both (Core) Maude and Real-Time Maude.

As discussed in Section 4, the rewrite theory R

sos

Orc

extends the semantic

infrastructure equational theory R

Ω

, which captures the algebraic properties

of Orc listed in Figure 3 as equational axioms in B

and equations in E

Below, we describe how R

sos

Orc

captures the timed, synchronous semantics of Orc

expressions, and discuss some of its important properties.

5.1. Instantaneous Rewriting Semantics Rules

Since, by rewriting logic’s transitivity inference rule, a rewrite computation

t → t

′

may involve a sequence of one-step rewrites t → t

→ t

→···→t

→ t

′

we need to restrict rewrites of Orc conﬁgurations to be exactly one-step rewrites,

corresponding to the single-step SOS behavior, as explained in [55]. For this

purpose, we employ the SOS one-step modiﬁer technique of [62, 73], in which two

operators are declared: (1) a (frozen) preﬁx dot operator ·

: Conﬁg → Conﬁg,

and (2) a non-frozen operator smallstep : Conﬁg → Conﬁg. By deﬁning the

rewrite rules that correspond to the SOS rules in Figure 2 in the following

format

·f,r→f

′

 if



i=1

·f

→f

′

∧C

with C an equational condition, we eﬀectively restrict rewriting to single steps

using the equation:

smallstep(f, lbl : l | r)=smallstep(·f, lbl : ǫ | r)

where the label ﬁeld is reset in preparation for the next transition step, which

is enabled by the newly introduced preﬁx dot.

The rewrite rules in R

sos

Orc

that specify the semantics of the basic Orc ex-

pressions are shown in Figure 6. The rules precisely match the correspondingly

labeled SOS rules in Figure 2.

When executing a site call, according to the site call rewrite rule, the call

expression is replaced by the handle expression (?h), where h is a fresh handle

name generated by a function fresh with respect to the currently used set of

handle names η,usingamatching equation

in the condition. Furthermore, the

rule emits a message targeted to M into the message pool, adds a site call event

label, and updates the handles set. When a site response that corresponds to

the call with handle h appears in the message pool, one of the site return rules

applies, depending on whether the response is the stop value or not. In both

cases, the site return rules replace the handle expression with the appropriate

Orc expression, add a site return event label, remove the message from the

pool, and update the set of handles. The rules for publishing expressions and

expression calls are very similar to their counterparts in the SOS speciﬁcation.

Figure 7 lists the rewrite rules in R

sos

Orc

that specify the synchronous, instan-

taneous semantics of the Orc combinators. In the ﬁgure, we let

f, ˆg range over

active expressions (of the sort AExpr),

f, ¯g over inactive expressions (IExpr), and



f,g over non-zero expressions (NZExpr). We also let i denote an internal action

label (i.e., a non-site-return label), and n a non-publishing internal action label

(i.e., a site call or a τ label). An important distinction between the rewrite rules

in R

sos

Orc

and the SOS rules in Section 3.3, is that the former capture the syn-

chronous semantics of Orc expressions whereas the rules in Section 3.3 describe

the unrestricted asynchronous semantics. This explains the larger number of

rules in Figure 7 compared to those in Figure 2. Indeed, for each rule in the

SOS rules for Orc’s combinators in Figure 2, there are one or more rewrite rules

in R

sos

Orc

that correspond to it. For example, the SOS rule Sym for symmetric

parallel composition has two corresponding rewrite rules in R

sos

Orc

, one captur-

ing internal actions for active expressions (SymI), while the other deals with

inactive expressions consuming site returns (SymE). Since the symmetric com-

binator is commutative with identity 0, the two rewrite rules fully specify the

synchronous semantics of parallel composition. Similar observations also apply

to the remaining rewrite rules in Figure 7.

5.2. Orc’s Synchronous SOS Revisited

As describ ed in Section 4.2 and summarized in Figure 5 above, the distinc-

tion between active (non-quiescent) and inactive (quiescent) Orc expressions,

which proved useful in obtaining a simple an elegant speciﬁcation of the instan-

taneous rewriting semantics of Orc, was captured by deﬁning an order-sorted

signature for Orc expressions and values. Since an order-sorted signature Σ

with “mix-ﬁx” syntax can be viewed as a context-free grammar G in which the

non-terminals of G arethesortsofΣ,andtheproductionrulesofG are the

mix-ﬁx operator declarations and the subsort declarations in Σ, we may use the

synchronous rewriting logic semantics described in Section 5.1 to give a corre-

sponding synchronous SOS of Orc speciﬁed by SOS rules that deﬁne a single,

A matching equation (see [21], Section 4.3) of the form u := v is an ordinary equation

u = v,whereu is a constructor pattern with extra variables, say x

, ··· ,x

, and v is a term.

Operationally, it is evaluated by matching the canonical form of the substitution instance of

v by the equations in the theory modulo the axioms B against the pattern u. In this way, the

extra variables become instantiated by matching.

SymI : ·

f | g, lbl : l | r→f



| g, lbl : i | r



 if ·

f, lbl :  | r→f



, lbl : i | r





SymE : ·

f | ¯g, lbl : l | r→f



| ¯g, lbl : h?w | r



 if ·

f, lbl :  | r→f



, lbl : h?w | r





Seq1V : ·

>x> g, lbl : l | r→(f



>x> g) | [v/x]g, lbl : τ | r





if ·

f, lbl :  | r→f



, lbl :!v | r





Seq1NI : ·

>x> g, lbl : l | r→f



>x> g, lbl : n | r





if ·

f, lbl :  | r→f



, lbl : n | r





Seq1NE : ·

>x> g, lbl : l | r→f



>x> g, lbl : h?w | r





if ·

f, lbl :  | r→f



, lbl : h?w | r





Asym1V : ·g

<x<

f, lbl : l | r→[v/x]g, lbl : τ | r





if ·

f, lbl :  | r→f



, lbl :!v | r





Asym1NI : ·g

<x<

f, lbl : l | r→g

<x< f



, lbl : n | r





if ·

f, lbl :  | r→f



, lbl : n | r





Asym1NEa : ·¯g

<x<

f, lbl : l | r→¯g <x< f



, lbl : h?w | r





if ·

f, lbl :  | r→f



, lbl : h?w | r





Asym1NEb : ·0

<x<

f, lbl : l | r→0

<x< f



, lbl : h?w | r





if ·

f, lbl :  | r→f



, lbl : h?w | r





Asym2I : ·ˆg

<x<



f, lbl : l | r→g



<x<



f, lbl : i | r





if ·ˆg, lbl :  | r→g



, lbl : i | r





Asym2E : ·¯g

<x<

f, lbl : l | r→g



<x<

f, lbl : h?w | r





if ·¯g, lbl :  | r→g



, lbl : h?w | r





OtherV : ·

f ; g, lbl : l | r→f



, lbl :!v | r



 if ·

f, lbl :  | r→f



, lbl :!v | r





OtherNI : ·

f ; g, lbl : l | r→f



; g, lbl : n | r



 if ·

f, lbl :  | r→f



, lbl : n | r





OtherNE : ·

f ; g, lbl : l | r→f



; g, lbl : h?w | r





if ·

f, lbl :  | r→f



, lbl : h?w | r





Figure 7: Rewrite rules in R

sos

Orc

for the combinators

h fresh

M(v)

Mv,h

֒−→ ?h

(SiteCall)

h?v

֒−→ !v

(SiteRetV)

h?stop

֒−→ 0

(SiteRetN)

֒−→ 0

(Publish)

E(x)  f ∈ D

E(p)

֒−→ [p/x]f

(Def)

֒−→ f



f ; g

֒−→ f



(OtherV)

֒−→ f



f ; g

֒−→ f



; g

(OtherNI)

֒−→ f



f ; g

֒−→ f



; g

(OtherNE)

֒−→ f



f | g

֒−→ f



| g

(SymI)

֒−→ f



f | ¯g

֒−→ f



| ¯g

(SymE)

֒−→ f



>x> g

֒−→ (f



>x> g) | [v/x]g

(Seq1V)

֒−→ f



>x> g

֒−→ f



>x> g

(Seq1NI)

֒−→ f



f >x> g

֒−→ f



>x> g

(Seq1NE)

֒−→ f



g <x<

֒−→ [v/x]g

(Asym1V)

֒−→ f



g <x<

֒−→ g <x< f



(Asym1NI)

֒−→ f



¯g <x<

֒−→ ¯g <x< f



(Asym1NEa)

֒−→ f



0 <x<

֒−→ 0 <x< f



(Asym1NEb)

ˆg

֒−→ g



ˆg <x<



֒−→ g



<x<



(Asym2I)

¯g

֒−→ g



¯g <x<

֒−→ g



<x<

(Asym2E)

Figure 8: Synchronous (instantaneous) structural operational semantics of Orc

self-contained transition relation, in which no rule application constraints or

further characterizations of transitions are necessary. This connection between

order-sorted theories and context-free grammars is exploited by ﬁrst reﬁning

the abstract syntax of Orc given in Figure 1 to include new syntactic categories

NZExpr, AExpr and IExpr for the sorts NZExpr, AExpr, IExpr, and reﬁned pro-

duction rules corresponding to the Orc expression subsort structure (shown in

Figure 5) and the Orc expression operator declarations described in Section 4.2.

In particular, in the reﬁned syntax, an Orc expression is either 0 or a non-zero

expression



f, which can be either an active expression

f, or an inactive expres-

sion

f. The syntactic categories AExpr and IExpr capture, respectively, the

sets of active and inactive expressions, as speciﬁed by Deﬁnition 1.

Based on this reﬁned syntax, the SOS rules deﬁning the synchronous SOS of

Orc are shown in Figure 8. We note that these rules deﬁne a self-contained tran-

sition relation specifying the synchronous semantics of Orc, in which no external

rule application constraints are necessary. This is in contrast to the approach

of [61], in which the transition relation was split into two sub-relations: one for

internal transitions on non-quiescent expressions, and another for external tran-

sitions on quiescent expressions. We also note that the SOS rules correspond,

one-to-one, to the rewriting logic semantics rules of the theory R

sos

Orc

given in

Figures 6 and 7.

5.3. The Tick Rule

Following the standard approach for specifying time in rewriting semantic

deﬁnitions of real-time systems [67] – using either ordinary or real-time rewrite

theories, the theory R

sos

Orc

includes a time tick rewriteruletocapturethetimed

semantics of Orc, in addition to the instantaneous rewrite rules in Figure 6 and

Figure 7. The tick rule in R

sos

Orc

is a one-step rule deﬁned as follows (with t

′

the sort Time):

Tick : ·f,clk : t | r→f

′

, clk : t + t

′

| δ(r, t

′

)

if eager(f, clk : t | r) = true ∧ t

′

:= mte(r) ∧ t

′

=0.

Note that the variable t

′

only appears in the righthand side. The value of t

′

determined, by the matching equation t

′

:= mte(r) in the condition, to be the

maximum time elapse, which is computed as the minimum message delay across

all messages in the message pool of the conﬁguration (see Deﬁnition 3). The

function δ propagates the eﬀect of a clock tick t

′

down the record structure of a

conﬁguration (somewhat similar to time-shifting in [82]). It essentially updates

delays of messages in the message pool, which makes response messages from

site calls become eventually available. For example, suppose that the current

conﬁguration C is of the form

·h

| h

, clk :0| msg :[app( M, v

, 3),h

][app(N, v

, 5),h

] | r

Then, the maximum time elapse of C is 3, and the clock can be advanced by

at most t

′

= 3 time units (as otherwise the opportunity of consuming the site

return for the call to M would be missed). When the Tick rule is applied, the

clock advances to 3, and the function δ updates the delays on all messages in

the message po ol, arriving at the conﬁguration

·h

| h

, clk :3| msg :[app( M, v

, 0),h

][app(N, v

, 2),h

] | r

in which the site return message for M can be processed (as per the deﬁnition

of app on M) and consumed (using the SiteRetV rule).

Ticking the clock, and updating the record structure accordingly, are not

enough for the proper timed semantics of Orc, because if not appropriately

controlled, new undesirable behaviors may be introduced, such as advancing

time indeﬁnitely or beyond a point when an instantaneous action was enabled

(and, in eﬀect, missing that action). This is avoided by deﬁning a maximal,

time-synchronous execution semantics, in which an Orc conﬁguration with no

enabled instantaneous actions is allowed to advance its clock all the way up to

the next point in time when an instantaneous action will be enabled

.This

For the analysis to be mechanizable, we also assume Orc programs with “non-Zeno”

behaviors [68], such that only a ﬁnite number of instantaneous transitions are possible within

any ﬁnite period of time. In particular, we exclude Orc programs that are not “instantaneously

terminating” that may exhibit an inﬁnite sequence of instantaneous transitions in zero time,

which in eﬀect can prevent time from ever advancing.

restriction is formally speciﬁed by making the tick rule conditional on: (1) the

conﬁguration not being eager, i.e., being incapable of making an instantaneous

transition as deﬁned by the eager predicate, and (2) the time shift t

′

being equal

to the maximal time elapse of the conﬁguration, as deﬁned by the mte function,

which must be non-zero (see Section 4.3 for deﬁnitions of eagerness and maximal

time elapse of conﬁgurations). These conditions ensure that time is advanced

as much as possible in every application of the tick rule, but only enough so as

to be able to capture all events of interest.

5.4. Correctness of R

sos

Orc

The original SOS transition relation ֒→ proposed in [61] (a variant of which

was shown in Figure 2) and it’s reﬁnement, also in [61], into two sub-relations

֒→

and ֒→

for quiescent and non-quiescent Orc expressions, respectively, de-

ﬁned the synchronous semantics of the instantaneous actions in Orc. Although

a non-trivial timed extension of the original SOS speciﬁcation was later pro-

posed in [82], the extension did not consider the synchronous semantics, and

abstracted non-publishing actions as unobservable actions for simplicity of pre-

sentation. We, therefore, show correctness of the rewriting semantics given by

sos

Orc

with respect to the SOS semantics in [61] by comparing the transition

systems deﬁned by the reﬁned SOS relation ֒→

∪ ֒→

and the instantaneous

part of the rewrite theory R

sos

Orc

, namely, the theory R

sos

Orc

without the Tick

rule.

First, a simple lemma relating the notions of non-quiescent expressions in [61]

and active expressions as deﬁned in Section 4.2.

Lemma 1. f is non-quiescent (resp. quiescent) iﬀ f is active (resp. inactive).

Proof. Straightforward by structural induction on f .

We denote by R

sos

Orc

⊢ t →

′

a single rewrite step obtained by an application

of an instantaneous (non-tick) rewrite rule, i.e., a rule I ∈R

sos

Orc

−{Tick}.

Correctness of R

sos

Orc

is expressed by the following theorem.

Theorem 1 (Correctness of R

sos

Orc

). For any two Orc expressions f and f

′

,and

for X ∈{A, R},

f֒→

′

⇐⇒ R

sos

Orc

⊢ smallstep(·f, lbl : l | r) →

smallstep(f

′

, lbl : l

| r

′

)

with l

an internal action label and l

a site return action label.

Proof. The proof follows trivially by construction of R

sos

Orc

, based on the cor-

rectness of the MSOS-to-rewriting logic transformation metho dology, given by

the strong bisimulation theorem (Theorem 1) in [55], and from Lemma 1.

5.5. Executability Properties of R

sos

Orc

The speciﬁcation of the theory R

sos

Orc

=(Σ

∪ B

,φ

) is not only

correct with respect to Orc’s synchronous semantics but also satisﬁes some de-

sirable admissibility and executability prop erties that make it computable and

amenable to sound and complete formal analysis and veriﬁcation. In particular,

the signature Σ

is A

-preregular [21] and the equations E

and the rules R

are deterministic. Furthermore, the equations E

are operationally terminat-

ing, conﬂuent, and sort-decreasing modulo the axioms B

, and the rules R

are

coherent with E

. As a result, the speciﬁcation R

sos

Orc

, through its implementa-

tion in Maude as the system module named SOS-ORC, can be both executed and

formally analyzed. We refer the reader to the extended version of this paper [7]

for a detailed proof of the following theorem.

Theorem 2 (Executability of

sos

Orc

). The speciﬁcation given by

sos

Orc

satisﬁes

the executability requirements of generalized rewrite theories.

6. The Reduction Rewriting Semantics R

red

Orc

Although the rewriting speciﬁcation R

sos

Orc

is readily understandable and its

correctness with respect to the SOS semantics in [61] is straightforward, its

execution, in practice, is quite expensive and ineﬃcient. This is partly because

sos

Orc

makes extensive use of conditional rewrite rules (corresponding to the

rules in the SOS sp eciﬁcations) which are particularly expensive to execute as

compared to unconditional rules. Moreover, most of these rewrite rules, besides

being conditional, have rewrites (as opposed to equations) in their conditions,

which is typical of the SOS speciﬁcation style. Rewrite conditions, as opposed

to equational conditions, can be particularly expensive to ﬁnd a proof for or

to disprove as they are non-deterministic in nature, and require breadth-ﬁrst

search. In addition, the relatively large numb er of such rules in the speciﬁcation

can potentially cause nested (recursive) rewrite checks when checking a rule’s

conditions, which adversely aﬀect performance of execution and analysis.

This section introduces a speciﬁcation for a rewrite theory R

red

Orc

that is not

directly based on the SOS speciﬁcations but is instead more akin to a reduction

semantics. It utilizes the inherently distributed semantics of rewriting logic, and

uses both equations, for modeling deterministic computation steps, and rewrite

rules, for modeling the non-deterministic transitions. This is achieved primarily

by localizing the rewrite rules as much as possible, and specifying equationally

any required propagation of information between the subexpression to be rewrit-

ten (the redex ) and the enclosing Orc conﬁguration (the context). In eﬀect, this

approach minimizes the number of rewrite rules needed and reduces their com-

plexity, resulting in a semantic speciﬁcation that can b e executed and analyzed

much more eﬃciently. Furthermore, the semantics deﬁned by R

red

Orc

is equiva-

lent to R

sos

Orc

, in the sense that, given any Orc program P , the state transition

systems of the semantics of P given by R

sos

Orc

and R

red

Orc

are strongly bisimilar,

assuming that program conﬁgurations are closed

.ThisimpliesthatR

red

Orc

cap-

tures precisely the intended semantics of Orc while providing an eﬃcient means

for execution and formal analysis of Orc programs.

The speciﬁcation of the reduction rewriting semantics builds on the seman-

tic infrastructure given by R

Ω

introduced in Section 4, with the main diﬀerence

that, unlike for R

sos

Orc

, action labels are not essential to R

red

Orc

, since lab el in-

formation is implicitly managed by auxiliary operators in R

red

Orc

. However, to

maintain equivalence with R

sos

Orc

,thelabelﬁeldlbl : l is maintained in Orc con-

ﬁgurations as before. Furthermore, the one-step modiﬁer strategy used in the

SOS-based semantics to implement one-step rewrites is no longer needed.

6.1. The Internal Actions

Transition steps that correspond to internal actions of Orc expressions are

speciﬁed using the IAction rewriterule(withact

↑

an auxiliary function symbol,

which will be described shortly):

IAction : 

f,r→act

↑

′

,i),r if

f → act

↑

′

,i).

The rule simply states that an (eager) conﬁguration with an active expression

may make an internal transition if the expression is able to make that transition.

Note that this rule is global at the conﬁguration level, which is required to

maintain equivalence with the original interleaving semantics of Orc, and is also

essential for executability of the speciﬁcation. An active expression may make

an internal transition according to one of the following rules:

SiteCall : M(v) → act

↑

(tmp, siteCall(M,v))

ExprCall : E(p) → act

↑

(tmp, exprCall(E,p))

Publish :!v → act

↑

(0, publish(v)).

Therefore, an active, basic sub-expression may rewrite to a frozen, auxiliary

operator symbol act

↑

: Expr × InternalEvent → [Expr], whose purpose is to prop-

agate the action up the expression tree all the way to the top so that: (i) its

eﬀects are reﬂected in the conﬁguration (e.g. emitting a site call message into the

conﬁguration) , and (ii) any necessary information in the conﬁguration can be

propagated back to the sub-expression (e.g. getting globally fresh handle names

for site calls). This process of propagating information back and forth between

redexes and contexts is speciﬁed equationally by induction on the structure of

Orc expressions. In particular, for site and expression calls, act

↑

replaces the

call with a temporary placeholder expression tmp and propagates the action up

to the conﬁguration according to the following equations (where c stands for a

Roughly speaking, a conﬁguration f, r is closed if every expression name referenced in

f has a declaration in r (see Section 6.5).

site call event siteCall(M, v), or an expression call event exprCall(E,p)):

act

↑

(f,c) | g = act

↑

(f | g, c) act

↑

(f,c) >x> g = act

↑

(f >x> g,c)

act

↑

(f,c) <x< g = act

↑

(f <x< g,c) act

↑

(f,c) ; g = act

↑

(f ; g, c) .

g <x< act

↑

(f,c)=act

↑

(g <x< f,c)

Once the call reaches the root of the expression, the eﬀect of the call is reﬂected

in the containing conﬁguration, using one of the following equations, depending

on the call type:

act

↑

(f,siteCall(M,v)), lbl : l | msg : ρ | hdl : η | r

= act

↓

(f,?h), lbl : ǫ | msg : ρ[M, v, h] | hdl : η, h | r if h := fresh(η)

act

↑

(f,exprCall(E,p)), lbl : l | env : σ, E(x)  g | r

= act

↓

(f,[p/x]g), lbl : ǫ | env : σ, E(x)  g | r

which capture precisely the semantics of site and expression calls, respectively.

The speciﬁcations of the eﬀects of site calls and expression calls on the record

structure of a conﬁguration are identical to those in the SiteCall and Def

rules of the SOS-based semantics of R

sos

Orc

, except that the label ﬁeld is reset to

ǫ. Note that since both the handle h in a site call and the instantiated body g

of the expression deﬁnition in an expression call need to propagate back to the

subterm where the call was made (which was temporarily substituted by the

expression tmp), act

↑

does not rewrite immediately to f, but rather to another

(frozen) operator, act

↓

: Expr × Expr → Expr, that traverses down the expression

tree until it reaches the appropriate subterm, using the following equations:

act

↓

(



f |



′

,g)=act

↓

(



f,g) | act

↓

(



′

,g) act

↓

(



f ;



′

,g)=act

↓

(



f,g) ;



′

act

↓

(



f >x> f

′

,g)=act

↓

(



f,g) >x> f

′

act

↓

(b, g)=b

act

↓

(f <x<



′

,g)=act

↓

(f,g) <x< act

↓

(



′

,g) act

↓

(tmp,g)=g.

where b is a basic Orc expression, and g is either a handle expression (for a site

call), or the body expression of a declaration (for an expression call).

The action of publishing a value is deﬁned slightly diﬀerently, although the

overall operational behavior is similar. This is primarily because published val-

ues may be bound in an expression by sequential or asymmetric parallel com-

positions. In particular, if the published value v is not bound in the expression,

the value is propagated all the way to the top, using the following equations:

act

↑

(f,publish(v)) | g = act

↑

(f | g, publish(v))

act

↑

(f,publish(v)) <x< g = act

↑

(f <x< g,publish(v))

act

↑

(f,publish(v)) ; g = act

↑

(f,publish(v)).

act

actact

(a) Site and expression calls

act

(b) Publishing and τ actions

Figure 9: Schematic diagrams of the equational propagation of information in an expression

tree

In this case, the published value reaches the top of the expression in the enclosing

conﬁguration: act

↑

(f,publish(v)), lbl : l | r = f,lbl : ǫ | r. Otherwise, if the

value published is bound by a sequential composition or an asymmetric parallel

composition, then one of the following equations applies:

act

↑

(f,publish(v)) >x> g = act

↑

(f >x> g | [v/x]g,publish

)

<x< act

↑

(f,publish(v)) = act

↑

([v/x]g,publish

These equations reﬂect the semantics speciﬁed by the SOS rules Seq1V and

Asym1V of Figure 2 (and the corresponding rewrite rules in R

sos

Orc

). They

also change the value publishing event to a τ publishing event publish

,which

ultimately causes the label ﬁeld of the conﬁguration to reset (the equations for

terms of the form act

↑

(f,publish

) are similar). Notice that in both cases, when

a publishing (or a τ) event reaches the conﬁguration, no further information

needs to be communicated back down the expression, unlike the cases of site

and expression calls. Figure 9 gives a schematic representation of the mechanics

of the internal actions. The ﬁgure shows that the structures of a site call and

an expression call are similar, although the information propagated in both

directions (and the side eﬀects on the enclosing conﬁgurations) are diﬀerent.

6.2. The Site Return Action

The external action of a site return is modeled by the following rewrite rule:

SiteReturn : 

f, lbl : l | msg : ρ[w, h] | hdl : η, h | r

→sret(

f,w,h) , lbl : ǫ | msg : ρ | hdl : η | r if h ∈ handles(

f).

which corresponds to the SiteRetV and SiteRetStop rules in the SOS rules

and the SOS-based rewrite rules of R

sos

Orc

. Note that application of the site return

rule above is subjected to the condition that the handle name of the message

to be consumed is referenced in

f. This is to avoid useless transitions that

Unwanted concurrent execution of site calls, expression calls and publishing of values is

avoided by equations that will introduce an error constant of the kind [Expr] in such cases. For

reasons of conﬂuence of the equations E

, an expression having error as a subterm immediately

collapses to error (see [4]).

could take place when a thread, having an unﬁnished site call, is pruned using

asymmetric parallel composition, and thus, maintains a comparable behavior

to site returns in the SOS speciﬁcation. In addition, the rule SiteReturn

captures the synchronous semantics of Orc by matching an inactive expression

f to consume the site return message. By this rule, the expression

f rewrites

to a frozen auxiliary operator sret : Expr × ResValue × Handle → Expr which

equationally carries the response parameters down to the appropriate pending

handle expression, replacing it with !w if w ∈ Value ,or0 if w = stop.

6.3. Timed Semantics

Like the SOS-based rewriting semantics R

sos

Orc

,timeandtheeﬀectsoftime

elapse are speciﬁed in the reduction semantics R

red

Orc

using a simple tick rewrite

rule and the δ methodology to propagate the eﬀects of time elapse on the

state [67, 64]. In fact, the tick rewrite rule is almost identical to that of R

sos

Orc

given in Section 5.3, but without the SOS one-step mo diﬁer. The rule relies on

the eager and mte functions to capture the maximal, time-synchronous execution

semantics, described before in Section 4.3.

6.4. Executability Properties of R

red

Orc

Like R

sos

Orc

,thetheoryR

red

Orc

=(Σ

∪ B

,φ

) is executable, which

implies that it provides an interpreter for Orc programs, and that formal analysis

using its implementation in Maude, as a system module RED-ORC, is both sound

and complete. A detailed proof of this result, which is stated below as a theorem,

is given in [7].

Theorem 3 (Executability of R

red

Orc

). The speciﬁcation given by R

red

Orc

satisﬁes

the executability requirements of generalized rewrite theories.

6.5. Equivalence of R

sos

Orc

and R

red

Orc

We shall now show that the SOS-based rewriting semantics, R

sos

Orc

,andthe

reduction-based rewriting semantics, R

red

Orc

, are semantically equivalent, in the

sense that an Orc program behaves in exactly the same way in both semantic

models. We show this by proving a more general result, stating that the semantic

models given by R

sos

Orc

and R

red

Orc

of any closed Orc conﬁguration are strongly

bisimilar. We ﬁrst deﬁne what we mean by a conﬁguration being closed.

Deﬁnition 4 (Closed conﬁgurations). An Orc conﬁguration f,r is well-formed

if: (i) the conﬁguration f,r is in canonical form; (ii) f does not contain any

auxiliary function symbol, such as act

↑

, sret,ortmp; and (iii) r contains at

least the ﬁve ﬁelds introduced in Section 4, namely: (1) lbl : l,withl ∈ Label,

(2) hdl : η,withη ∈ HandleSet,(3)env : σ,withσ ∈ Env,(4)msg : ρ,with

ρ ∈ MsgPool,and(5)clk : t,witht ∈ Time. Moreover, a closed conﬁguration

is a well-formed conﬁguration in which no expression name appears free in f or

σ.

We observe that a closed conﬁguration in R

sos

Orc

is also a closed conﬁguration

in R

red

Orc

and vice versa. This is due to the fact that both R

sos

Orc

and R

red

Orc

use

the same semantic infrastructure. Moreover, we have the following easy lemma.

Lemma 2 (Preservation of closed conﬁgurations). Let C be a closed conﬁgura-

tion. If R

sos

Orc

⊢C→

′

for some conﬁguration C

′

,thenC

′

is closed. Similarly,

if R

red

Orc

⊢C→

′

,thenC

′

is closed.

Proof. This can be proved by rule induction on the rewriting relations induced

by R

sos

Orc

and R

red

Orc

, respectively.

Intuitively, preservation of well-formedness is trivial in both R

sos

Orc

and R

red

Orc

by a quick examination of the rewrite rules. It is also easy to see that closed

conﬁgurations in R

sos

Orc

rewrite to conﬁgurations that are also closed. Essentially,

the only rule in R

sos

Orc

that might introduce expression names in an expression

is the [Def] rule. But since all expression declarations are closed (have no

free occurrences), and since actual parameters cannot be expression names, the

resulting expression must also be closed. A similar argument also applies to

red

Orc

. In what follows, we assume all conﬁgurations are closed.

The following lemma states that the deﬁnitions of eager conﬁgurations in

sos

Orc

and R

red

Orc

coincide. The lemma is an easy consequence of the fact that

the deﬁnitions of the eager predicate, the mte function, active and inactive

expressions, messages, and auxiliary functions for the time domain and handle

names, are all shared in the same semantic infrastructure given by R

Ω

Lemma 3 (Timing strategy equivalence). For any conﬁguration C, R

sos

Orc

⊢

eager(C)=trueiﬀ R

red

Orc

⊢ eager(C)=true,and,similarly,R

sos

Orc

⊢ mte(C)=t

iﬀ R

red

Orc

⊢ mte(C)=t, for any t ∈ Time.

Now we are ready to present the equivalence theorem, for which a detailed

proof can be found in Appendix A.

Theorem 4. For any conﬁgurations C and C

′

, the following equivalence holds,

sos

Orc

⊢ smallstep(·C) →

smallstep(·C

′

) ⇐⇒ R

red

Orc

⊢C→

′

The main result of this section can be derived as a consequence of Theo-

rem 4 by taking as C the initial conﬁguration of a program P given by [P ] (see

Section 4.3).

Corollary 1. For any Orc program P and conﬁguration C, we have

sos

Orc

⊢ [P ] →

smallstep(·C) ⇐⇒ R

red

Orc

⊢ [P ] →

Proof. Immediate from Theorem 4 and the fact that [P ] is closed.

timeout priority par-or timed-m BCast CList

sos

Orc

rewrite 1.0 1.0 8.0 14.0 3.0 10.0

search 1.0 2.0 84.0 326.0 5,492.0 6.0 × 10

red

Orc

rewrite 1.0 1.0 1.0 1.0 1.0 1.0

search 1.0 1.0 3.0 4.0 56.0 4.7 × 10

Table 1: A performance comparison of the rewriting semantics of Orc using Maude’s rewrite

and search commands (times in milliseconds)

Problem Size 2 3 4 5

sos

Orc

22.0 2,423.0 4.8 × 10

∞

red

Orc

3.0 107.0 3,230.0 1.6 × 10

Table 2: A performance comparison of the rewriting semantics of Orc using Maude’s LTL model

checker applied to four instances of the dining philosophers problem (times in milliseconds)

6.6. Performance Comparison

Despite being bisimilar, the reduction rewriting semantics given by R

red

Orc

enjoys a signiﬁcant performance advantage over the SOS-based rewriting se-

mantics given by R

sos

Orc

. This section validates this claim by comparing the

formal simulation and analysis performance of the two rewrite theories through

their speciﬁcations as system modules in Maude.

Throughout all experiments, performance is measured in terms of the CPU

time – in milliseconds – taken to perform a particular task as reported by

Maude. The tasks are: (1) simulating six Orc programs using Maude’s rewrite

command, (2) exploring the state space of these six programs using Maude’s

breadth-ﬁrst search command, and (3) model checking deadlock-freedom in

four problem instances of a deadlock-free speciﬁcation of the the dining philoso-

phers problem using Maude’s LTL model checker. The Orc programs used as

benchmarks for these tasks were borrowed from, or inspired by, examples in [61].

In particular, timeout, which was also given in Section 3.2, priority,which

prioritizes a site call over another, par-or, which speciﬁes a parallel (lazy) dis-

junction function, and timed-m, which makes four timed calls to a site, were all

borrowed from [61]. The Orc programs BCast, which implements a sequential

broadcast, and CList, which constructs in parallel a tuple of responses from ex-

ternal sites with timeout, were both inspired by [61]. The expression deﬁnitions

for BCast and CList are given in Appendix B. For the dining philosophers

benchmark, we use the deadlock-free speciﬁcation given in [61]. For simplicity,

we assume no message delays for all the benchmarking tasks above.

The results of these experiments, which were carried out on a 2.93GHz quad-

core machine with 24GB of memory using Maude 2.6, are summarized in Ta-

bles 1 and 2. The results clearly show that the reduction semantics of Orc

is much more eﬃciently executable than the SOS-based semantics, especially

when considering complex Orc expressions (having a large number of parallel

compositions). The performance gap is more evident when using the search

command, since searching builds proofs of all reachable states. In addition to

having fewer and simpler rewrite rules in R

red

Orc

, attempts to apply the instan-

taneous action rules in R

red

Orc

never fail (as can be veriﬁed by Maude’s proﬁler)

since transition steps corresponding to instantaneous actions are speciﬁed only

by two rules that match active expressions for internal actions (the rule labeled

IAction), and inactive expressions for the external action of site return (the

SiteReturn rule). This signiﬁcantly reduces the need for backtracking-like

behaviors when (recursively) searching for proofs of rewrite conditions, which

is characteristic of the SOS-based semantics. Finally, the performance advan-

tage of R

red

Orc

is even more pronounced in the model checking experiments of the

notoriously non-deterministic dining philosophers speciﬁcation, as shown by Ta-

ble 2. For the SOS-based semantics, the model checker did not ﬁnish within a

reasonable amount of time for the problem instance with ﬁve philosophers

7. The MOrc To ol

MOrc is a web-based formal speciﬁcation and analysis tool for Orc programs

based on Real-Time Maude (RTM) and the real-time rewriting logic speciﬁca-

tion of Orc, R

red

Orc

. MOrc provides a user-friendly interface for specifying the

Orc program or expression to be analyzed, any sites and their deﬁnitions, and

the desired formal analysis task and its parameters. The tool supports three

kinds of formal analyses: (1) simulation, (2) untimed and timed breadth-ﬁrst

search, and (3) untimed and time-bounded model-checking. The tool is de-

signed to balance both simplicity and expressiveness by supporting user inputs

in standard Orc notation, hiding interactions with RTM, and providing generic

templates for specifying parametric predicates (for both searching and model-

checking), using which a wide range of formal properties can be speciﬁed. MOrc

can be accessed online at http://www.ccse.kfupm.edu.sa/

musab/morc.

7.1. Components of MOrc

MOrc is implemented as a dynamic web-based application with both: (1) a

front-end client process (implemented using Javascript and the JQuery library)

to display appropriate interactive visual elements and manage interactions with

the user, and (2) a back-end server (implemented in PHP and C) that pre-

processes user input, handles communication with RTM, and post-processes

Maude’s output. The diagram in Figure 10 shows the main components of the

tool and illustrates their interactions.

The front-end of MOrc provides an intuitive interface for specifying inputs

and displaying analysis results. The main screen, shown in the screen-shot in

Figure 11, is divided into three main sections: (1) an Orc program/expression

and site input section, (2) a preloaded examples section, and (3) a tabbed analy-

sis input/output section. The user may wish to load, and then perhaps edit, one

It is important to note that, like the original SOS speciﬁcation of Orc, both rewriting

semantics are fairly detailed, operational semantics of Orc, and are, as a result, vulnerable to

the state space explosion problem, when using the search or LTL model checking commands,

particularly for programs with increasing levels of non-determinism.

MOrc is actually based on an object-oriented extension of R

red

Orc

, which is explained in [7].

Orc parser

Orc

program P

Analysis

parameters A

Request

object

Orc Front-end

(Web client)

Orc Back-end

(Web server)

Orc code

generator

AST(P)

Real-Time

Maude

Maude input

pre-processor

Maude term

T(P)

Maude module

& analysis command

Maude output

post-processor

Maude output

Response

object

Processed

output

User-accessible

analysis results

Figure 10: The architecture of MOrc

of the examples by clicking on it on the right panel, or he/she may specify an

entirely diﬀerent Orc program/expression, essentially using the mathematical

notation of the syntax of Orc deﬁned in Section 3.1 (a more precise deﬁnition

of MOrc-admissible Orc syntax is given in [7]). Furthermore, custom sites can

be deﬁned in the “Custom Sites” panel of the program input area by deﬁning

the site’s name, its parameters, and the values it may publish (only functional

sites can currently be user-deﬁned). Finally, the formal analysis section presents

a tabbed interface with three tabs corresponding to the three analysis modes

supported, namely, simulation, search, and model-checking. Each tab provides

a customized panel for specifying analysis parameters for the corresponding

analysis mode (described below in Section 7.2).

Upon specifying the analysis parameters, the front-end constructs a request

object (in Javascript Object Notation format, or JSON) encapsulating all rel-

evant input parameters, submits it to the back-end server, and waits for a re-

sponse. As illustrated in Figure 10, the back-end server passes the Orc program

text P to a parser and a code generator (both written in C) to build the Maude

term T (P ) corresponding to the initial state of P .ThetermT (P ), along with

the user-supplied analysis parameters, is then fed into a RTM pre-processor

that is responsible for generating the appropriate RTM formal analysis com-

mand and, for searching and model-checking, a user module that extends the

RTM Orc module ORC with custom predicates capturing the analysis param-

eters. After that, the generated module and command are supplied to RTM

for execution. The analysis output of RTM is parsed and processed b efore a

server, JSON-encoded object is created and sent to the client. When the client

receives the server response object, the front-end replaces the analysis panel in

the user interface with a results panel that displays in a structured way the

analysis results extracted from the response object.

Figure 11: The main screen of MOrc’s front-end

7.2. Formal Analysis Using MOrc

Simulation. The simulation analysis panel implements RTM’s timed rewrite

command trewrite. The panel may optionally specify limits on the simulation

task, which is particularly useful for simulating non-terminating Orc programs.

The possible simulation limits are: (1) a logical time limit, which speciﬁes an

upper bound on the logical time value of the state of the program; (2) a pub-

lications limit, which speciﬁes an upper bound on the number of publications

allowed; and (3) a rewrite steps limit, which speciﬁes an upper bound on the

number of transitions allowed in the semantics of Orc (where a transition is

either a site call, an expression call, the publishing of a value, a site return, or a

time tick). If more than one limit is speciﬁed, simulation proceeds until at least

oneofthelimitsisreached. Asanexample,wecanloadtheMetronome ex-

ample, whose declaration was given in Section 3.2, from the “Examples” panel

on MOrc’s interface:

Metronome(t) := let(signal) | rtimer(t) >> Metronome(t) .

Metronome(5)

Giving a logical time limit of 20 time units, and a publications limit of 2

causes the simulation to stop once the second publication of signal is made

at logical time 5, with the resulting Orc expression being of the form: ?h >>

Metronome(5). This generally corresponds to the following analysis command

in RTM (where 2 is the speciﬁed publication limit):

(trew {[Metronome(t) := let(signal) | rtimer(t) >> Metronome(t) ;

Metronome(5), 2]} in time <= 20 .)

Finally, a timeout in seconds (which is available in all three analysis panels)

must be speciﬁed to guard against having simulations running forever. For

instance, running the simulation command on Metronome without specifying

any simulation limit causes the tool to display a timeout message.

Search. The search analysis panel implements the breadth-ﬁrst search

command of RTM, which is either timed (using tsearch), or untimed (using

utsearch). Timed search takes into account explicit time-stamps of states, and

allows reasoning about timed properties of Orc programs, such as the number

of publications within the ﬁrst t time units, the time at which a speciﬁc value

is published, and whether a pattern is reachable by a given timeout. When

timed search is selected, the user may specify the search time bound, or leave

it unspeciﬁed for a timed search with no time limit. Untimed search, on the

other hand, ignores time-stamps on states, allowing only untimed properties to

be speciﬁed and checked.

To perform a search, the user typically provides an Orc expression pattern

that a solution state must satisfy. If speciﬁed, the search command will look for

states whose Orc expression components match at the top the given pattern.

An Orc expression pattern can b e either a concrete Orc expression, for example

let(x) and if(x == y) >> let(true),orasymbolic pattern containing pat-

tern meta-variables ranging over terms of appropriate types. Syntactically, a

pattern meta-variable is an identiﬁer of the form $[A-Z][A-Z]?[0-9]*,where

the preﬁx dollar sign $ distinguishes pattern meta-variables from Orc variables,

and the ﬁrst one or two uppercase letters specify the type of the terms over

which the pattern meta-variable ranges (refer to MOrc’s site for supported

meta-variables). For example, the pattern $F>$X>$Fmatches a sequen-

tial composition of two identical sub-expressions, while the pattern $M($VL) |

$E(1, $P) matches a parallel composition of an enabled site call and an ex-

pression call with two parameters, the ﬁrst of which is the value 1. Pattern

meta-variables, which are internally translated into Maude meta-variables of

appropriate sorts, enable symbolic reachability analysis without requiring users

of MOrc to b e familiar with the underlying Maude syntax.

In addition to Orc expression patterns, semantic constraints on publications

of Orc values can also be speciﬁed when using search. First, the reachable state

space of an Orc program can be constrained by giving an upper bound on the

number of publications allowed. Furthermore, it is possible to specify timed

constraints (for timed search) or untimed constraints (for untimed search) on

what values are published (Type I constraints) or the number of values pub-

lished (Type II constraints) in a state. MOrc provides two generic templates,

corresponding to both types, for the speciﬁcation of such constraints, which are

internally translated into state predicates in RTM. For example, a timed Type I

constraint may be that the Orc program must have published a signal within

the ﬁrst ﬁve time units of its execution, whereas an untimed Type II constraint

may require that the program must have published at least two values. The user

may specify as many such constraints as desired through MOrc’s interface. For

a search task, the solution states will have to satisfy all the speciﬁed publication

constraints (i.e., the conjunction of the corresponding state predicates in RTM).

As an example, consider the Delayed Response example from the list of

examples on the right pane, which is sp eciﬁed as:

DelayedResponse(x,t) := rtimer(t) >> let(z)<z<x().

DelayedResponse(clock, 5) | let(signal)

Using timed search with a strict upper bound of 5 time units (i.e. t<5),

and using the default values for the other search parameters, we may verify

the simple invariant that the site response from clock (which is the value 0)

is never published before 5 time units have passed. This can be achieved by

giving a Type I constraint that looks for states with time-stamps less than 5

in which the value 0 has been published, and making sure that no solution

is found. This generally corresponds to issuing the following RTM command

(where pubValue? is a predicate modeling Type I constraints):

(tsearch [10] {[DelayedResponse(x,t) := rtimer(t) >> let(z)<z<x();

DelayedResponse(clock, 5) | let(signal)]}

=>+ {CF:Configuration} such that pubValue?(CF:Configuration, 0, ltr, 5)

intime<5.)

LTL Model-checking. The model checking analysis panel implements the

linear temporal logic (LTL) model checking command mc of RTM. As for search,

model checking is either untimed, so that state time-stamps are abstracted away,

or time-bounded, (normally) with a given time bound. The LTL property to be

veriﬁed in MOrc can b e either the generic absence-of-deadlock property, or

a custom, user-deﬁned formula, typically based on user-deﬁned atomic predi-

cates. MOrc provides three generic templates for specifying named, parametric

atomic predicates: (i) expression pattern predicate, which speciﬁes a predicate

that is true in a state whose expression component matches at the top the given

pattern; (ii) publication predicate, which speciﬁes a predicate that is true in a

state in which the given value is published within the given time constraints;

and (iii) publication length predicate, which speciﬁes a predicate that is true in

a state in which at least the given number of publications are made within the

given time constraints. Furthermore, an upper bound on the number of publi-

cations (for time-bounded model-checking) may optionally b e speciﬁed, which

restricts the analysis to the subset of the reachable state space satisfying this

bound. The LTL formula ﬁeld, which is a required ﬁeld when specifying a custom

formula, allows specifying an LTL formula that may make use of user-deﬁned

atomic predicates (see [7] for the syntax of LTL formulas).

We illustrate how the model-checking interface panel may be used by means

of a speciﬁcation in Orc of Fischer’s protocol with two processes, which is a

timed, shared-variable-based, synchronization protocol (assuming atomic reads

and writes) for controlling multi-process access to a critical section [43]. The

speciﬁcation in Orc, which can be found in the Examples panel in MOrc by the

name FP

, uses two sites: (1) shared, which represents the shared (synchro-

nization) variable, which can be set to a positive value, reset to 0, or waited on

(for a possibly unbounded amount of time) to be reset again; and (2) csection,

which represents the critical section and blocks, when called, for a ﬁxed (ﬁnite)

period of time before responding. The mutual exclusion property can b e veriﬁed

in FP

using untimed model checking of the formula: [] ~ (cs1 /\ cs2),

where [] denotes the LTL “always” operator, ~ the negation operator, /\ the

conjunction operator, and where cs

,fori ∈{1, 2}, are user-deﬁned atomic

predicates speciﬁed using pattern expressions of the form csection(i)>>$F1

| $F2. Alternatively, time-bounded model checking (with a reasonable time

bound) may also be used to verify this property up to the given bound. An-

other important property that is desired in such a protocol is absence of livelock,

so that some progress is being made by either process in the protocol. This can

be veriﬁed by model checking the formula: [] <> (cs1 \/ cs2),where<>

denotes the LTL “eventually” operator and \/ is for disjunction.

8. Related Work

Rewriting Logic Semantics Project. Several recent research projects

within the rewriting logic semantics project [56, 73, 58], which are closely related

to this work, have been conducted. For example, a formal framework for the

speciﬁcation and analysis of timing properties in software design based on RTM

was presented at [2]. The framework uses a ﬂexible intermediate language with

timeouts to specify software components in a design, and allows for both static

analysis (using abstract interpretations) and dynamic analysis (searching and

model checking) of timed properties. Another recent example is a RTM-based

tool for specifying and analyzing synchronous, real-time embedded software sys-

tems in Ptolemy II [9]. The tool implements a code generation infrastructure,

similar to MOrc’s, minimizing exposure to the underlying Maude model. A

third example, also for embedded software components, but with emphasis on

safety-critical systems, is given in [65], where an object-based, formal semantics

of a behavioral subset of AADL in RTM is used as a formal analysis back-end

for AADL speciﬁcations. This last work has been extended in [8, 10] to han-

dle synchronous AADL models. For a recent survey of these and several other

examples, the reader is referred to [54].

Formal Semantics of Orc. In addition to the operational SOS seman-

tics of Orc in [61] and its timed SOS extension in [82], several denotational

formalizations of Orc’s semantics, which are better suited for reasoning about

algebraic properties in the language than for describing the operational behavior

of Orc programs, have been developed [37, 40, 69]. The deﬁnitive work on Orc is

the upcoming [60], which gives a thorough treatment of the Orc semantics, the

Orc language, and its powerful features for structured concurrent programming.

Encodings of Orc in some other formal models of concurrency, including encod-

ings in the π-calculus [23], Petri nets and the join calculus [17], and networks

of timed automata [24, 25], were also given, indirectly providing formal seman-

tics to Orc and highlighting some of its semantic subtleties. The SOS-based

rewriting semantics of Orc, along with some of the operational approaches cited

above, has similarities with the various SOS semantics that have been given for

diﬀerent timed process calculi, such as ATP [63] and TLP [36], and real-time

extensions to various process calculi, such as extensions of ACP [11, 12], CCS

[20], and CSP [72].

Formal Analysis of Service Compositions. Over the last few years,

the problem of formally specifying and verifying service compositions has been

approached in several diﬀerent ways. Below, we selectively highlight some of

the most relevant approaches.

An automata-theoretic approach, which was prop osed in [24, 25] (using a

compositional partial order reduction technique to improve performance [76]),

leverages available model checking tools for timed automata models, namely

Uppaal [13], by modeling the semantics of an Orc expression as a network of

timed automata. Unlike MOrc, the resulting Uppaal-based tool enables formal

veriﬁcation of only a subset of Orc with limited recursion, where the numb er of

threads in an Orc expression is ﬁxed. A fundamentally similar approach, but

based on an abstraction of BPEL activities instead of Orc, is used in [38], where

an abstracted BPEL process is transformed into a network of Web Service Timed

Transition Systems (WSTTS), which are essentially timed automata tailored

in design for web service compositions. An implementation of the underlying

model enables model checking analysis of timed properties, which are speciﬁed in

discrete-time Duration Calculus. In comparison to the rewriting-based approach

of the paper, automata-based methods are limited in expressiveness and are, as

a result, insuﬃcient for modeling the full generality of service compositions.

Models of service compositions using Petri nets, and their extensions, have

been developed. Most of these approaches, such as [35, 84, 75], tend to ﬁrst

deﬁne a process calculus in which service composition constructs are speciﬁed,

and give such constructs formal semantics as Petri nets. Correctness of com-

position speciﬁcations can then be veriﬁed using standard reachability analysis

methods for Petri net models. A fairly recent, introductory b ook on modeling

business processes using Petri nets is also available [77].

Several other (non-Petri-net-based) process-algebraic approaches to service

composition speciﬁcation were developed. The general theme of these methods

is to ﬁrst specify a process calculus with specialized constructs for the targeted

aspects of a service composition, like persistent sessions, error handling (ex-

ceptions), or security properties, and then develop their formal semantics in

some form of a transition system, on which formal veriﬁcation is based. Exam-

ples of such eﬀorts, many of which were partially supported by the Sensoria

project [83], include: (1) Service-Centered Calculus (SCC) [14], an Orc-inspired

process calculus of service compositions with persistent sessions; (2) Stream-

based Service Centered Calculus (SSCC) [44], an SCC-insipred calculus for mod-

eling orchestrations and conversations; (3) Service Oriented Computing Kernel

(SOCK) [33], which deﬁnes a layered process calculus for modularly specifying

service behaviors, service sessions, and service compositions; (4) the Calculus

for Orchestration of Web Services (COWS) [45], a timed process calculus with

termination constructs; (5) Event Calculus for Web Services [34], a process cal-

culus with events and event scopes for error handling; and (6) Signal Calculus

(SC) [29], a variant of the Ambient Calculus [19] for event-notiﬁcation-based

service coordination. Most of these calculi emphasize expressiveness and con-

ciseness by providing constructs that capture diﬀerent aspects of services, and

demonstrate them with examples. It is not clear, however, how mechanizable

such formalisms are for performing automatic formal analysis. Bruni [15] pro-

vided a survey of such process-calculus-based approaches, and described one of

his own, called the Calculus of Sessions and Pipelines (CaSPiS) [15, 16], which is

a calculus for describing service sessions and their interactions. Further related

work on formal analysis of service compositions given in [31] uses game-theoretic

methods to formally analyze uncertainty in the behaviors of service orchestra-

tions (expressed in Orc) under bursts of demand.

Other approaches that are based directly on BPEL (and related industrial

languages) have also been proposed. Given the fact that BPEL and similar

languages are descriptive and verbose, and lack any sort of formal semantics,

these approaches essentially try to provide formalizations of (subsets of) these

industrial languages in some formal model of computation, like BPEL encodings

in Petri Nets [47], the π-calculus [48], Event Calculus [71], and Message Sequence

Charts [30]. Alternatively, they may devise new BPEL-inspired core languages

for service orchestrations that capture some of BPEL’s salient features, such

as transactions and process termination, including, for example, Blite [46], and

the BPEL-based process calculi of [79] and [1], focusing on studying correlations

between orchestration processes within service choreographies. Nevertheless, as

a result of BPEL’s complexity and expansive feature-set, a comprehensive and

practical BPEL-based formal framework for the speciﬁcation and veriﬁcation of

service orchestrations remains elusive.

9. Conclusion

Orc [59, 61, 82] is a very powerful calculus and language for concurrent pro-

gramming combining great simplicity and mathematical elegance with practical

applicability to a wide range of concurrent programming areas. Its semantics

is a matter of great importance for theoretical, veriﬁcation, and implementa-

tion purposes. However, Orc’s semantics is subtle, due to its real-time aspects

and to the distinction between internal and external computation. Faithfully

capturing the Orc semantics is therefore a nontrivial challenge for a semantic

framework. Furthermore, the real goal should be not just capturing a “paper

semantics,” but obtaining an executable one from which interpreters, language

implementations, and program analysis tools can be derived, essentially for free.

In this work we have shown that the semantic framework of rewriting logic

[52] and its support for speciﬁcation of both concurrency and real-time com-

putation [64] can naturally and elegantly capture all the aspects of the Orc

semantics in an executable way. As a side eﬀect, we have also obtained a new

formulation of Orcs’s synchronous SOS that naturally captures with a single

transition relation what required two diﬀerent transition relations in [61]. For

eﬃciency reasons we have also developed a reduction style semantics strongly

bisimilar to the single-step style semantics, but vastly superior in eﬃciency.

This is of great practical importance to make semantics-based Orc tools such as

interpreters and model checkers much more eﬃcient.

An important practical result of this work is the development of the MOrc

semantics-based interpreter and mo del checker. MOrc hides from the user the

underlying Real-Time Maude tool where Orc programs are executed and model

checked by providing a user interface where only acquaintance with Orc itself

is required. This is an instance of a general methodology within the rewriting

logic semantics project [51, 56, 57], where formal methods are hidden “under

the hood,” so that a language user can perform sophisticated program analyses

without having to be familiar with the underlying formalism (see [27, 9, 8] for

other examples of similar Maude-based program analysis tools whose formal

underpinnings are hidden “under the hood”).

Acknowledgements. We thank Professor Jayadev Misra and all the members

of the Orc team at the University of Texas at Austin for explaining to us many

details of Orc and its language implementation, and for their very helpful com-

ments on, and encouragement of, the research presented here. We also thank

the anonymous reviewers for their valuable comments and suggestions. This

work was partially supported by KFUPM Grant JF121005, AFOSR Contract

FA8750-11-2-0084 and NSF Grants CCF 09-05584 and CNS 13-19109.

References

[1] Faisal Abouzaid and John Mullins. Formal speciﬁcation of correlation in

WS orchestrations using BP-calculus. Electronic Notes in Theoretical Com-

puter Science, 260:3 – 24, 2010. Proceedings of the 5th International Work-

shop on Formal Aspects of Component Software (FACS 2008).

[2] Musab AlTurki, Dinakar Dhurjati, Dachuan Yu, Ajay Chander, and Hi-

roshi Inamura. Formal speciﬁcation and analysis of timing properties in

software systems. In Marsha Chechik and Martin Wirsing, editors, Funda-

mental Approaches to Software Engineering, volume 5503 of Lecture Notes

in Computer Science, pages 262–277. Springer, 2009.

[3] Musab AlTurki and Jos´e Meseguer. Real-time rewriting semantics of Orc.

In PPDP ’07: Proceedings of the 9th ACM SIGPLAN international sympo-

sium on Principles and practice of declarative programming, pages 131–142,

New York, NY, USA, 2007. ACM Press.

[4] Musab AlTurki and Jos´e Meseguer. Rewriting logic semantics of Orc.

Technical Report UIUCDCS-R-2007-2918, University of Illinois at Urbana

Champaign, November 2007. http://hdl.handle.net/2142/11410.

[5] Musab AlTurki and Jos´e Meseguer. Reduction semantics and formal anal-

ysis of Orc programs. Electron. Notes Theor. Comput. Sci., 200(3):25–41,

2008.

[6] Musab AlTurki and Jos´e Meseguer. Dist-Orc: A rewriting-based dis-

tributed implementation of Orc with formal analysis. In The 1st In-

ternational Workshop on Rewriting Techniques for Real-Time Systems

(RTRTS), Longyearbyen, Spitsbergen, Norway, April 2010.

[7] Musab AlTurki and Jos´e Meseguer. Executable rewriting logic semantics

of Orc and formal analysis of Orc programs. Technical report, University

of Illinois at Urbana Champaign, September 2012. http://hdl.handle.

net/TBD.

[8] Kyungmin Bae, Peter Csaba

Olveczky, Abdullah Al-Nayeem, and Jos´e

Meseguer. Synchronous AADL and its formal analysis in Real-Time Maude.

In Shengchao Qin and Zongyan Qiu, editors, Proceedings of the 13th Inter-

national Conference on Formal Engineering Methods (ICFEM) 2011, vol-

ume 6991 of Lecture Notes in Computer Science, pages 651–667. Springer,

2011.

[9] Kyungmin Bae, Peter Csaba

Olveczky, Thomas Huining Feng, Edward A.

Lee, and Stavros Tripakis. Verifying hierarchical Ptolemy II discrete-event

models using Real-Time Maude. Sci. Comput. Program., 77(12):1235–1271,

2012.

[10] Kyungmin Bae, Peter Csaba

Olveczky, Jos´e Meseguer, and Abdullah Al-

Nayeem. The SynchAADL2Maude tool. In Juan de Lara and Andrea

Zisman, editors, FASE , volume 7212 of Lecture Notes in Computer Science,

pages 59–62. Springer, 2012.

[11] J. C. M. Baeten and J. A. Bergstra. Real time process algebra. Formal

Aspects of Computing, 3(2):142–188, 1991.

[12] J. C. M. Baeten and Cornelis A. Middelburg. Process algebra with timing;

Monographs in theoretical computer science. Springer, Berlin; New York,

2002.

[13] G. Behrmann, A. David, and K. G. Larsen. A tutorial on UPPAAL. In

Marco Bernardo and Flavio Corradini, editors, International School on

Formal Methods for the Design of Computer, Communication and Software

Systems (SFM-RT), volume 3185 of Lecture Notes in Computer Science,

pages 200–236. Springer, 2004.

[14] M Boreale, R Bruni, L Caires, R De Nicola, I Lanese, M Loreti, F Martins,

U Montanari, A Ravara, and D Sangiorgi. Scc: a service centered calculus.

Lecture notes in computer science, 4184:38, 2006.

[15] Roberto Bruni. Calculi for service-oriented computing. In Proceedings of

SFM’09, volume 5569 of LNCS, pages 1–41. Springer, 2009.

[16] Roberto Bruni, Andrea Corradini, Fabio Gadducci, Alberto Lluch-

Lafuente, and Ugo Montanari. Hierarchical models for service-oriented

systems. In Martin Wirsing and Matthias M. H¨olzl, editors, Results of the

SENSORIA Project, volume 6582 of Lecture Notes in Computer Science,

pages 349–368. Springer, 2011.

[17] Roberto Bruni, Hern´an Melgratti, and Emilio Tuosto. Translating Orc

features into Petri nets and the Join calculus. In Mario Bravetti, Manuel

N´u˜nez, and Gianluigi Zavattaro, editors, Web Services and Formal Meth-

ods, volume 4184 of Lecture Notes in Computer Science, pages 123–137.

Springer, 2006.

[18] Roberto Bruni and Jos´e Meseguer. Semantic foundations for generalized

rewrite theories. Theor. Comput. Sci., 360(1-3):386–414, 2006.

[19] Luca Cardelli and Andrew D. Gordon. Mobile ambients. Theor. Comput.

Sci., 240(1):177–213, 2000.

[20] Liang Chen. An interleaving model for real-time systems. In TVER ’92:

Proceedings of the Second International Symposium on Logical Foundations

of Computer Science, pages 81–92, London, UK, 1992. Springer-Verlag.

[21] Manuel Clavel, Francisco Dur´an, Steven Eker, Patrick Lincoln, Narciso

Mart´ı-Oliet, Jos´e Meseguer, and Carolyn Talcott. All About Maude - A

High-Performance Logical Framework, volume 4350 of LNCS. Springer-

Verlag, Secaucus, NJ, USA, 2007.

[22] William Cook, Sourabh Patwardhan, and Jayadev Misra. Workﬂow pat-

terns in Orc. In Paolo Ciancarini and Herbert Wiklicky, editors, Coordi-

nation Models and Languages, volume 4038 of Lecture Notes in Computer

Science, pages 82–96. Springer Berlin / Heidelberg, 2006.

[23] William R. Cook and Jayadev Misra. A structured orchestration lan-

guage, July 2005. http://www.cs.utexas.edu/users/wcook/Drafts/

OrcCookMisra05.pdf.

[24] Jin Song Dong, Yang Liu, Jun Sun, and Xian Zhang. Veriﬁcation of com-

putation orchestration via timed automata. In Zhiming Liu and Jifeng

He, editors, Formal Methods and Software Engineering, 8th International

Conference on Formal Engineering Methods, ICFEM 2006, Macao, China,

November 1-3, 2006, Proceedings, volume 4260 of Lecture Notes in Com-

puter Science, pages 226–245. Springer, 2006.

[25] JinSong Dong, Yang Liu, Jun Sun, and Xian Zhang. Towards veriﬁcation of

computation orchestration. Formal Aspects of Computing, 26(4):729–759,

2014.

[26] Chucky Ellison and Grigore Rosu. An executable formal semantics of c with

applications. In John Field and Michael Hicks, editors, Proceedings of the

39th ACM SIGPLAN-SIGACT Symposium on Principles of Programming

Languages, POPL 2012, Philadelphia, Pennsylvania, USA, January 22-28,

2012, pages 533–544. ACM, 2012.

[27] A. Farzan, F. Cheng, J. Meseguer, and G. Ro¸su. Formal analysis of Java

programs in JavaFAN. In Proc. CAV’04, volume 3114 of LNCS, 2004.

[28] Azadeh Farzan, Jos´e Meseguer, and Grigore Ro¸su. Formal JVM code anal-

ysis in JavaFAN. In Charles Rattray, Savitri Maharaj, and Carron Shank-

land, editors, Algebraic Methodology and Software Technology, volume 3116

of Lecture Notes in Computer Science, pages 132–147. Springer Berlin Hei-

delberg, 2004.

[29] Gian Luigi Ferrari, Roberto Guanciale, and Daniele Strollo. JSCL: A mid-

dleware for service coordination. In Proceedings of FOR TE’06, volume 4229

of Lecture Notes in Computer Science, pages 46–60. Springer, 2006.

[30] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based veriﬁcation of

web service compositions. In Automated Software Engineering, 2003. Pro-

ceedings. 18th IEEE International Conference on, pages 152 – 161, October

2003.

[31] Joaquim Gabarro, Maria Serna, and Alan Stewart. Analysing web-

orchestrations under stress using uncertainty proﬁles. The Computer Jour-

nal, July 2013.

[32] Joseph Goguen and J os´e Meseguer. Order-sorted algebra I: Equational

deduction for multiple inheritance, overloading, exceptions and partial op-

erations. Theoretical Computer Science, 105:217–273, 1992.

[33] C Guidi, R Lucchi, R Gorrieri, N Busi, and G Zavattaro. Sock: a calculus

for service oriented computing. Lecture notes in computer science, 4294:327,

2006.

[34] C Guidi, R Lucchi, and M Mazzara. A formal framework for web services

coordination. Electronic Notes in Theoretical Computer Science, 180(2):55–

70, 2007.

[35] R Hamadi and B Benatallah. A Petri net-based model for web service

composition. Proceedings of the 14th Australasian database conference-

Volume 17, pages 191–200, 2003.

[36] Matthew Hennessy and Tim Regan. A process algebra for timed systems.

Inf. Comput., 117(2):221–239, 1995.

[37] Tony Hoare, Galen Menzel, and Jayadev Misra. A tree semantics of an or-

chestration language. Engineering Theories of Software Intensive Systems,

pages 331–350, 2005.

[38] Raman Kazhamiakin, Paritosh Pandya, and Marco Pistore. Timed mod-

elling and analysis in web service compositions. In ARES ’06: Proceedings

of the First International Conference on Availability, Reliability and Secu-

rity, pages 840–846, Washington, DC, USA, 2006. IEEE Computer Society.

[39] D Kitchin, E Powell, and J Misra. Simulation using orchestration. Pro-

ceedings of AMAST, Jan 2008.

[40] David Kitchin, William R. Cook, and Jayadev Misra. A language for task

orchestration and its semantic properties. In CONCUR 2006, volume 4137

of Lecture Notes in Computer Science, pages 477–491. Springer, 2006.

[41] David Kitchin, Adrian Quark, William Cook, and Jayadev Misra. The

Orc programming language. In David Lee, Ant´onia Lopes, and Arnd

Poetzsch-Heﬀter, editors, Formal techniques for Distributed Systems; Proc.

of FMOODS/FORTE, volume 5522 of LNCS, pages 1–25. Springer, 2009.

[42] David Kitchin, Adrian Quark, and Jayadev Misra. Quicksort: Combining

concurrency, recursion, and mutable data structures. In A.W. Roscoe,

Cliﬀ B. Jones, and Kenneth R. Wood, editors, Reﬂections on the Work

of C.A.R. Hoare, History of Computing, pages 229–254. Springer London,

2010.

[43] Leslie Lamport. A fast mutual exclusion algorithm. ACMTrans.Comput.

Syst., 5:1–11, January 1987.

[44] Ivan Lanese, Francisco Martins, Vasco T. Vasconcelos, and Antonio Ravara.

Disciplining orchestration and conversation in service-oriented computing.

In Proceedings of the Fifth IEEE International Conference on Software

Engineering and Formal Methods, SEFM ’07, pages 305–314, Washington,

DC, USA, 2007. IEEE Computer Society.

[45] A Lapadula, R Pugliese, and F Tiezzi. Cows: A timed service-oriented

calculus. Lecture notes in computer science, 4711:275, 2007.

[46] A Lapadula, R Pugliese, and F Tiezzi. A formal account of WS-BPEL.

Lecture notes in computer science, 5052:199, 2008.

[47] Niels Lohmann. A feature-complete Petri net semantics for WS-BPEL 2.0.

In Proceedings of WS-FM’07, volume 4937 of Lecture Notes in Computer

Science, pages 77–91. Springer, 2008.

[48] R Lucchi and M Mazzara. A pi-calculus based semantics for WS-BPEL.

Journal of Logic and Algebraic Programming, 70(1):96–118, 2007.

[49] Patrick Meredith, Mark Hills, and Grigore Ro¸su. An executable rewriting

logic semantics of K-Scheme. In Danny Dube, editor, Proceedings of the

2007 Workshop on Scheme and Functional Programming (SCHEME’07),

Technical Report DIUL-RT-0701, pages 91–103. Laval University, 2007.

[50] Patrick O’Neil Meredith, Michael Katelman, Jos´e Meseguer, and Grigore

Ro¸su. A formal executable semantics of Verilog. In Eighth ACM/IEEE

International Conference on Formal Methods and Models for Codesign

(MEMOCODE’10), pages 179–188. IEEE, 2010.

[51] J. Meseguer and G. Ro¸su. Rewriting logic semantics: From language spec-

iﬁcations to formal analysis tools. In Proc. Intl. Joint Conf. on Automated

Reasoning IJCAR’04, Cork, Ireland, July 2004, pages 1–44. Springer LNAI

3097, 2004.

[52] Jos´e Meseguer. Conditional rewriting logic as a uniﬁed model of concur-

rency. Theor. Comput. Sci., 96(1):73–155, 1992.

[53] Jos´e Meseguer. Membership algebra as a logical framework for equational

speciﬁcation. In F. Parisi-Presicce, editor, Proc. WADT’97, volume 1376

of LNCS, pages 18–61. Springer, 1998.

[54] Jos´e Meseguer. Twenty years of rewriting logic. J. Log. Algebr. Program.,

81(7-8):721–781, 2012.

[55] Jos´e Meseguer and Christiano Braga. Modular rewriting semantics of

programming languages. Algebraic Methodology and Software Technology,

pages 364–378, 2004.

[56] Jos´e Meseguer and Grigore Rosu. The rewriting logic semantics project.

Theor. Comput. Sci., 373(3):213–237, 2007.

[57] Jos´e Meseguer and Grigore Rosu. The rewriting logic semantics project: A

progress report. In Olaf Owe, Martin Steﬀen, and JanArne Telle, editors,

Fundamentals of Computation Theory, volume 6914 of Lecture Notes in

Computer Science, pages 1–37. Springer, 2011.

[58] Jos´e Meseguer and Grigore Ro¸su. The rewriting logic semantics project: A

progress report. Information and Computation, 231(0):38–69, 10 2013.

[59] Jayadev Misra. Computation orchestration: A basis for wide-area comput-

ing. In Manfred Broy, editor, Proc. of the NATO Advanced Study Institute,

Engineering Theories of Software Intensive Systems, NATO ASI Series,

Marktoberdorf, Germany, 2004.

[60] Jayadev Misra. Structured Concurrent Programming. Manuscript, Univer-

sity of Texas at Austin, January 2013.

[61] Jayadev Misra and William R. Cook. Computation orchestration: A ba-

sis for wide-area computing. Journal of Software and Systems Modeling,

6(1):83–110, March 2007.

[62] Peter D. Mosses. Modular structural operational semantics. J. Log. Algebr.

Program., 60-61:195–228, 2004.

[63] X. Nicollin and J. Sifakis. The algebra of timed processes ATP: Theory

and application. Information and Computation, 114(1):131–178, 1994.

[64] P. C.

Olveczky and J. Meseguer. Semantics and pragmatics of Real-Time

Maude. Higher-Order and Symbolic Computation, 20(1-2):161–196, 2007.

[65] Peter

Olveczky, Artur Boronat, and Jos´e Meseguer. Formal semantics and

analysis of behavioral aadl models in real-time maude. In John Hatcliﬀ and

Elena Zucca, editors, Formal Techniques for Distributed Systems, volume

6117 of Lecture Notes in Computer Science, pages 47–62. Springer Berlin

/ Heidelberg, 2010.

[66] Peter Csaba

Olveczky. Real-Time Maude 2.3 manual, August 2007. http:

//heim.ifi.uio.no/

peterol/RealTimeMaude/.

[67] Peter Csaba

Olveczky and Jos´e Meseguer. Speciﬁcation of real-time and

hybrid systems in rewriting logic. Theoretical Computer Science, 285:359–

405, August 2002.

[68] Peter Csaba

Olveczky and Jos´e Meseguer. Abstraction and completeness

for Real-Time Maude. Electron. Notes Theor. Comput. Sci., 176(4):5–27,

2007.

[69] Sidney Rosario, David Kitchin, Albert Benveniste, William Cook, Stefan

Haar, and Claude Jard. Event structure semantics of Orc. In WS-FM

2007, volume 4937 of Lecture Notes in Computer Science, pages 154–168.

Springer, 2008.

[70] Grigore Rosu and Andrei Stefanescu. Matching logic: a new program ver-

iﬁcation approach. In Richard N. Taylor, Harald Gall, and Nenad Medvi-

dovic, editors, Proceedings of the 33rd International Conference on Software

Engineering, ICSE 2011, Waikiki, Honolulu , HI, USA, May 21-28, 2011,

pages 868–871. ACM, 2011.

[71] M Rouached, O Perrin, and C Godart. Towards formal veriﬁcation of web

service composition. Lecture notes in computer science, 4102:257, 2006.

[72] Steve Schneider, Jim Davies, D. M. Jackson, George M. Reed, Joy N. Reed,

and A. W. Roscoe. Timed CSP: Theory and practice. In Proceedings of the

Real-Time: Theory in Practice, REX Workshop, pages 640–675, London,

UK, 1992. Springer-Verlag.

[73] Traian Florin Serbanuta, Grigore Rosu, and Jos´e Meseguer. A rewriting

logic approach to operational semantics. Information and Computation,

207(2):305 – 340, 2009. Special issue on Structural Operational Semantics

(SOS).

[74] Mark-Oliver Stehr. CINNI — A generic calculus of explicit substitutions

and its application to λ-, ς-andπ-calculi. In Kokichi Futatsugi, editor,

Proceedings Third International Workshop on Rewriting Logic and its Ap-

plications, WRLA 2000, Kanazawa, Japan, September 18–20, 2000, vol-

ume 36 of Electronic Notes in Theoretical Computer Science, pages 71–92.

Elsevier, 2000.

[75] Jindian Su, Shanshan Yu, and Heqing Guo. Formal description and veri-

ﬁcation of web service composition based on oopn. In De-Shuang Huang,

Donald Wunsch, Daniel Levine, and Kang-Hyun Jo, editors, Advanced In-

telligent Computing Theories and Applications. With Aspects of Theoretical

and Methodological Issues, volume 5226 of Lecture Notes in Computer Sci-

ence, pages 644–652. Springer Berlin / Heidelberg, 2008.

[76] Tian Huat Tan, Yang Liu, Jun Sun, and Jin Song Dong. Veriﬁcation

of orchestration systems using compositional partial order reduction. In

Shengchao Qin and Zongyan Qiu, editors, ICFEM, volume 6991 of Lecture

Notes in Computer Science, pages 98–114. Springer, 2011.

[77] Wil van der Aalst and Christian Stahl. Modeling Business Processes: A

Petri Net Oriented Approach. MIT Press, Cambridge, MA, 2011.

[78] Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Bartek Kiepuszewski,

and Alistair P. Barros. Workﬂow patterns. Distrib. Parallel Databases,

14(1):5–51, 2003.

[79] Mirko Viroli. Towards a formal foundation to orchestration languages.

Electronic Notes in Theoretical Computer Science, 105:51 – 71, 2004. Pro-

ceedings of the First International Workshop on Web Services and Formal

Methods (WSFM 2004).

[80] Patrick Viry. Equational rules for rewriting logic. Theor. Comput. Sci.,

285(2):487–517, 2002.

[81] I Wehrman, D Kitchin, W Cook, and J Misra. Properties of the timed

operational and denotational semantics of Orc. Technical report, University

of Texas at Austin, 2007.

[82] Ian Wehrman, David Kitchin, William R. Cook, and Jayadev Misra. A

timed semantics of Orc. Theor. Comput. Sci., 402(2-3):234–248, 2008.

[83] Martin Wirsing, Rocco De Nicola, Stephen Gilmore, Matthias H¨olzl,

Roberto Lucchi, Mirco Tribastone, and Gianlugi Zavattaro. Sensoria pro-

cess calculi for service-oriented computing. In Proceedings of TGC’06, vol-

ume 4661 of Lecture Notes in Computer Science, pages 30–50, 2007.

[84] Wen Zhao, Yu Huang, Chongyi Yuan, and Lifu Wang. Formalizing business

process execution language based on Petri nets. In Intelligent Systems and

Applications (ISA), 2010 2nd International Workshop on, pages 1 –8, 22-23

2010.

Appendix A. Proof of the Equivalence Theorem (Theorem 4)

In this section, we refer to the theories R

sos

Orc

and R

red

Orc

respectively by R

and R

, and use C→

′

to denote R⊢C→

′

, for brevity and notational

convenience.

Proof. (=⇒) By induction on a proof of smallstep(·C) →

smallstep(·C

′

), which

is abbreviated below as (·C) →

(·C

′

). There are six base cases, corresponding

to the rules [SiteCall], [Publish], [Def], [SiteRetV], [SiteRetStop],and

[Tick] in R

• [SiteCall]:Ifh is a fresh handle with respect to a handle set η,and

(·M(v), lbl : l | msg : ρ | hdl : η | r)

→

(?h, lbl : Mv, h|msg : ρ[M,v, h] | hdl : η, h | r)

(·?h, lbl : ǫ | msg : ρ[M,v, h] | hdl : η, h | r)

then, by [IAction] (and [SiteCall])inR

, and using the substitution

′

→ γ,i → siteCall(M,v)},wehave

M(v), lbl : l | msg : ρ | hdl : η | r

→

act

↑

(γ,siteCall(M,v)), lbl : l | msg : ρ | hdl : η | r

act

↓

(γ,?h), lbl : ǫ | msg : ρ[M, v, h]) | hdl : η, h | r

?h, lbl : ǫ | msg : ρ[M,v, h] | hdl : η, h |r.

The base cases for the remaining internal actions, [Publish] and [Def],

are similar.

• [SiteRetV]: Suppose

(·?h, lbl : l | msg : ρ[v, h] | hdl : η, h | r)

→

(!v, lbl : h?v | msg : ρ | hdl : η | r)

(·!v, lbl : ǫ | msg : ρ | hdl : η | r).

Since ?h is an inactive expression and h ∈ handles(?h)=true is provable

from R

,weusetheruleSiteRet in R

(with the substitution {

f →?h})

to get:

?h, lbl : l | msg : ρ[v, h] | hdl : η, h | r

→

sret(?h, v, h), lbl : ǫ | msg : ρ | hdl : η | r

!v, lbl : ǫ | msg : ρ | hdl : η | r.

The base case for [SiteRetStop] is similar.

• [Tick]: Suppose

(·

f,clk : t | r) →

(

f,clk : t + t

′

| δ(r, t

′

)).

Then, R

proves t

′

= mte(C), which is non-zero, and eager(C) = true.By

Lemma 3, R

,too,provesthatthatt

′

is the maximum time elapse of C

and that C is not an eager conﬁguration. Therefore, by the Tick rule in

,wehave:



f,clk : t | r→



f,clk : t + t

′

| δ(r, t

′

).

For the inductive step, there are fourteen cases corresponding to the induc-

tive rules listed in Figure 7. We discuss below representative cases for symmetric

parallel and sequential compositions. The remaining cases for asymmetric par-

allel and otherwise compositions are similar.

• [SymI]. Suppose (·

f | g, lbl : l | r) →

(f

′

| g, lbl : i | r

′

), which is

equationally equivalent to (·f

′

| g, lbl : ǫ | r

′

), then we have

(·

f, lbl : ǫ | r) →

(f

′

, lbl : i | r

′

)=

(·f

′

, lbl : ǫ | r

′

).

By the inductive assumption, this implies 

f, lbl : ǫ | r→

f

′

, lbl :

ǫ | r

′

, by an application of [IAction] in R

such that there exists an ac-

tive base expression as a subexpression of

f. Therefore,

f →

act

↑

′′

,i),

with f

′′

f[p ← b], for some position p in

f and b is either tmp or 0,

depending on whether the internal action is a (site or expression) call

or a publishing of a value, respectively. By congruence, this implies

f | g →

act

↑

′′

,i) | g, which is equal to act

↑

′′

| g, i). If the ac-

tion i is a call, then by the rule [IAction]:



f | g, lbl : l | r→

act

↑

′′

| g,i), lbl : l | r

act

↓

′′

| g,e), lbl : ǫ | r

′



f

′

| g, lbl : ǫ | r

′



where e is a handle expresion if i is a site call, or the instantiation of a

body of an appropriate expression declaration if i is an expression call.

The remaining case when the action i is a publishing action is similar.

• [SymE].Letu be a site return label, and suppose

(·

f | ¯g, lbl : l | r) →

(f

′

| ¯g, lbl : u | r

′

)=

(·f

′

| ¯g, lbl : ǫ | r

′

).

Then (·

f, lbl : ǫ | r) →

(f

′

, lbl : u | r

′

)=

(·f

′

, lbl : ǫ | r

′

). By the

inductive assumption, this implies 

f, lbl : ǫ | r→

f

′

, lbl : ǫ | r

′

,by

an application of [SiteReturn] in R

such that there exists a handle base

expression of the form ?h as a subexpression of

f at some position p,that

a message [w, h] exists in the set of handles in the handles ﬁeld of r,and

that f

′

is either

f[p ← 0]or

f[p ←!v], depending on whether the return

value is a stop value or not, respectively. Therefore, by [SiteReturn],

we have:



f | g, lbl : l | r→

sret(

f | g, w, h), lbl : ǫ, | r

′



sret(

f,w,h) | sret(g, w,h), lbl : ǫ, | r

′



f

′

| g, lbl : ǫ, | r

′

.

• [Seq1V]. Suppose

(·

>x> g, lbl : l | r) →

((f

′

x> g) | [v/x]g, lbl : τ | r

′

)

which is equationally equivalent to (·(f

′

x> g) | [v/x]g, lbl : ǫ | r

′

).

Then, (·

f,lbl : ǫ | r) →

(f

′

, lbl :!v | r

′

)=

(·f

′

, lbl : ǫ | r

′

). By

the inductive assumption, this implies 

f,lbl : ǫ | r) →

(f

′

, lbl : ǫ | r

′



by an application of [IAction] in R

such that there exists a publishing

base expression of the form !v as a subexpression of

f and that v is not

bound in

f. Therefore,

f →

act

↑

′

, publish(v)), with f

′

f[p ← 0],

for some position p in

f. By congruence, this implies

>x> g →

act

↑

′

, publish(v)) >x> g, which is equal to act

↑

′

x> g | [v/x]g,publish

and, thus, by the rule [IAction]:



>x> g, lbl : l | r→

act

↑

′

x> g | [v/x]g,publish

), lbl : l | r

f

′

>x> g | [v/x]g, lbl : ǫ | r

′

.

• [Seq1NI]. Suppose

(·

>x> g, lbl : l | r) →

(f

′

>x> g, lbl : n | r

′

)

(·f

′

x> g, lbl : ǫ | r

′

)

for some internal, non-publishing label n. Then, (·

f,lbl : ǫ | r) →

(f

′

, lbl : n | r

′

)=

(·f

′

, lbl : ǫ | r

′

). By the induction hypothe-

sis, this implies 

f,lbl : ǫ | r) →

(f

′

, lbl : ǫ | r

′

 by an applica-

tion of [IAction] in R

such that

f has as a subexpression a base ex-

pression of one of the folowing forms: (i) a site call expression M(v),

(ii) an expression call expression E(p), or (iii) a publishing expression !v

with v bound in

f. For case (i),

f →

act

↑

tmp

, siteCall(M,v)), with

tmp

f[p ← tmp], for some position p in

f. By congruence, this im-

plies

>x> g →

act

↑

tmp

, siteCall(M,v)) >x> g, which is equal to

act

↑

tmp

x> g,siteCall(M,v)), and, thus, by the rule [IAction]:



f >x> g, lbl : l | r→

act

↑

tmp

x> g,siteCall(M,v)), lbl : l | r

act

↓

tmp

x> g,?h), lbl : ǫ | r

′



f

′

x> g, lbl : ǫ | r

′

.

Cases (ii) and (iii) can similarly be checked using IAction and the ap-

propriate equations in R

• [Seq1NE].Letu be a site return label, and suppose

(·

f >x> g, lbl : l | r→

f

′

x> g, lbl : u | r

′

)

(·f

′

>x> g, lbl : ǫ | r

′

).

Then, (·

f,lbl : ǫ | r→

f

′

, lbl : u | r

′

). By the induction hypothe-

sis, this implies 

f,lbl : ǫ | r→

f

′

, lbl : ǫ | r

′

 by an application of

[SiteReturn] in R

such that there exists a handle base expression of

the form ?h as a subexpression of

f at some position p, that a message

[w, h] exists in the set of handles in the handles ﬁeld of r,andthatf

′

either

f[p ← 0]or

f[p ←!v], dep ending on whether the return value is a

stop value or not, respectively. Therefore, we have by [SiteReturn]:



>x> g, lbl : l | r→

sret(

f >x> g,w, h), lbl : ǫ, | r

′



sret(

f,w,h) >x> g, lbl : ǫ, | r

′



f

′

>x> g, lbl : ǫ, | r

′

.

The inductive cases for [Asym2I] and [Asym2E] are, respectively, similar to

[SymI] and [SymE]. The cases for [Asym1V] and [OtherV] are similar to the

value publishing case of [Seq1V], while the cases for [Asym1NI] and [Oth-

erNI] are similar to the internal non-publishing case of [Seq1NI]. Finally, the

cases for the external site return action, namely [Asym1NEa], [Asym1NEb]

and [OtherNE] are similar to [Seq1NE].

(⇐=) If C→

′

is an instance of the [Tick] rule (i.e., C is not an eager

conﬁguration), then the implication holds trivially by the corresponding [Tick]

rule in R

by Lemma 3. So, suppose that the rewrite in the hypothesis is not

an instance of the tick rule. Then, we observe that it must be an instance

of an instantaneous action, which can either be an internal action (with the

[IAction] rule) or a site return action (using the [SiteReturn] rule). This

implies that the expression component f of C is either active or inactive (i.e.,

non-zero). To complete the proof, we proceed by induction on f.

If f is a base active expression (i.e. M(v), E(p), or !v), then the implication

holds easily by the equations in R

, the assumption that C is closed, and the

corresponding base rules ([SiteCall], [Def],and[Publish]) for these expres-

sions in R

. Similarly, if f is a base inactive expression, namely the handle

expression ?h, then the implication follows using the corresponding site return

rules in R

([SiteRetV] and [SiteRetStop], for the cases of returning an Orc

value or a stop value, respectively).

Suppose that the expression f is of the form f | g. If the hypothesis is an

instance of an internal action i, then, modulo commutativity, it must be of the

form



f | g, lbl : l | r→

f

′

| g, lbl : ǫ | r

′



with

f having as a sub-expression a base active expression at some position p.

Then,

f →

act

↑

′′

,i), with f

′′

f[p ← b], for some position p in

f and b is

either tmp or 0, depending on whether the internal action is a (site or expression)

call or a publishing of a value, respectively. By the equations deﬁning act

↑

for

internal actions, this implies 

f, lbl : ǫ | r→

f

′

, lbl : ǫ | r

′

,whichbythe

induction hypothesis implies (·

f, lbl : ǫ | r) →

(f

′

, lbl : i | r

′

), and thus

the conclusion holds by the rule SymI in R

. If the action is an instance of a

site return u, then the hypothesis is of the form:



f | ¯g, lbl : l | r→

f

′

| ¯g, lbl : ǫ | r

′



with

f having as a sub-expression a handle expression of the form ?h,andr

having in its messages ﬁeld an incoming message of the form [w, h], and in its

handles ﬁeld a handle h.Bythe[SiteReturn] rule and the equations deﬁning

sret for site return actions, this implies 

f, lbl : l | r→

f

′

, lbl : ǫ | r

′

.The

induction hypothesis, and the [SymE] rule in R

imply the desired conclusion.

Suppose f is of the form f >x> g. There are three cases. First, the hypoth-

esis may be an instance of a publishing action, and hence of the form



>x> g, lbl : l | r) →

((f

′

>x> g) | [v/x]g, lbl : ǫ | r

′



with

f having as a sub-expression a base publishing expression !v such that v

is not bound in

f.Bythe[IAction] and [Publish] rules, and the equations

deﬁning act

↑

for publishing actions, this implies 

f,lbl : ǫ | r) →

(f

′

, lbl :

ǫ | r

′

. By induction, and rule [Seq1V] in R

, the conclusion holds.

The second case is when the action is a non-publishing internal action (i.e.

asitecalloraτ action). In this case the hypothesis has the form:



>x> g, lbl : l | r→

f

′

>x> g, lbl : ǫ | r

′



where, by the [IAction] rule,

f has as a sub-expression either a site call, an

expression call or a publishing expression in a value-binding position. Again,

[IAction] and the equations deﬁning act

↑

for non-publishing internal actions,

imply 

f,lbl : ǫ | r) →

(f

′

, lbl : ǫ | r

′

. Induction and rule [Seq1NI] in R

complete the proof of this case

Finally, the action may be an external site return action, and the hypothesis

has the form:



>x> g, lbl : l | r→

f

′

x> g, lbl : ǫ | r

′



which, by the [SiteReturn] rule, the equations deﬁning sret, the inductive

hypothesis and the R

rule [Seq1NE], implies the desired conclusion.

The inductive cases for the asymmetric parallel composition and the oth-

erwise composition are similar and follow by induction and the corresponding

rules in R

Appendix B. BCast and CList Expression Declarations

The Orc program BCast has the following declaration:

BCast(m, x)  (if (empty(x))

≫ let(signal)

| if (¬empty(x))

≫ head(x) >a> a(m) ≫ BCast(m, tail(x)))

where empty, head,andtail are (local) sites implementing list functions.

The program CList has the following declaration:

CList(x)  (if (empty(x))

≫ let([])

| if (¬empty(x)) ≫ head(x) >a> (append ( y, ys)

<y< (a() | Rtimer (5) ≫ let(signal))

<ys< CList(tail (x))))

with append a local site that appends an element to a list.

Specifying and Analyzing the Kademlia Protocol in Maude

Conference Paper

Dec 2015
Lect Notes Comput Sci

Kademlia is the most popular peer-to-peer distributed hash table (DHT) currently in use. It offers a number of desirable features that result from the use of a notion of distance between objects based on the bitwise exclusive or of n-bit quantities that represent both nodes and files. Nodes keep information about files close or near to them in the key space and the search algorithm is based on looking for the closest node to the file key. The structure of the routing table defined in each peer guarantees that the lookup algorithm takes no longer than O(log(n)) steps, where n is the number of nodes in the network.

A Formal Executable Semantics of Orc using the K Framework

Thesis

Full-text available

Feb 2016

Omar Alzuhaibi

Orc is a programming model for expressing orchestrated distributed and concurrent computations. It abstracts computations through calling sites and expresses concurrency through four concise constructors. Our goal is twofold: (1) to devise a formal semantics of Orc that elegantly captures its intended semantics and (2) to formally verify the correctness of programs written in Orc. In order to achieve that, we wrote a complete formal semantics of Orc using the K framework, which in turn enables the execution and verification of Orc programs. This thesis presents in detail how the K framework's various facilities were utilized to arrive at a clean, minimal, precise and elegant semantic specification; informally compares our specification to previously developed operational semantics of Orc; and demonstrates how all of that enables the execution and verification of Orc programs through a case study and a few distinctive examples.

Towards Formal Verification of Orchestration Computations Using the K Framework

Conference Paper

Full-text available

Jun 2015
Lect Notes Comput Sci

Orchestration provides a general model of concurrent computations. A minimal yet expressive theory of orchestration is provided by Orc, in which computations are modeled by site calls and their orchestrations through a few combinators. Using Orc, formal verification of correctness of orchestrations amounts to devising an executable formal semantics of Orc and leveraging existing tool support. Despite its simplicity and elegance, giving formal semantics to Orc capturing precisely its intended behaviors is far from trivial primarily due to the challenges posed by concurrency, timing and the distinction between internal and external actions. This paper presents a semantics-based approach for formally verifying Orc orchestrations using the K framework. Unlike previously developed operational semantics of Orc, the K semantics is not directly based on the interleaving semantics given by Orc's SOS specification. Instead, it is based on concurrent rewriting enabled by K. It also utilizes various K facilities to arrive at a clean, minimal and elegant semantic specification. To demonstrate the usefulness of the proposed approach, we describe a specification for a simple robotics case study and provide initial formal verification results.

Functional Programming Using the New C++ Standard

Article

Full-text available

Dec 2015

Today software technology evolves very quickly, to an old paradigm, called functional programming. This paradigm uses lambda functions ready to be used where declared instead of function pointers. The long term target is to let compilers evaluate rather than execute a program/function. The new C++14 standard allows lambda calculus as we demonstrate in the applicative section of implementing conditionals, booleans and numbers.

Process Algebra with Timing

Article

Jan 2002

This book is concerned with a number of theories that can be used for describ ing and analyzing systems of interacting components in case it is desirable or necessary to regard their time-dependent behavior. Society is becoming increasingly more dependent on complex computer based systems that are composed of several components that act concurrently and interact - to synchronize and communicate with each other. The com plexity of these systems arises to a great extent from the many ways in which their components can interact. The need that these components act and in teract on time as well adds considerably to the complexity. In developing such a system, it is important to be able to acquire a better understanding of the relevant issues at the conceptual level, to describe the system in a precise way at various levels of detail, and to analyze it on the basis of the descriptions. When the early algebraic theories about processes, such as ACP [16, 17, 20], CCS [49, 50] and CSP [27, 39], were developed for that purpose, the established opinion was still that timing is a concern that can more often than not be treated independently. It is therefore not surprising that timing is deliberately ignored in those theories. They have now all been extended to deal with timing.

CINNI - A generic calculus of explicit substitutions and its application to λ-, ζ- and π-calculi

Article

Jan 2000

M.-O. Stehr

Towards Formal Verification of Web Service Composition

Article

Sep 2006

Mohsen Rouached

http://www.springerlink.com/

Analysing Web-Orchestrations Under Stress Using Uncertainty Profiles

Article

Oct 2013

An orchestration is a multi-threaded computation that invokes a number of remote services. In practice, the responsiveness of a web-service fluctuates with demand; during surges in activity service responsiveness may be degraded, perhaps even to the point of failure. An uncertainty profile formalizes a user's perception of the effects of stress on an orchestration of web-services; it describes a strategic situation, modelled by a zero-sum angel–daemon game. Stressed web-service scenarios are analysed, using game theory, in a realistic way, lying between over-optimism (services are entirely reliable) and over-pessimism (all services are broken). The ‘resilience’ of an uncertainty profile can be assessed using the valuation of its associated zero-sum game. In order to demonstrate the validity of the approach, we consider two measures of resilience and a number of different stress models. It is shown how (i) uncertainty profiles can be ordered by risk (as measured by game valuations) and (ii) the structural properties of risk partial orders can be analysed.

Mobile Ambients

Conference Paper

Mar 1998
Lect Notes Comput Sci

Laboratory We introduce a calculus describing the movement of processes and devices, including movement through administrative domains.

A Feature-Complete Petri Net Semantics for WS-BPEL 2.0 and its Compiler BPEL2oWFN

Article

Niels Lohmann

We present an extension of a Petri net semantics for the Web Service Business Execution Language (WS-BPEL). This exten-sion covers the novel activities and constructs introduced by the recent WS-BPEL 2.0 specification. Furthermore, we simplify several aspects of the Petri net semantics to allow for more compact models suited for computer-aided verification. This technical report is the extended version of the papers [1, 2] and can be seen as the sequel of [3].

The SynchAADL2Maude tool

Conference Paper

Mar 2012
Lect Notes Comput Sci

SynchAADL2Maude is an Eclipse plug-in that uses Real-Time Maude to simulate and model check Synchronous AADL models. Synchronous AADL is a variant of the industrial modeling standard AADL that supports the modeling of synchronous embedded systems. In particular, Synchronous AADL can be used to define in AADL the synchronous models in the PALS methodology, in which the very hard tasks of modeling and verifying an asynchronous distributed real-time system that should be virtually synchronous can be reduced to the much simpler tasks of modeling and verifying the underlying synchronous design.

A sensorless position detection strategy for Surface Mounted permanent magnet motors at low speed using transient finite-element analysis

Conference Paper

Jan 2010

The research proposes a solution for the sensorless control of Surface Mounted PM motors at zero speed. A creative strategy that involves minor change in the rotor is presented. The proposed FEA serves to evaluate the effectiveness of the strategy quickly and accurately down to very low speed.

Towards verification of computation orchestration

Article

Jul 2013

Recently, a promising programming model called Orc has been proposed to support a structured way of orchestrating distributed Web Services. Orc is intuitive because it offers concise constructors to manage concurrent communication, time-outs, priorities, failure of Web Services or communication and so forth. The semantics of Orc is precisely defined. However, there is no automatic verification tool available to verify critical properties against Orc programs. Our goal is to verify the orchestration programs (written in Orc language) which invoke web services to achieve certain goals. To investigate this problem and build useful tools, we explore in two directions. Firstly, we define a Timed Automata semantics for the Orc language, which we prove is semantically equivalent to the operational semantics of Orc. Consequently, Timed Automata models are systematically constructed from Orc programs. The practical implication is that existing tool supports for Timed Automata, e.g., Uppaal, can be used to simulate and model check Orc programs. An experimental tool has been implemented to automate this approach. Secondly, we start with encoding the operational semantics of Orc language in Constraint Logic Programming (CLP), which allows a systematic translation from Orc to CLP. Powerful constraint solvers like CLP

{(\mathcal{R})}

are then used to prove traditional safety properties and beyond, e.g., reachability, deadlock-freeness, lower or upper bound of a time interval, etc. Counterexamples are generated when properties are not satisfied. Furthermore, the stepwise execution traces can be automatically generated as the simulation steps. The two different approaches give an insight into the verification problem of Web Service orchestration. The Timed Automata approach has its merits in visualized simulation and efficient verification supported by the well developed tools. On the other hand, the CPL approach gives better expressiveness in both modeling and verification. The two approaches complement each other, which gives a complete solution for the simulation and verification of Computation Orchestration.

Verifying Hierarchical Ptolemy II discrete-event models using Real-Time Maude

Article

Oct 2012
SCI COMPUT PROGRAM

This paper defines a real-time rewriting logic semantics for a significant subset of Ptolemy II discrete-event models. This is a challenging task, since such models combine a synchronous fixed-point semantics with hierarchical structure, explicit time, and a rich expression language. The code generation features of Ptolemy II have been leveraged to automatically synthesize a Real-Time Maude verification model from a Ptolemy II design model, and to integrate Real-Time Maude verification of the synthesized model into Ptolemy II. This enables a model-engineering process that combines the convenience of Ptolemy II DE modeling and simulation with formal verification in Real-Time Maude. We illustrate such formal verification of Ptolemy II models with three case studies.

Executable rewriting logic semantics of Orc and formal analysis of Orc programs

Abstract and Figures

Recommended publications

On strictly arithmetical completeness in logics of programs

Dist-Orc: A Rewriting-based Distributed Implementation of Orc with Formal Analysis

Towards Formal Verification of Orchestration Computations Using the K Framework

The Rewriting Logic Semantics Project: A Progress Report

Reduction Semantics and Formal Analysis of Orc Programs