Document [original]

An Integration of Z and Timed CSP

for Specifying Real-Time Embedded Systems

vorgelegt von

Diplom-Informatiker

Carsten S¨

uhl

aus Berlin

Von der Fakult¨

at IV - Elektrotechnik und Informatik

der Technischen Universit¨

at Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

- Dr.-Ing. -

genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr.-Ing. Martin Buss

Berichter: Prof. Dr.-Ing. Stefan J¨

ahnichen

Berichterin: Prof. Dr. rer. nat. Maritta Heisel

Tag der wissenschaftlichen Aussprache: 17. Dezember 2002

Berlin 2002

D 83

Zusammenfassung

Fortschritte in der Entwicklung der Hardwaretechnologie haben zu einem Vordringen von

Software in neue Anwendungsbereiche und zu ihrem Einsatz zur L¨

osung immer komplexe-

rer Probleme gef¨

uhrt. Dies trifft insbesondere auf den Bereich eingebetteter Systeme zu.

Viele eingebettete Systeme, vor allem im Bereich der Prozesskontrolle, sind sicherheitskri-

tisch, d.h. sie stellen eine potentielle Gefahr f¨

ur das Eigentum oder sogar das Leben von

Menschen dar. Weil von solchen Systemen ein hoher Grad an Zuverl¨

assigkeit verlangt wird,

besitzt die Verwendung formaler Techniken in diesem Anwendungsbereich im Vergleich

zu nicht sicherheitskritischen Systemen, bei denen ihr ad¨

aquater Einsatz lediglich zu einer

allgemeinen Qualit¨

atsverbesserung f¨

uhrt, ein noch gr¨

oßeres Potential. Trotz dieser Vorz¨

uge

besitzen die etablierten formalen Spezifikationssprachen verschiedene Restriktionen, welche

ihre N¨

utzlichkeit f¨

ur die Entwicklung eingebetteter Systeme einschr¨

anken. Unter anderem

diese Erkenntnis hat dazu gef¨

uhrt, dass sich das Forschungsgebiet der ”Integration formaler

Methoden“ in j¨

ungster Zeit wachsenden Interesses erfreut.

Die vorliegende Arbeit hat eine solche Integration von zwei formalen Techniken, der mo-

dellbasierten Notation Z und der Echtzeitprozessalgebra Timed-CSP, zum Gegenstand. Z

ist eine verbreitete Notation zur Spezifikation datenbezogener Eigenschaften transformatio-

neller Systeme, jedoch nicht zur Modellierung von Verhaltensaspekten geeignet. Timed-CSP

hingegen, eine Erweiterung der Prozessalgebra CSP um Echtzeit, erm¨

oglicht die Definition

von Verhalten inklusive Echtzeitaspekten, unterst¨

utzt allerdings nicht die Modellierung von

Datentypen. Ziel dieser Arbeit ist die Ausnutzung der St¨

arken der beiden komplement¨

aren

Formalismen im Rahmen eines Integrationsformalismus’, der als RT-Z bezeichnet wird. RT-

Z unterst¨

utzt den Entwicklungsprozess in verschiedenen Phasen — von der Anforderungs-

spezifikation ¨

uber den Architektur- bis zum Detailentwurf — und erlaubt eine koh¨

arente,

formale Spezifikation aller relevanten Aspekte eines eingebetteten Echtzeitsystems.

Im Folgenden seien die vier wesentlichen Charakteristika von RT-Z skizziert.

Zur Ausnutzung der oben genannten Vorz¨

uge formaler Techniken ist RT-Z vollst¨

andig for-

mal fundiert, was die Syntax, die Semantik und den Verfeinerungsbegriff, der die Grundlage

des Prozesses der schrittweisen Entwicklung von Spezifikationen bildet, einschließt.

Die meisten eingebetteten Systeme bestehen aus einer Vielzahl stark interdependenter Kom-

ponenten. Um diese inh¨

arente Komplexit¨

at bew¨

altigen zu k¨

onnen, stellt RT-Z eigene, formal

fundierte Strukturierungskonzepte bereit. Dies ist notwendig, weil beide Basisformalismen

nicht ¨

uber ad¨

aquate Strukturierungsmechanismen verf¨

ugen.

Weiterhin unterst¨

utzt RT-Z sowohl die Anforderungs- als auch die Entwurfsphasen. RT-Z

verf¨

ugt zu diesem Zweck ¨

uber Sprachkonstrukte auf verschiedenen Abstraktionsebenen:

abstrakte Konstrukte zur Spezifikation von Anforderungen, ohne dabei gleichzeitig Imple-

mentierungsdetails festzulegen, und konkrete Konstrukte zur Festlegung solcher Implemen-

tierungsdetails im Entwurf.

Schließlich ist eine herausragende Zielsetzung bei der Integration etablierter Techniken die

Wiederverwendbarkeit ihrer Infrastruktur, z.B. Werkzeuge. RT-Z ist als ”konservierende In-

tegration“ konzipiert und stellt einen optimalen Kompromiss zwischen oben genannter Wie-

derverwendbarkeit und der Koh¨

arenz der Teile einer Spezifikation dar.

Die Eignung von RT-Z — im Vergleich zu anderen Formalismen — f¨

ur den anvisierten An-

wendungsbereich folgt aus dem Zusammenwirken der Gesamtheit dieser Eigenschaften.

Acknowledgements

First of all, I would like to thank my advisers. Stefan J¨

ahnichen, who employed me as a PhD

student at GMD FIRST, gave me the freedom to develop my own research interests and to

choose my PhD topic. Also, the opportunity to work in interesting projects allowed me to

gain insight into current research issues. Maritta Heisel, who introduced me to research, sup-

ported my work from the beginning and provided me with important advice and feedback

for developing this thesis.

I am also grateful to my colleagues from the software engineering groups at Fraunhofer

FIRST (formerly GMD FIRST) and the Technical University of Berlin for their interest and

support. Matthias Anlauff, Jochen Burghardt, Steffen Helke, Stephan Herrmann, Florian

Kamm¨

uller, Jeff Sanders, Thomas Santen, Dirk Seifert, Graeme Smith and Kirsten Winter

helped me obtain an understanding of formal methods and software engineering in general.

They allowed me to benefit from their expertise and experience.

Thomas Santen deserves special thanks for relieving me in the QUASAR project during the

final stage of my dissertation as far as possible, allowing me to finish the work presented in

this thesis.

I am particularly grateful to Graeme Smith for reading the long chapter dealing with the

semantics of RT-Z and for giving me important advice how to make the definition of the

semantics conforming to my informal description of RT-Z.

Many thanks to Jochen Burghardt, who assisted me in improving the overview of timed CSP.

Discussions with Jan Brederecke helped me improve my understanding of and clear some

misconceptions concerning CSP-OZ.

Last, but not least, Wolfgang Grieskamp’s tool ZETA was extremely useful for typesetting

and checking the formal definitions.

III

Contents

I Introduction 1

1 Envisaged Application Area 7

2 Underlying System Model and Development Process 9

2.1 DevelopmentProcess ............................... 9

2.2 SystemModel ................................... 11

2.2.1 System Requirements and Design Specifications . . . . . . . . . . . . 12

2.2.2 Software Requirements Specifications . . . . . . . . . . . . . . . . . . 13

2.2.3 Software Design Specifications . . . . . . . . . . . . . . . . . . . . . . 14

3 Objectives 15

3.1 Restrictions..................................... 16

4 State of the Art: Related Work 17

4.1 CSP-OZ....................................... 17

4.2 TCOZ ........................................ 20

4.3 Object-Z/CSP................................... 21

4.4 LOTOS ....................................... 23

4.5 RAISE Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6 Temporal Logic of Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7 Others........................................ 26

5 Classification 31

II RT-Z: An Integration of Z and Timed CSP 35

6 Integration Principles 39

6.1 Specifying Properties (Abstract Model of Integration) . . . . . . . . . . . . . . 39

6.2 Specifying Models (Concrete Model of Integration) . . . . . . . . . . . . . . . 45

7 Specification Units 53

7.1 Concrete Specification Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Abstract Specification Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8 Structuring Mechanisms 65

8.1 Aggregation..................................... 66

8.1.1 Example................................... 66

8.1.2 GlobalInvariants.............................. 68

8.1.3 Syntax.................................... 71

8.1.4 SimpleAggregation ............................ 72

8.1.5 IndexedAggregation............................ 78

8.2 Extension...................................... 83

8.3 Renaming...................................... 94

8.4 Hiding........................................ 94

8.5 Parametrisation................................... 94

8.6 Example: Alternating Bit Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 95

III Formal Foundation 101

9 Denotational Semantics 103

9.1 Basics........................................ 103

9.2 Concrete Specification Units (Open System View) . . . . . . . . . . . . . . . 105

9.2.1 Concurrency on Common Data State . . . . . . . . . . . . . . . . . . 105

9.2.2 Semantic Integration: Overview . . . . . . . . . . . . . . . . . . . . . . 109

9.2.3 HistoryModel................................ 111

9.2.4 Extended Timed Failures Model (ETFM) . . . . . . . . . . . . . . . . . 122

9.2.5 Timed Failures/States Model (TFSM) . . . . . . . . . . . . . . . . . . 141

9.2.6 Semantic Integration: Definition . . . . . . . . . . . . . . . . . . . . . . 144

9.3 Abstract Specification Units (Open System View) . . . . . . . . . . . . . . . . 146

9.4 ClosedSystemView................................ 147

9.4.1 Concrete Specification Units . . . . . . . . . . . . . . . . . . . . . . . 147

9.4.2 Abstract Specification Units . . . . . . . . . . . . . . . . . . . . . . . . 147

9.5 Definedness of Recursive Process Equations . . . . . . . . . . . . . . . . . . 148

10 Refinement 151

10.1 Refining Single Specification Units . . . . . . . . . . . . . . . . . . . . . . . . 152

10.1.1 Retrieve Specification Units . . . . . . . . . . . . . . . . . . . . . . . . 152

10.1.2 Relating Timed Observations of a Refined and a Refining Unit . . . . 154

10.1.3ClosedSystemView............................ 156

10.1.4OpenSystemView............................. 157

10.1.5 Techniques for Establishing Refinement . . . . . . . . . . . . . . . . . 158

10.2 Refining Compound Specification Units . . . . . . . . . . . . . . . . . . . . . 160

10.2.1Aggregation................................. 161

10.2.2Extension.................................. 163

10.3 Relationship between Simulation and Refinement . . . . . . . . . . . . . . . . 163

IV Discussion 169

11 Comparison with Related Formalisms 171

11.1CSP-OZ....................................... 171

11.2TCOZ ........................................ 176

11.3Object-Z/CSP................................... 180

11.4LOTOS ....................................... 180

12 Case Studies 183

12.1Multi-liftSystem................................... 183

12.1.1 Problem Description and System Architecture . . . . . . . . . . . . . . 183

12.1.2 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . 185

12.1.3 Design Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

12.1.4Discussion ................................. 205

12.2GasBurner..................................... 207

12.2.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

12.2.2SystemDesign............................... 209

12.2.3 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 212

12.2.4SoftwareDesign.............................. 214

12.2.5Discussion ................................. 220

13 Conclusions 223

13.1Contributions.................................... 223

13.2 Satisfaction of Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.3FutureWork..................................... 226

VII

V Appendices 231

A Base Formalisms 233

A.1 ZNotation...................................... 233

A.1.1 Standardisation............................... 233

A.1.2 Discussion ................................. 235

A.2 TimedCSP..................................... 235

A.2.1 Computational Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

A.2.2 Process Term Language and Operational Semantics . . . . . . . . . . 238

A.2.3 Timed Transition Systems . . . . . . . . . . . . . . . . . . . . . . . . . 244

A.2.4 Denotational Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 247

A.2.5 PredicateLanguage............................ 258

A.2.6 Verification ................................. 260

A.2.7 Discussion ................................. 262

A.2.8 Other Approaches to Modelling and Reasoning about Real-Time . . . 263

B Satisfaction of TFM Properties 265

B.1 Lemmata ...................................... 265

B.2 Properties of the Timed Failures Model . . . . . . . . . . . . . . . . . . . . . 267

C Relationship between Simulation and Refinement 291

D RT-Z Syntax 303

E Glossary of Timed CSP Notation 311

Bibliography 313

Index of Terms 321

Index of Semantic Definitions 325

VIII

Part I

Introduction

Recent advances in hardware technology have led to the introduction of software into new

application domains and, within particular domains, to its use to solve increasingly complex

problems; this holds particularly for embedded systems. The relevance of the domain of

embedded systems is increasing, because it occupies a growing portion of the market. It is

estimated [Gupta, 2002] that the market for embedded computer systems will surpass the

market for personal computers until the end of this decade.

Many embedded systems, e.g., in the area of process control, are of a safety-critical nature,

i.e., they have the potential to threat the safety of property or even of human life. Because of

the high degree of reliability required of such systems, the use of formal methods is benefi-

cial in this application domain. Sometimes it is even mandatory. The UK Ministry of Defence

[1997], e.g., issued a standard concerning the procurement of safety-critical software in de-

fence equipment. This standard mandates the extensive use of formal methods.

But there are also economical reasons for employing formal methods: Potter et al. [1996]

have pointed out that “the bulk of the costs of a software project are related to the fixing of

errors at the implementation and test stages and that a very large percentage of these errors

are traceable to imprecision in the early stages of a project.” Consequently, techniques able

to eliminate imprecision and to introduce clarity and rigour at those early stages are likely to

lead to a reduced error rate and hence to substantial cost savings. The use of formal methods

can assist in achieving these goals. Their mathematical foundation makes it possible to state

requirements and designs in a clear and unambiguous way and to reason about their proper-

ties rigorously. Following Clarke and Wing [1996], we use the term formal methods through-

out this thesis in order to refer to mathematically-based languages, techniques and tools for

specifying and verifying systems.

Despite the merits generally attributed to formal methods, the established formal specifica-

tion languages exhibit limitations that restrict their usefulness for the development of soft-

ware in embedded systems. This observation, among others, has caused the integration of

formal methods to become a research field of growing interest. This is witnessed, e.g., by

the establishment of a series of international conferences dedicated to this research topic

[Grieskamp et al., 2000, Butler et al., 2002, Ehrig and Große-Rhode, 2002], but also by the

funding of research projects such as ESPRESS [1998], UNIFORM [1998] and SoftSpez [2000].

The present thesis deals with such an integration of two established formal specification

languages: the state-based specification language Z and the real-time process algebra timed

CSP. The integrated formalism, called RT-Z, is aimed at formally specifying all relevant as-

pects of real-time embedded systems in a coherent manner. RT-Z is designed to support

the development process of embedded systems in different phases—from the requirements

engineering via the architectural to the detailed design.

The Z notation [Woodcock and Davies, 1996] is a formal language for specifying data-related

characteristics of transformational systems, which is in widespread use in academia and—to

a restricted extent—also in industry. However, it is not designed to model behaviour. Timed

CSP [Schneider, 1999b], a real-time extension of the process algebra CSP, on the other hand, is

a powerful language for specifying behaviour, including real-time aspects. However, it does

not provide adequate constructs to model data. The formalisms can hence be considered

as complementary, covering disjoint aspects of real-time embedded systems. Further, their

underlying concepts are well suited to each other. RT-Z exploits the strengths of both formal-

isms in order to provide a smoothly integrated, single formalism to model all relevant facets

of real-time embedded systems.

Let us stress four essential characteristics of RT-Z.

First, to exploit the abovementioned benefits of formal methods, the integrated formalism

RT-Z is defined completely formally, including its syntax and semantics. Further, its form-

ally defined notion of refinement enables the stepwise development of RT-Z specifications

towards implementations.

Second, most embedded systems are fairly complex systems, containing a large number

of highly interdependent system components. An appropriate specification language must

provide adequate structuring (and encapsulation) mechanisms to cope with this inherent

complexity; they are introduced and backed up formally by RT-Z on top of the integration of

the notations of Z and timed CSP, because both base formalisms are lacking corresponding

mechanisms.

Third, as already indicated, the aim of RT-Z is to support the requirements and the design

phases of the development process. To this end, it provides two kinds of language con-

structs: abstract constructs to specify requirements without fixing aspects of the final imple-

mentation and concrete constructs to fix such implementation aspects in the architectural and

detailed design.

Last, but not least, a crucial rationale of integrating existing, well-established formalisms

is the reuse of their infrastructure, e.g., tools or the knowledge and experience of existing

users. RT-Z is designed as a so-called ‘conserving integration’ and reconciles both the desire

to reuse existing infrastructure and the coherence between different parts of the specification

of an embedded system.

The appropriateness of RT-Z—compared with other integrated formalisms—for specifying

real-time embedded systems results from the interaction of all these characteristics.

Overview

The thesis is organised as follows.

In Part I we introduce the context of the integrated formalism RT-Z: its envisaged applica-

tion area (Chapter 1), its underlying system model and the development process into which

it is incorporated (Chapter 2). The objectives that RT-Z must meet to be useful for the envis-

aged application area within the considered phases of the development process are stated

in Chapter 3. Based on these objectives, we discuss the related work in Chapter 4. Then,

to get a better overview and to have a basis for categorising our approach with respect to

the related work, we propose a classification of approaches to integrating complementary

formalisms in Chapter 5.

Part II deals with the basics of the integrated formalism RT-Z in an informal way. We first

discuss the general principles pursued in integrating the formalisms Z and timed CSP in

Chapter 6. In particular, we distinguish between an abstract and a concrete model of inte-

gration, covering the different abstraction levels to be supported during the development

process. Then, in Chapter 7, we treat the notation of the basic units of an RT-Z specification,

which we call specification units. We finally introduce the structuring operators of RT-Z in

Chapter 8 allowing us to hierarchically decompose the specification of a large and complex

system into basic specification units.

In Part III we back up formally the notation introduced in the previous part. This includes

the definition of a denotational semantics for RT-Z specification units in Chapter 9 and of the

notion of refinement in Chapter 10, the latter chapter including techniques for establishing

refinement between specification units.

A discussion of the integrated formalism RT-Z is the subject of Part IV. This includes a

comparison of RT-Z with directly related integrated formalisms in Chapter 11 and two case

studies in Chapter 12, carried out in order to illustrate and validate the concepts underlying

RT-Z. In Chapter 13 we draw conclusions and discuss open items that remain as subjects for

future work.

Finally, the appendices contain a detailed account of the two base formalisms of RT-Z (espe-

cially of timed CSP) and two substantial mathematical proofs concerning the consistency of

our semantic definitions and the soundness of our refinement rules for RT-Z.

Chapter 1

Envisaged Application Area

The integrated formalism we are aiming at is directed towards the development of software

in embedded systems. Embedded systems cover a wide area of applications, including pro-

cess control, signal processing, communication and networking, etc. Following Koopman

[1999, 1996] and Gupta [2002] embedded systems are characterised by:

•being heterogeneous, i.e., including software, digital, electric and mechanical compon-

ents, etc;

•being time-dependent, i.e., associated with (hard) real-time constraints;

•being reactive, i.e., performing computations in response to periodic and spontaneous

events controlled by the environment;

•involving data-processing tasks (e.g., digital signal processing);

•being safety-critical (e.g., process control);

•being inherently concurrent and distributed;

•being application specific, i.e., the application is known a priori before the system de-

sign begins.

Note that not necessarily all of the above characteristics need to apply to each individual

embedded system.

Thus, software components in embedded systems usually

•have complex interrelations to their environment (constituted by various types of com-

ponents);

•are reactive (as opposed to transformational), having several concurrent threads of

control;

•involve data-processing;

•must perform their computations timely, i.e., are associated with real-time constraints;

8 Chapter 1. Envisaged Application Area

•are distributed and must hence communicate via networks;

•are required to have a high degree of reliability;

•are not general-purpose.

The required abilities of the integrated formalism we are aiming at derive from the above

characteristics of embedded systems and the software components they contain.

The high degree of reliability that is often required of embedded systems, particularly in

safety-critical applications, renders the use of formal methods a worthwhile option, if not

even prescribed by certification authorities or customers.

A characteristic of embedded systems that makes the use of formal methods realistic is that

they are developed for specific, a priori known purposes. This is a contrast to desktop com-

puting applications, which usually have a more general purpose. It is very hard to elicit

clear requirements for such applications, which makes the use of formal methods problem-

atic. Moreover, desktop computing applications tend to become very complex and put the

main emphasis on aspects that are hardly amenable to a formalisation, e.g., the graphical

user interface. Embedded systems do not have these characteristics and are hence more

amenable to formality.

Of course, the diversity of the relevant aspects—reactiveness, real-time, concurrency, distri-

bution, data processing, and so on—is challenging for a formalism that is to be employed

for developing software in embedded systems.

Chapter 2

Underlying System Model and

Development Process

In this chapter, we discuss the system model underlying the integrated formalism we are

aiming at and the overall development process for embedded systems of which the inte-

grated formalism is one constituent.

2.1 Development Process

We start with outlining the model of the system development process in which the appli-

cation of the integrated formalism we are aiming at is embedded. This process model fol-

lows the waterfall model enhanced with the concept of iterations as presented, e.g., by Som-

merville [1995, p. 9]. In this model, the development process is considered to be partitioned

into a sequence of phases, each of which results in a well-defined set of documents. The

result of a phase is the basis for performing the subsequent phase. In contrast to the basic

waterfall model, the extended one takes into account the need of verification and validation

(V&V) activities at the end of each phase, a negative result of a V&V activity giving rise to a

repetition of phases already passed through.

The considered process model is depicted in Figure 2.1. Phases are depicted by rectangles,

and the resulting documents are depicted by ellipses. The backward arrows represent the

need to go back to a previous phase because of a failed V&V activity. The grey rectangle

encompasses those parts of the overall development process that are to be covered by the

envisaged integrated formalism.

The first two and the last two phases of this model apply to entire systems. In contrast,

the phases in the middle are applicable only to a certain type of system components. The

phases supporting the development of particular types of system components are arranged

in different levels represented by the outmost rectangles. The front rectangle contains the

phases for developing software components.

The aim of the system requirements analysis phase, resulting in the system requirements

specification, is to analyse an existing system and its environment and to specify the require-

10 Chapter 2. Underlying System Model and Development Process

System (Requirements) Analysis

System (Requirements)

Specification

System Design

System Design Specification

Implementation

Software Modules

Integration & Installation

Operation & Maintenance

software

component

verification &

validation

Architectural

Software Design

Detailed

Software Design

Software Requirements

Elicitation

Software Requirements

Specification

Software Design

Specification

Figure 2.1: System development process.

ments (system function) and constraints the redeveloped system must meet with respect to

its environment.

The system design phase, completed by the system design specification, deals with devis-

ing an implementation concept for the considered system that satisfies the requirements and

constraints defined in the system requirements specification. This involves the system archi-

tecture, e.g., the decomposition of the system into certain kinds of system components. The

system design specification contains specifications of different types of system components.

In the following, we consider the development of software components.

The subject of the software requirements elicitation phase, resulting in the software require-

2.2. System Model 11

ments specification, is to define the requirements and constraints each software component,

identified in the system design, must satisfy at its external interface. At this stage, no aspects

of its internal implementation should be fixed.

In the software design phase, an implementation concept is worked out for each specified

software component. This includes stipulating internal aspects, e.g., the internal structure,

the state space, etc. The result of this phase is a software design specification for each soft-

ware component.

The subsequent implementation phase transforms the design specification of each software

component into an executable piece of code (module) in the chosen implementation lan-

guage.

All developed system components—software, hardware, mechanical, electrical components,

and so on—must be integrated eventually to form the entire system, and the integrated

system must be installed in its operational environment. The operation of the developed

system may entail the need to correct, to change or to extend the system, which leads to a

repetition of previous phases.

2.2 System Model

We proceed with discussing the system model underlying the envisaged formalism. It de-

termines the abstraction to be carried out when modelling an embedded system and incor-

porates the information needed in order to interpret specifications of the integrated formal-

ism.1

We start with clarifying the notion of a system; this leads us to a rough, generic system

model. The integrated formalism aimed at is to be applied in different phases of the system

development process just described. Each of the phases is associated with a particular in-

stance of this generic system model. These instances are described in the following sections.

Following Leveson [1995, pp. 136–137] we interpret a system as a collection of components

acting together and interacting with each other in order to achieve some common goal with

respect to its environment at the same time obeying some constraints.

The system state at any point in time is the set of relevant properties characterising the sys-

tem at that time. The system environment is a collection of components that are not part of

the system but whose behaviour can affect the system. The system interacts with the envir-

onment through events crossing the boundary between the system and its environment. Any

set of components that is considered as a system is part of a hierarchy of systems: a system

may contain subsystems and may also be part of larger systems.

We must distinguish between two types of entities in the following description of the in-

stances of the system model.

1In our opinion, clarifying the system model underlying a specification language is crucial. For instance, the

success of the formal specification language SCR [Heitmeyer et al., 1996] rests, among other things, on the

underlying ‘Four Variable Model’ of Parnas and Madey [1995].

12 Chapter 2. Underlying System Model and Development Process

•Entities that specify characteristics of the artifact at hand that are visible to the envir-

onment.

•Entities that specify characteristics of the artifact at hand that are not visible to the

environment. Such entities are used in order to enable a more convenient modelling of

those characteristics that are externally visible.

As elaborated in the following sections, the state is an entity that is considered to be ex-

ternally visible in the system-related phases but not to be externally visible in the software-

related phases.

The above distinction leads to two different views on artifacts of the system development

process: the closed system view in which an artifact is considered to be completely charac-

terised in terms of its behaviour at the external interface; and the open system view in which

“internal” aspects of its description are taken as an additional part of its characterisation.

2.2.1 System Requirements and Design Specifications

The aim of the system-related phases is to define the embedding of the software to be de-

veloped within its context, which may be constituted by digital, electrical, mechanical com-

ponents, human operators, etc. When developing safety-critical systems, the definition of

safety constraints is one of the most important tasks in these phases.

The entities treated in the system-related phases are (almost) of an arbitrary kind: mech-

anical components, e.g., valves, electrical components, e.g., fuses, digital components, e.g.,

electronic circuits, human operators, and—last but not least—software components. Due to

this diversity there are different kinds of interaction: information flows, electrical current,

mechanical pressure, etc. The system model underlying this phase must be general enough

as to take this diversity of components and interactions into account.

As indicated, a system is modelled as a hierarchy of interacting components. Interaction

between components (and between a system and its environment) is modelled to take place

by means of events occurring on channels. This means that components interact via synchron-

ous communication: for an interaction to take place, the “sender” and the “receiver” have to

simultaneously participate in that interaction. The occurrence of an event may be associated

with the communication of information units (between software components), the transport-

ation of material (between mechanical components), the flow of current (between electrical

components), etc. That is, we associate a particular type with each channel which restricts

the set of objects that can be transported with the occurrence of events on that channel.

Each component is considered to have an interface, which consists of all events that serve

the component to interact with its environment. Furthermore, since a component may be

structured into sub-components, there may be additional events that are not part of the in-

terface but are related to the local interaction between these sub-components. Therefore, we

distinguish between external and internal events with respect to a component. An internal

event is solely controlled by the component, whereas an external event is controlled by both

the component and its environment.

Each component is embedded within a context. It need not achieve its goal under all possible

circumstances, but it may require its environment to satisfy some conditions called environ-

2.2. System Model 13

mental assumptions: if these assumptions are violated by the environment, the component is

neither required to achieve its goal properly nor to obey its constraints.

The state of a component at a particular instant of time is constituted by the set of relevant,

physically available properties characterising the component at that time. In the system-

related phases, as already indicated, the state is considered as an externally visible entity.

That is, the definition of a state with a certain structure and certain properties in a system

specification forces any conforming implementation to have a counterpart with that struc-

ture and that properties. There are two reasons why the state cannot be considered as an

internal aspect of a system specification.

Firstly, safety is a property that is of relevance in the area of embedded systems. Safety, ac-

cording to Leveson [1995], is a property of a system whose definition is directly related to the

state of that system (and its components). Therefore, the meaning associated with a system

specification must incorporate the state, because the classification of an implementation as

safe or unsafe can be carried out only on this basis.

Secondly, as discussed in detail in Section 9.1 by means of an example, there are relevant

types of requirements in the context of system specifications that cannot be handled properly

if not including the state evolution in the meaning associated with a system specification.

The state of a component is transformed in reaction to interactions occurring at the external

interface. State transitions need not be defined deterministically, i.e., the transition from a

pre to a post state in reaction to an external event need not be unique. State transitions may

depend on inputs and they may produce outputs. State transitions are instantaneous; the

continuous change of the state during a time interval is not expressible within the chosen

system model: we do not aim at describing hybrid behaviour.

The decomposition of a system specification into components renders physical structures

that are already fixed by the existing development context. Therefore, the structure of a

system specification fixes the structure of conforming implementations.

2.2.2 Software Requirements Specifications

The artifacts referred to in software requirements specifications are software components.

These software components interact by communicating information units. The facts that we

deal with software and that we do not consider whole systems but only components entail

some consequences on the underlying system model for this phase.

In the software-related phases, as already indicated, the state defined in a specification is

considered as an internal aspect of the specification that does not force conforming imple-

mentations to have a counterpart. The meaning associated with a software specification,

therefore, does not incorporate the evolution of the state. The reason for this different inter-

pretation of the state in the system-related and the software-related phases is twofold.

Firstly, safety is a property that does not refer to software components: a software compon-

ent cannot be safe or unsafe; but it can contribute to the safety of the system into which it

is embedded depending on its external behaviour at the interface. So, our above reasoning

about safety on the system level does not apply to the software level.

14 Chapter 2. Underlying System Model and Development Process

Secondly, since the invention of the information hiding principle, software components are

considered as encapsulated entities that interact only via defined interfaces; the environment

cannot observe the internal structure and the internal state of a software component.

Following Broy et al. [1992], the specification of a state and its operations does not necessar-

ily constrain implementations to have an implementation of the state and all its operations.

Rather, the state machine model is a tool for specifying the data-related characteristics at the

external interface more succinctly and conveniently. The current state of a software com-

ponent can be interpreted as representing the relevant properties of the past interaction that

determine the software component’s ability to interact with the environment in the present

and future.

In contrast to system requirements and design specifications, the structure of a software

requirements specification has only conceptual reasons and does not restrict conforming

implementations.

2.2.3 Software Design Specifications

The artifacts and their interrelations that are referred to in software design specifications

are essentially identical to those in a software requirements specification. Thus, the system

model underlying software design specifications is almost identical to the one underlying

software requirements specifications. However, the following difference exist.

In the software design phase, it is the general task to devise an “implementation concept” for

the requirements specified in the software requirements specification. Like in the system de-

sign, such an implementation concept encompasses (among other things) the decomposition

of software components into sub-components and the definition of their interfaces. That is,

the structure of a software design specification has immediate consequences for conforming

implementations.

This completes our discussion of the instances of the system model underlying RT-Z. These

instances roughly stipulate how the notation of RT-Z, treated in Part II, is to be interpreted,

as formally fixed in Part III.

Chapter 3

Objectives

In Chapter 1, we have discussed the envisaged application area of the integrated formalism

we are aiming at: real-time embedded systems. The development process incorporating the

application of the integrated formalism and the phases of this process to be supported have

been discussed in Chapter 2. We now derive from these context conditions objectives to be

met by the formalism.

Formality, Abstractness and Rigour: Developing safety-critical systems requires a high de-

gree of reliability. Only a notation based on mathematical concepts and associated

with a formal semantics enables the clear and precise definition of requirements, con-

straints and models. A mathematical basis is also the prerequisite for the ability to

specify at different abstraction levels. Finally, formality is the prerequisite for reason-

ing about specifications by means of rigorous proof techniques.

Adequate Expressiveness: The provided language constructs need to be adequate for the

considered application area. On the one hand, the formalism must be expressive

enough; on the other hand, the trade-off between a high expressiveness and the ability

to reason about specifications must be taken into account.

Since, as claimed in Chapter 1, embedded systems are usually reactive, are usually

associated with real-time constraints and usually involve data-processing tasks, the

formalism should provide language constructs to cover all these three dimensions of

the behaviour of an embedded system.

Coverage of the System Development Process: As stated in Chapter 2, the formalism must

be appropriate for different phases of the system development process. It is to be used

to set up system requirements specifications, system design specifications, software

requirements specifications and software design specifications. It must hence be able

to cover all involved abstraction levels.

The formalism must, on the one hand, provide abstract language constructs, which

allow us to specify requirements on the externally observable behaviour in system

and software requirements specifications without fixing implementation aspects. On

the other hand, it must provide concrete language constructs to allow us to specify

architectural and implementation aspects in system and software design specifications.

16 Chapter 3. Objectives

Scalability (Modularity): The formalism must cope with large and complex systems. To this

end, it must provide appropriate structuring and decomposition concepts.

The above objectives are used to assess the integrated formalism that we present in this thesis

as well as the related work treated in the next chapter.

3.1 Restrictions

For pragmatic reasons we do not aim at achieving all those desirable objectives whose satis-

faction is vital only for a sub-class of the considered application area. The following restric-

tions apply to the formalism we are aiming at.

Hybrid Behaviour: The specification of hybrid systems with discrete and continuous ele-

ments is not to be taken into account. The class of systems that can be specified is

thereby restricted. However, taking into account hybrid behaviour would make the

formalism disproportionately complex.

Stochastic Behaviour: Similarly, the specification of stochastic systems—systems consisting

of parts whose concrete behaviours occur with a certain probability—is not to be taken

into account. Also this decision causes a restriction of the considered system classes,

however, in favour of an essentially simpler model.

Simulation/Executability: The ability to animate and to simulate a formal specification, re-

spectively, is not our main concern. Of course, the simulation of a formal specification

is an important means for validation. However, to focus on the ability to simulate

a specification appears to be in conflict with a high level of abstraction (intelligibil-

ity): simulating a specification necessitates the employment of concrete (executable)

language constructs, which contradicts the requirement for abstractness at least in the

early phases.

Chapter 4

State of the Art: Related Work

Before introducing our integrated formalism RT-Z, we discuss some related approaches,

which partly share our goals. The discussion in this chapter is the basis for our classification

of approaches to combining/integrating formalisms proposed in the next chapter. Those

approaches discussed in this chapter that are related most closely to RT-Z and that have

strongly influenced its design are compared with RT-Z in Chapter 11.

In the remainder of this chapter, the related approaches are introduced in the order of close-

ness to RT-Z.

4.1 CSP-OZ

CSP-OZ [Fischer, 2000, 1997, Fischer and Wehrheim, 1999] is an integration of Object-Z and

(untimed) CSP. According to the classification scheme discussed in the following chapter, it

is a monolithic integration.

In CSP-OZ, each system specification is composed of class specifications. Fischer distin-

guishes between Object-Z classes, encapsulating only Object-Z notation, and CSP-OZ clas-

ses, encapsulating the notations of Object-Z and CSP. Objects, being instances of class speci-

fications, interact with each other along typed CSP channels: each class has an interface part

declaring a set of CSP channels each of which associated with a Z type. In CSP-OZ, each

interaction at the interface of an object corresponds to the application of an Object-Z oper-

ation that is defined in the corresponding class. With each operation application, the input

and output parameters of the corresponding operation are communicated along the corres-

ponding channel. The Z type associated with a channel is thus the schema type containing

the parameters of the corresponding operation schema.

Roughly speaking, each CSP-OZ class consists of three parts.

1. The interface part mentioned above.

2. The Object-Z part. It defines, in the style of Object-Z, data types, constants, a data state

schema, an initialisation schema and operation schemas.1

1Since ‘schemas’ is established in the Z community as the plural of ‘schema,’ we use it instead of the grammat-

ically correct ‘schemata.’

18 Chapter 4. State of the Art: Related Work

3. The CSP part. It defines the dedicated process term main; this process basically defines

the order in which operations are applied.

CSP-OZ partly adopts the structuring mechanisms of Object-Z: inheritance and object in-

stantiation. Compared with Object-Z, however, object instantiation is allowed only in a re-

stricted form: only Object-Z classes, which do not contain CSP definitions, are allowed to

instantiate other Object-Z classes in their data state schema and thus to exploit the full gen-

erality of object instantiation in Object-Z (including the ability to express invariants relating

the data states of several instantiated objects). Objects of CSP-OZ classes, on the other hand,

can instantiate objects of CSP-OZ classes only as fully encapsulated entities; they can refer

only to the interfaces of the instantiated objects. Instantiation of objects in CSP-OZ classes

takes place in the CSP part: the instantiating object can dynamically create objects of CSP-OZ

classes depending on its control state.

In CSP-OZ, the integration of Object-Z and CSP is achieved in two layers (phases). In the

first layer, an intermediate language, CSPZ, is defined that integrates Z and CSP. More pre-

cisely, CSPZis defined as an extension of Standard Z with CSP process expressions. CSPZ

expressions constitute the CSP part of CSP-OZ classes. In the second layer, the structure of

CSP-OZ classes is defined in terms of the Object-Z notation and the intermediate CSPZlan-

guage. Most important, the meaning of CSP-OZ classes is defined by means of translation

rules into the CSPZsyntax.

CSPZis an extension of the Z notation with the process term syntax of CSP. It is a very close

integration of the base notations and the basis for our classification of CSP-OZ as a mono-

lithic integration. Roughly speaking, the Z grammar is extended with additional production

rules for CSP process expressions: each CSP expression is a Z expression by definition. This

leads to a very convenient and concise style of specification. For example, the interleaving

of a collection of processes indexed by members of a set expression can be expressed as

|||i: 1 . . N•c!i→Stop

where i: 1 . . Nis a Z expression and c!i→Stop is a CSP process expression.

Central to the proposed integration of the Z and CSP notation is the introduction of param-

etrised process definitions, i.e., the ability to parametrise CSP process definitions by arbitrary

Z expressions, e.g.,

P(i:N)c

=c!i→Stop.

To define the meaning of such parametrised process definitions, Fischer provided syntactic

transformation rules mapping parametrised process definitions to Z syntax. The above de-

finition, e.g., would be mapped to the axiomatic definition

P:N→PROCESS

∀i:N•P(i) = c!i→Stop

where PROCESS is a given set assumed to be present in each CSPZspecification and to

represent all possible process expressions.

4.1. CSP-OZ 19

The meaning of CSPZprocess terms is defined by a so-called hybrid semantics, which in fact

is a denotational semantics, but associates with each process term a denotation that repre-

sents a labelled transition system; this is the operational nature of the semantics justifying

the term ‘hybrid.’ A main principle of defining the hybrid semantics, written [[ ]]O, is to

interpret each process term in the context of a Z model.2Accordingly, the semantic function

of CSPZis a curried function with the signature

[[ ]]O:PROCESS →Model →LTS

where LTS is intended to represent the set of all labelled transition systems. The function

[[ ]]Ois induced by a set of inference rules (several for each CSP operator).

In the second layer, as already indicated, the meaning of CSP-OZ classes is defined in terms

of transformation rules, mapping hierarchies of CSP-OZ classes to single classes and single

CSP-OZ classes to equivalent CSPZterms. This transformational approach to defining the

semantics of CSP-OZ classes follows the approach of Object-Z, which maps Object-Z syntax

to (plain) Z syntax.

The main principle of defining the meaning of a CSP-OZ class, constituted by an Object-

Z and a CSP part, follows an idea of Smith [1997]: the Object-Z part of a CSP-OZ class is

interpreted as a CSP process and is subsequently composed in parallel with the CSP part,

where both parts must synchronise on the operations of the Object-Z part. Accordingly, the

transformation rules yield two CSPZprocess terms procC and procZ for each CSP-OZ class,

representing the CSP and Object-Z part, respectively, and the process term proc, representing

the meaning of the whole CSP-OZ class.

proc(C) = (procC(C). . . kprocZ(C). . .)\. . .

A detailed discussion of the strengths and drawbacks of CSP-OZ can be found in Chapter 11.

Only there, after having introduced RT-Z, it is meaningful to further elaborate the descrip-

tion of CSP-OZ, including the discussion of which of the objectives stated in the previous

chapter are met.

Extensions

Hoenicke and Olderog [2002] have proposed an extension of CSP-OZ, called CSP-OZ-DC,

which uses the Duration Calculus [Chaochen et al., 1991] for specifying real-time constraints

on the behaviour of objects. In the Duration Calculus, real-time constraints are specified in

terms of integrals over continuous functions. Thus, the time models underlying CSP-OZ-DC

and RT-Z, which is based on timed CSP, are diametrical.

Sherif et al. [2001] have adapted the predecessor of CSP-OZ, CSP-Z, by substituting timed

CSP for CSP. This allows them to express real-time constraints in addition to the capabilities

of CSP-Z. The authors applied the resulting language, called Timed-CSP-Z, to the specifica-

tion and validation of the on-board computer of a Brazilian research satellite.

Because no semantics has been defined for Timed-CSP-Z, it is not backed up formally.

The authors defined a translation from Timed-CSP-Z specifications to high-level Petri Nets,

2The term ‘Z model,’ which is Z Standard terminology, is explained in Appendix A.1.

20 Chapter 4. State of the Art: Related Work

which can be checked by existing analysis tools for particular types of properties. The trans-

lation process, however, must be carried out manually. Further, since the meaning of Timed-

CSP-Z is not defined formally, there is no base against which the correctness of this transla-

tion process could be checked.

4.2 TCOZ

Timed Communicating Object-Z (TCOZ) [Mahony and Dong, 2000, 1998a, 1999b] is an inte-

gration of Object-Z and timed CSP. According to the classification scheme discussed in the

following chapter, it is a monolithic integration.

Each system specification in TCOZ is composed of class specifications. TCOZ classes incor-

porate the notations of Object-Z and timed CSP. Objects, being instances of class specifica-

tions, interact with each other along (untyped) CSP channels, which constitute the interface

of classes. The most important structuring operators are inheritance and object instantiation.

Each object is associated with a data state specified by an Object-Z state schema in the cor-

responding class, and it transforms the data state by performing operations specified by

Object-Z operation schemas. The dynamic behaviour of an object, i.e., its interaction with

the environment and the internal control of its operations, is specified by the dedicated timed

CSP process term MAIN in the corresponding class.3

The main principles of integrating the notations of Object-Z and timed CSP to obtain the

syntax of TCOZ classes is outlined in the following.

•Object-Z operation schemas are interpreted by TCOZ as terminating timed CSP pro-

cesses. For each operation schema Op of a TCOZ class, the timed CSP process MAIN

of this class can refer to the process Op in order to apply this operation to the current

data state.

•In each operation schema, input and output parameters may be associated with chan-

nels being part of the interface of the class. Applying an operation means to read

the specified input parameters from the corresponding channels, to transform the ob-

ject state according to the relationships specified in the operation schema and to sub-

sequently write the computed output parameters to the corresponding channels. The

exact order of reading input parameters and writing output parameters, the exact tim-

ing aspects of these parameter interactions and the time instant at which the state tran-

sition actually takes place is not fixed by the schema definition.

•The state schema of a class specified in Object-Z is extended by an interface definition,

i.e., a list of (untyped) CSP channels connecting the class objects to other objects. The

operations of the class read and write their parameters from and to these channels,

respectively.

3TCOZ distinguishes active and passive objects [Dong and Mahony, 1998]. For active objects, the dynamic

behaviour is explicitly defined by the process MAIN. In contrast, the behaviour of passive objects is controlled

by instantiating objects. Objects instantiate other objects by declaring a state variable of the respective class

type in their state schema. The data state of the instantiated object is part of the data state of the instantiating

object. The instantiating object may apply operations of the instantiated object and thereby transform its data

state.

4.3. Object-Z / CSP 21

•The specification of the dynamic behaviour in a TCOZ class mainly follows the syntax

of timed CSP, however, essential extensions have been defined to enable the reference

to the data state.

–So-called state guards serve to make the dynamic behaviour, more specifically the

flow of control, dependent on the current data state of an object. A state guard

is an arbitrary schema expression and may refer to the data state that is present

when the process guarded by the state guard starts.

–Value expressions within timed CSP processes may refer to arbitrary components

of the data state in order to denote values to be communicated via external chan-

nels. These state variables are evaluated with respect to the data state present at

the time of communication.

In summary, the notations of Object-Z and timed CSP are integrated very closely.

Considering the semantic model of TCOZ, the monolithic nature of the integration becomes

even more evident. Both timed CSP and Object-Z are equipped with a formal semantics, see

[Schneider, 1999a] and [Smith, 2000]. By merging the notations of Object-Z and timed CSP

in TCOZ, however, there are no identifiable parts of a TCOZ class solely formulated by one

of both notations. Therefore, it is not feasible to reuse the semantic definitions of the base

formalisms, because there are no parts within a TCOZ class to which the semantic functions

of Object-Z and timed CSP could be applied to somehow obtain the semantic function of

TCOZ. Consequently, the semantics of TCOZ is defined—more or less—from scratch.

The semantic model underlying TCOZ is the so-called timed, infinite states model [Mahony

and Dong, 1999a, 1997]. Each object of a TCOZ class is associated with a set of observations

each of which consisting of a state history, an infinite timed trace and a timed refusal. The

definition of the semantics of TCOZ is rather abstract, using Z as the meta language. The

meaning of the most important structuring facilities of Object-Z—inheritance, object instan-

tiation, containment—is not taken into account in the current version of the TCOZ semantics.

This is problematic, as the Object-Z extensions are the only operators to structure a TCOZ

specification, and they are extensively used (cf. [Mahony and Dong, 1998b]). Inheritance

and object instantiation are undoubtedly utmost powerful notational means, but their use is

problematic within a formal approach if their meaning is not defined precisely.

The strengths and drawbacks of TCOZ, including the discussion of which objectives stated

in the previous chapter are met, are discussed in detail in Chapter 11 after having introduced

RT-Z.

4.3 Object-Z / CSP

Smith and Derrick [Smith and Derrick, 2001, Derrick and Smith, 2000] have presented an

integration of Object-Z and CSP. According to the classification scheme discussed in the

following chapter, it is a conserving integration. The approach they proposed on the basis of

their integrated formalism supports—in addition to specifying concurrent and distributed

systems—aspects of refinement and verification.

22 Chapter 4. State of the Art: Related Work

The main idea underlying the integration is the identification of corresponding concepts

of the specification of object-oriented and concurrent systems—classes and operations on

the one and processes and events on the other hand. This identification is underpinned

semantically by giving Object-Z classes a semantics in the failures–divergences model of

CSP; it allows Object-Z classes to be referred to as CSP processes and hence to be composed

by CSP operators.

A system specification in the considered approach consists of two parts. The Object-Z part

comprises a number of Object-Z classes, each defining the behaviour of a single system com-

ponent. The CSP part fixes the configuration of the defined system components and their

interaction with the help of CSP operators, e.g., parallel composition. That is, the approach

chosen by the authors to integrate Object-Z and CSP is absolutely different from the ap-

proach taken in the design of CSP-OZ and TCOZ: in the current approach, Object-Z and

CSP cover different layers of a system specification. The first layer deals with single com-

ponents by solely using Object-Z, and the second layer deals with composing the compon-

ents defined in the first layer by solely using CSP. Thus, the notations of the base formalisms

are strictly separated from each other. This separation between different layers is a contrast

to the approach taken by the other integrations of Object-Z/Z and timed/untimed CSP, in

which the respective notations are integrated within the component level.

Since Object-Z classes are associated with a CSP semantics, refinement between integrated

specifications is simply defined in terms of CSP refinement, i.e., failures–divergences re-

finement. The authors have adapted the work of Josephs [1988], which has provided re-

finement relations for state-based systems that are sound and complete with respect to CSP

refinement, to the Object-Z setting. This enables them to check CSP refinement relations

between Object-Z classes directly using state-based techniques without the need to compute

the failures–divergences semantics of these classes.

The authors have also outlined an approach to verifying integrated specifications. Because

of the strict separation of the base formalisms, the existing verification techniques of Object-

Z and CSP can be combined to check properties of an overall system specification: first CSP’s

inference rules are used in order to reduce properties that the overall system must satisfy to

properties that its components must meet, and then Object-Z’s verification techniques are

applied in order to show that the components really meet these properties.

The major benefit of this approach is the absolutely strict separation of the base formalisms,

exploiting the maximal potential to reuse their infrastructure. The choice of CSP to define the

interactions between system components allows the convenient definition of architectural

aspects.

A disadvantage of this approach, on the other hand, is that CSP is not used in order to define

the dynamic behaviour of single system components (e.g., the temporal order of operation

applications). It is still Object-Z that is used for this purpose. From our point of view, CSP is

more appropriate than Object-Z to specify behavioural aspects.

Furthermore, Smith [2002] has presented an integration of Real-Time Object-Z [Smith and

Hayes, 1999] and CSP. The principles underlying this integration are identical to those ex-

plained above. However, using Real-Time Object-Z for defining the behaviour of system

4.4. LOTOS 23

components, the specifier is also able to express real-time constraints. Real-Time Object-Z

is based on the timed trace notation of Fidge et al. [1998], which is an interval-based set-

theoretic notation expressing real-time constraints in terms of continuous functions. Thus,

the time models underlying Real-Time Object-Z/CSP and RT-Z are diametrical.

4.4 LOTOS

LOTOS4[Bolognesi et al., 1995, Bolognesi and Brinksma, 1987] is a formal description tech-

nique developed by the International Standardization Institute (ISO) in the context of the

specification of the Open Systems Interconnection (OSI) architecture. It integrates two com-

plementary languages:

•a process algebra, which is mainly based on CCS [Milner, 1989], for specifying behavi-

oural aspects and

•the algebraic specification language ACT ONE [Ehrig and Mahr, 1985] for specifying

abstract data types, i.e., data structures and value expressions.

According to the classification scheme discussed in the following chapter, it is a conserving

integration.

The system model underlying LOTOS regards a distributed, concurrent system as a process,

composed of a collection of interacting sub-processes. A process is an entity able to con-

trol internal (unobservable) actions and to interact with its environment (constituted by a

set of other processes). Complex interactions between processes are built up of elementary,

atomic units of synchronisations called actions. The occurrence of an action implies process

synchronisation, i.e., all processes that are connected by an action have to participate in its

occurrence simultaneously. The occurrence of an action may be associated with the trans-

mission of data values. Actions are thought of as occurring at a synchronisation point called

gate. The interface of a process is constituted by the set of gates via which it interacts with its

environment.

One distinguishes between full LOTOS, providing the full range of syntactic constructs, and

basic LOTOS, providing only the process algebra language.

A process definition specifies the externally observable behaviour of a system component in

terms of sequences of observable actions at its gates. A process definition is parametrised

by a list of formal gates; these constitute the interface of the process via which the process

interacts with the environment (through synchronisation and value transmissions). The ob-

servable behaviour of a process is defined by a so-called behaviour expression.

In the data type part of a process definition, a set of abstract data types are introduced by us-

ing the algebraic specification language ACT ONE. Basic LOTOS is extended to full LOTOS

by language constructs referring to the elements of the abstract data types, i.e., constants,

functions and carrier sets. In full LOTOS, the occurrence of an action may be associated with

the communication of an arbitrarily complex value.

4LOTOS is a shorthand for Language of Temporal Ordering Specification.

24 Chapter 4. State of the Art: Related Work

The most important additional language constructs of full LOTOS are selection predicates

and guarded behaviour expressions.

Let us first consider a selection predicate in the example action denotation g?x:T1 !y[x<y].

Each occurrence of an action at gate ginvolves the communication of two values: the first

value must be of type T1and is bound to the variable xduring synchronisation, and the

second value is uniquely determined by the expression y. The selection predicate x <ydefines

a further constraint on the value bound to the variable xduring synchronisation.

As a second extension, each behaviour expression, say BE, may be guarded by a predicate,

say G, written G→BE. If the guard Gevaluates to true, the behaviour of the guarded expres-

sion is BE; otherwise the whole expression is equivalent to deadlock. The guard may refer to

any process parameter and to any variable bound by a prior communication of the process;

this allows the dynamic behaviour to depend on the current (data) state of the process.

The meaning of behaviour expressions is defined by an operational semantics. To relate

different descriptions of a system, e.g., its requirements specification and its design speci-

fication, several behavioural equivalence relations are defined between behaviour expressions

based on the operational semantics. The core of the process algebra LOTOS is constituted by

a set of algebraic laws stating equivalences between behaviour expressions.

To conclude, LOTOS is an expressive language, closely integrating notations for defining

behaviour and data types. The module concept of LOTOS is elaborate allowing it to tackle

large and complex systems. Moreover, LOTOS has a completely formal foundation. Its proof

rules support a rigorous development of a specification towards an implementation.

However, LOTOS has also some drawbacks. First, it does not aim to specify real-time con-

straints. Second, it is based on an algebraic specification language. While an algebraic speci-

fication language is perfectly suited to specifying requirements, it is difficult to use it in order

to fix design decisions, in particular architectural aspects. Finally, its process algebra is based

on an operational semantics. This implies that requirements must be expressed in terms of

behaviour expressions (rather than predicates).5In our opinion, specifying requirements in

terms of behaviour expressions is not as adequate as specifying requirements in terms of

predicates.

4.5 RAISE Specification Language

RSL is part of the formal method RAISE [Haxthausen and George, 1993], which is an ac-

ronym for Rigorous Approach to Industrial Software Engineering. RSL is a formal specifica-

tion language and has resulted from an integration of concepts from VDM [Jones, 1986],

CSP [Hoare, 1985], algebraic specification languages and ML [Paulson, 1991]. It is a wide-

spectrum language in that it enables the user to specify a variety of aspects of the system be-

haviour (e.g., dynamic behaviour, functional I/O behaviour) and in that it supports different

abstraction levels. For the abstract levels, axiomatic (algebraic) constructs are provided; for

the more concrete levels, model-oriented constructs are provided.

5Later in this thesis, we will see that a process algebra that is based on a denotational semantics (such as CSP)

provides a predicate language in addition to the language of process terms.

4.6. Temporal Logic of Actions 25

The notation is equipped with methodological support, where the overall development pro-

cess mainly follows the stepwise-refinement paradigm. The meaning of RSL specifications

is formally defined by a denotational semantics. Based on this semantics, proof rules have

been developed allowing one to derive properties from RSL specifications and to establish

refinement between two successive specifications in the development process. The entire

RAISE method is also supported by tools, e.g., editors, type-checkers and provers.

In RSL, a system is modelled as a network of interacting system components. Each sys-

tem component is specified by a module. Interaction between different modules takes place

via typed communication channels. The language provides an elaborate module concept,

comprising aggregation, indexed aggregation, parametrisation of modules, stepwise mod-

ule extension and hiding and renaming of module components. Inside a module, however,

there are no elaborate structuring facilities comparable, e.g., with the Z schema calculus.

The language has been designed to encompass the main language constructs of VDM, CSP

and algebraic specification languages; this has been achieved by a very close integration of

these base notations. Within an RSL module, these different language constructs (e.g., CSP

processes, VDM operations) are not separated syntactically. Thus they needed to be lifted

on a uniform semantic interpretation. CSP processes, e.g., are interpreted as VDM functions

with side effects on external channels and on the global state.

As already indicated, RSL is an utmost expressive language covering various aspects of the

behaviour of a system and several phases of the development process. From our point of

view, however, RSL is far too expressive, integrating features of too many different formal-

isms. This leads to a low degree of intelligibility.

Further, the monolithic nature of the integration makes it almost impossible to reuse the

infrastructure of the base formalisms, e.g., existing tools or the knowledge and experience of

their existing users.

4.6 Temporal Logic of Actions

Lamport [1994] has developed the formal specification language TLA (Temporal Logic of

Actions). It is a variant of temporal logic, as invented by Manna and Pnueli [1992], instanti-

ated by a particular system model. TLA+[Lamport, 2000] improves TLA by introducing a

module concept, i.e., it is designed to cope with complexity. TLA+is suited for specifying

and reasoning about concurrent systems.

A system specification in TLA+is composed of a collection of modules. Each module spe-

cifies a system component in terms of the behaviours it may perform.6Usually, a TLA+

module has the following structure. It first introduces a collection of variables, which con-

stitute the state of the component under consideration. TLA+is an untyped language, so in

principle variables can assume arbitrary values. State transitions, i.e., pairs of adjacent states

in a behaviour, are then defined by actions, which are predicates on pairs of states. Finally,

safety and liveness properties of the admissible behaviours are defined by using temporal

logic. Safety properties deal with the initial states in which the component may start and

6A behaviour is an infinite sequence of states, and a state is an assignment of values to variables.

26 Chapter 4. State of the Art: Related Work

with the state transitions it is allowed to perform. Safety properties are usually defined by a

temporal formula of the form

Init ∧[Next]

where Init characterises the set of initial states and Next, the so-called next-state action,

defines the relation between adjacent states in a correct behaviour. Thus, safety properties

define what the component must not do. Liveness properties, in the form of weak and strong

fairness conditions, on the other hand, define which actions are assumed to be (eventually)

performed under which conditions.

TLA+adds the module concept to TLA. Modules can extend other modules by importing

their definitions. This allows general-purpose definitions, e.g., the natural numbers or se-

quences, to be stored in module libraries. The other module operator is instantiation, which

allows a module to incorporate arbitrary collections of instances of other modules. The in-

stantiation operator supports the hierarchical decomposition of system specifications.

Modules in TLA+are basically containers for collections of definitions. They are used to

structure the definitions of large specifications; but they cannot be used to fix the structure

of a system, e.g., the configuration of its components and their interactions. This is the case

because the interactions between the instantiated modules are defined only implicitly: the

instantiating module connects the instantiated modules by defining actions on the overall

state—including the states of the instantiated modules—thereby composing sub-behaviours

of the instantiated modules to complete behaviours.

A major strength of TLA+is its module concept, which allows the specifier to structure

large collections of definitions in an intelligible way. Another benefit of using TLA+is its

tool support. Among others, there is a syntax checker, a model checker and a simulator for

a subclass of “executable” TLA+specifications. For TLA, there is also an implementation in

the generic theorem prover Isabelle [Kalvala, 1995].

However, TLA+has also some shortcomings.

Most important, it is difficult (if not impossible) to fix architectural aspects of a design, be-

cause the configuration of components and their interactions are not made explicit in a sys-

tem specification and could hence be changed arbitrarily in refining specifications and hence

in the ultimate implementation.

Further, TLA+is not a typed language, which, from our point of view, is a major drawback.

Typed languages, e.g., the Z notation, allow specifications to be type-checked, which helps

detect important types of errors, including conceptual ones.

Last, but not least, the notation provided by TLA+for defining the state does not provide any

structuring concepts comparable with the Z notation (schema calculus). The state is consti-

tuted by a plain (unstructured) collection of variables. The same applies to the specification

of actions, for which only the operators of predicate logic can be used.

4.7 Others

In the remainder of this chapter, we discuss some approaches that are related to RT-Z only

in a wider context but that are nevertheless useful in discussing the design principles under-

4.7. Others 27

lying RT-Z.

The following viewpoint-oriented approaches are based on the general ViewPoints frame-

work developed by Finkelstein et al. [1994, 1992], whose discussion is beyond the scope of

this thesis.

Viewpoints in a Formal Setting

Boiten et al. [Boiten et al., 2000, 1996, Bowman et al., 1999a, 1996] have proposed a system de-

velopment framework in the context of the Open Distributed Processing (ODP) [ISO, 1998]

standardisation, which is based on the use of multiple viewpoints.

According to the authors, the complete specification of any non-trivial distributed system

involves a large amount of information. To capture all aspects of such a system in a single

model is generally infeasible. As a consequence, their framework aims to establish a con-

figuration of models each aimed at capturing a particular facet of the system, satisfying the

requirements which are the concern of a particular stakeholder of the development pro-

cess. More specifically, the framework achieves this separation of concerns by the identific-

ation of a set of so-called viewpoints. The general idea is that multiple partial specifications

(viewpoints) of a system are developed. Each partial specification represents a different per-

spective on the system under development at a particular level of abstraction. In particular,

different viewpoints may be specified using different formal description techniques (FDT).

An immediate consequence of adopting a multiple viewpoint approach is that descriptions

of the same or related entities can appear in different viewpoints. Thus, different viewpoints

can impose contradictory requirements on the system under development and the consist-

ency of viewpoint specifications needs to be checked. Thus, providing techniques to check

consistency is one of the major research topics in the context of viewpoint modelling. A

necessary prerequisite for checking consistency is to define the relationships between view-

points that overlap. This could be achieved by using the same name for common aspects in

different viewpoints. In general, however, more complicated mechanisms for relating com-

mon aspects of viewpoints are needed. They are called correspondences in this framework.

The traditional approach to consistency checking is to translate all viewpoints to a com-

mon, underlying semantic model (e.g., first-order predicate logic): if all the translations

have a common model, i.e., their conjunction is satisfiable, then the viewpoints are con-

sistent. However, this approach has two shortcomings. First, a detected inconsistency is in

terms of the common semantic model, and it is in general impossible to trace it back to the

involved viewpoints. Second, the translation is accompanied by a loss of syntactic structure,

impeding an incremental approach. For these reasons, the authors pursued an alternative

approach to consistency checking: consistency of viewpoint specifications is defined in terms

of the existence of a common development. The term development comprises several mech-

anisms for evolving specifications towards implementations, e.g., the stepwise refinement

within a single formal description technique and the translation between different formal

description techniques. Since all viewpoint specifications must eventually be realised by a

single implementation, there must be a way to combine specifications from different view-

points during development; this combination is called a unification. To unify specifications

of different formal description techniques, a translation mechanism is needed to transform a

specification between the respective languages.

28 Chapter 4. State of the Art: Related Work

The definition of consistency in the considered framework is as follows.

A set of viewpoint specifications are consistent if there exists a specification that

is a development of each of the viewpoint specifications with respect to the iden-

tified development relations and the correspondences between viewpoints. This

common development is called a unification. [Boiten et al., 2000]

Besides the definition of consistency, the framework incorporates a method for construct-

ively establishing the consistency of a set of viewpoint specifications [Bowman et al., 1999b].

This involves algorithms that build unifications from pairs of viewpoint specifications. An

important notion in this context is that of a least developed unification. This is a unification

such that all other unifications are developments of it. Thus, it is the least developed of the

set of possible unifications according to the respective development relations. Using least

developed unifications as intermediate stages, global consistency of a set of viewpoints can

be established by a series of binary checks.

The framework also distinguishes between intra-language consistency and inter-language con-

sistency. Intra-language consistency is a relation between specifications expressed in the

same language, whereas inter-language consistency crosses a language boundary. As men-

tioned, to establish inter-language consistency, translation mechanisms are needed to trans-

form a specification in one language into another language.

A particular instance of this framework is described in [Boiten et al., 2000] by means of a

case study. This instance uses the formal description techniques LOTOS and Object-Z for

the different viewpoints. Appropriate translation techniques from LOTOS to Object-Z are

investigated in [Derrick et al., 1999].

To conclude, the current approach is not a particular integrated formalism but rather a gen-

eral framework containing techniques and guidelines to use the particular formalisms best

suited to a particular development task in a combined way.

Weber [1997] has presented a viewpoint-oriented approach, which aims at the combination

of formal and semi-formal specification techniques for the development of embedded con-

trol systems. He proposed to decompose the specification of an embedded control system

into three viewpoints: an architectural model, a behavioural model and a functional model.

Although his approach is general in that it does not explicitly fix the particular specification

languages to be used for the three models, Weber described his approach with respect to a

particular instance, which uses Z for the functional model, Statecharts for the behavioural

model and class and instance diagrams for the architectural model.

Weber has put emphasis on checking the consistency between the three models. To this

end, he defined a mapping that relates elements in different models that are intended to be

descriptions of a single entity and necessary conditions that must be met for the different

descriptions to be consistent. Of course, this mapping and the consistency conditions are

specific to the particular specification languages chosen for the three models.

Viewpoints in Z

Ainsworth et al. [1994] have investigated techniques to organise large and complex Z speci-

fications. Using their approach, any specification is divided into a set of viewpoints; each

4.7. Others 29

viewpoint is a partial specification that describes only certain aspects of the system under

development and is constituted by a “state-oriented” Z specification. The process of in-

tegrating all viewpoints of a system to a single specification and of checking their mutual

consistency is called amalgamation in this approach.

Since all viewpoints of a system specification use the same language (Z notation), the ap-

proach is homogeneous and avoids many problems that arise when multiple notations must

be reconciled. On the other hand, this approach does not aim to improve the expressive

power of Z; it restricts itself to manage the complexity of large specifications and thus to

enhance the structuring facilities of plain Z.

The process of amalgamating viewpoints, as illustrated in [Ainsworth et al., 1994] by means

of an example, is mostly driven by the intuition of the human specifier. The result of the

amalgamation of a pair of viewpoints is a combined viewpoint (Z specification) that must,

roughly speaking, be a refinement of both original viewpoints. Corresponding specification

elements of both original viewpoints and the resulting viewpoint are formally related with

the help of retrieve relations, which are the basis to check for refinement.

Conjoining Specifications

Zave and Jackson [1993] have described a general framework for multi-paradigm specifica-

tions. According to their terminology, a multi-paradigm specification is a finite set of partial

specifications, each covered by the formalism best suited to the particular purpose.

Central to their approach is the existence of a common, underlying semantic model: single-

sorted first-order predicate logic. Each formalism to be used in a partial specification must

be equipped with a semantic mapping from its expressions to equivalent assertions in first-

order predicate logic. These mappings might be partial, i.e., in some cases it suffices to

transform the specific parts of a formalism that are used. Composition of partial specifica-

tions, then, corresponds to the conjunction of the assertions that are the transformations of

the partial specifications.

An important notion in this framework is that of the vocabulary of a partial specification,

which is the set of predicates contained in its equivalent assertion. Different partial speci-

fications interact with each other via the intersection of their vocabularies: the predicates

that both partial specifications define and use, respectively. A set of partial specifications are

consistent if there exists a common model of their associated assertions, i.e., if the conjuction

of their associated assertions is satisfiable.

The approach described in [Zave and Jackson, 1993] is a framework rather than a concrete

specification language, because no particular decomposition style is fixed, encompassing

•the decomposition of a multi-paradigm specification into a fixed set of partial specifi-

cations,

•the set of formalisms to be used within these partial specifications and

•how partial specifications interact.

Moreover, the framework does not fix a particular system model: it is not fixed how a spe-

cified system interacts with its environment and which assumptions about the environment

30 Chapter 4. State of the Art: Related Work

are made. It describes how to organise/structure specifications using different formalisms,

how to relate aspects covered in different partial specifications, how to obtain the meaning

of a multi-paradigm specification and how to check for consistency.

Major shortcomings of the framework are that most formalisms can be translated at most

partially into predicate logic7and that the interpretation of a multi-paradigm specification

as the conjunction of the assertions associated with its partial specifications is not intuitive

and hence very difficult to understand.

An instance of this framework is presented in [Zave and Jackson, 1996]. The instantiation is

achieved by fixing a particular decomposition style and system model. The formalisms used

by this instance are primarily Z and finite state machines.

Composing Specifications

Abadi and Lamport [1993] have analysed sufficient conditions that specifications of concur-

rent components must satisfy in order to be successfully composed to a system specification

with given properties.

They have investigated these conditions in a general semantic model, namely the transition-

axiom method (TAM), which is an extension to temporal logic. That is, their composition

principles are independent of particular specification languages. As long as the semantics

of a specification formalism can be mapped to the TAM model, it can be used to specify

components of the system under development. Thus, the TAM model can be regarded as a

common, underlying semantic model in which the meaning of system components, possibly

specified by several formalisms, can be expressed. The meaning of the composition of a set

of component specifications is defined to be the conjunction of the meaning associated with

the component specifications.

Note that in this approach the decomposition of a system into the parts that are covered by

distinct formalisms is absolutely different from the decomposition in the other approaches

discussed in this chapter. In the current approach, different “partial specifications” describe

different system components, so there is no overlap between different partial specifications.

In the other approaches, in contrast, different partial specifications describe the same system

from distinct viewpoints, where the covered aspects usually overlap. Thus, the approaches

are based on orthogonal principles for decomposing system specifications.

7Große-Rhode [2001] suggests transformation systems as a semantic domain into which all kinds of specifica-

tion languages can be mapped semantically. His approach is more general because transformation systems,

which extend labelled transition systems, are more powerful than first-order predicate logic.

Chapter 5

Classification

Considering the plethora of approaches discussed in the previous chapter and the interna-

tional conferences dedicated to this subject, e.g., [Grieskamp et al., 2000, Ehrig and Große-

Rhode, 2002], we conclude that integrating existing formalisms has become a research field

of growing interest. To get a better overview of the field and to have a basis for categorising

our approach into the existing work, we propose a classification of approaches to combin-

ing/integrating existing formalisms. On the top level of this classification, we distinguish

between two classes.

In component-oriented approaches, the structure of composing the deployed base formalisms

corresponds to the component structure of the specified system, i.e., each component of the

system under development is specified by a particular base formalism. The only instance

of this class described in the previous chapter is the approach of Abadi and Lamport [1993].

In viewpoint-oriented approaches, by contrast, different base formalisms are used in order to

cover different aspects of the system under development. That is, the composition of the

used base formalisms is orthogonal to the component structure of the specified system: each

system component is specified using several base formalisms. All approaches discussed in

the previous chapter with the exception of that of Abadi and Lamport belong to this class.

Let us further refine the class of viewpoint-oriented approaches by proposing three sub-

classes. All three sub-classes can be thought of as being located within a spectrum of the

degree of integrating the respective base formalisms, see Figure 5.1.

Viewpoint-oriented Combinations. One end of the spectrum, with a low degree of integra-

tion, is occupied by the class of viewpoint-oriented combinations. They are frameworks for

combining multiple languages rather than particular combined languages. They provide an

infrastructure containing general techniques and guidelines

•to decompose complex specifications into viewpoints (partial specifications),

•to relate common aspects of different viewpoints,

•to map all viewpoints to a common, underlying semantic model and

•to check a multi-viewpoint specification for consistency.

32 Chapter 5. Classification

degree of integration

viewpoint-oriented

combinations conserving

integrations monolithic

integrations

fixed

decomposition

style

reuse

of semantic

definitions

general frameworks

for combining

formalisms

new syntax

new, common

semantic model

trade-off:

reuse

potential

vs.

coherence,

uniformity

Smith/Derrick RT-Z CSP-OZ TCOZ RSLLOTOS

Zave/Jackson

Boiten et al.

Weber

Figure 5.1: Viewpoint-oriented approaches to integrating formalisms.

In other words, viewpoint-oriented combinations do not fix a particular decomposition style.

We use the term decomposition style of a multi-language specification to refer to the infor-

mation

•of which concrete constituents it is composed,

•which base formalisms are associated with its constituents and

•the concrete correspondences via which its constituents are related.

Particular instances of such frameworks, however, define specific decomposition styles on

the basis of the general guidelines prescribed by the framework.

Instances of this class are the approaches proposed by Zave and Jackson [1993], Weber [1997],

Boiten et al. [1996] and Große-Rhode [2001].

The main advantage related to viewpoint-oriented combinations is the possibility to use the

base formalisms within viewpoints without the need of adaptation. This allows specifiers to

make use of the infrastructure available for the respective base formalisms, e.g., specification

and verification tools, and of their gained knowledge and experience. Another advantage

is the flexibility to use the particular base formalisms best suited for a particular specifica-

tion task. A further aspect of flexibility is the high independence of a viewpoint-oriented

combination from potential changes of the used base formalisms.

The most serious disadvantage associated with viewpoint-oriented combinations, on the

other hand, is that a multi-paradigm specification is not really a single document but rather

an independent coexistence of loosely coupled partial specifications, i.e., there is a low co-

herence between the combined base formalisms. That is, it is difficult to understand the

interaction between different partial specifications and to obtain the overall picture drawn

by all partial specifications together. Another major problem related to viewpoint-oriented

combinations is due to the fact that a single artifact of the software development can be sub-

ject to several viewpoints. Thus, it is a major concern to ensure the consistency between

different viewpoints.

The other two classes—conserving and monolithic integrations—differ from viewpoint-ori-

ented combinations in that they fix a particular decomposition style, i.e., they define a fixed

set of base formalisms to be deployed and fixed correspondences that relate the selected base

formalisms to each other.

Monolithic Integrations. The other end of the spectrum, with a high degree of integration,

is occupied by the class of monolithic integrations. In this class, the chosen base formalisms

are integrated very closely leading—more or less—to a completely new formalism.

In the first step of the integration, selected elements of the notations of the base formalisms

are merged, yielding the notation of the integrated formalism. That is, monolithic integra-

tions do not pursue the separation of their base notations. The next step lifts the selected ele-

ments of the base notations to a uniform semantic interpretation, which necessarily differs

from their original interpretation. This lifting, however, impedes the reuse of the semantic

definitions of the base formalisms when defining the unified semantics of the integrated for-

malism. This can be illustrated with the help of the monolithic integration TCOZ. In TCOZ,

the notations of Object-Z and timed CSP are merged very deeply: Object-Z operation sche-

mas can be used in timed CSP expressions to represent terminating processes, and the TCOZ

state guard operator uses an Object-Z schema expression to prefix a timed CSP process ex-

pression in order to make the flow of control dependent on the current data state. Therefore,

Object-Z schema expressions and timed CSP expressions need to be lifted on a uniform se-

mantic interpretation; the semantic function of timed CSP cannot be applied to these TCOZ

process expressions because of the contained Object-Z expressions.

Instances of this class are the RAISE specification language (RSL), CSP-OZ and TCOZ.

The most notable merit of monolithic integrations is the strong coherence between the base

formalisms and the notational conciseness of being able to directly merge the syntaxes of the

base formalisms. Their essential drawback is due to the fact that the base formalisms are not

identifiable parts of the integrated formalism, impeding the reuse of their infrastructure.

Conserving Integrations. Last but not least, conserving integrations are located in the centre

of the spectrum. The major design criterion for conserving integrations is the possibility to

reuse the infrastructure of the selected base formalisms. This is the distinguishing feature

with respect to the class of monolithic integrations. Of particular interest for this distinction

is the reuse of the semantic functions of the base formalisms within the unified semantic

model of the integrated formalism.

Note that the transition between conserving and monolithic integrations is fluid, depicted in

Figure 5.1 by the dashed arrow: also monolithic integrations can make use of the semantic

definitions of their base formalisms to a restricted extent. Ultimately, the crucial decision

concerns the direction in which the trade-off between the potential to reuse the infrastructure

of the base formalisms on the one hand and the coherence and uniformity of the integrated

34 Chapter 5. Classification

formalism on the other hand is resolved. The reuse of the semantic definitions is only an

indication for the direction of this resolution.

To achieve this reuse potential, conserving integrations interrelate their base formalisms

more loosely: each base formalism constitutes an identifiable part of the integrated for-

malism. Accordingly, each specification of an integrated formalism is composed of several

separated parts, each obtained by encapsulating the notation of a single base formalism.

The integration of these notationally separated parts to constitute a single, coherent unit is

achieved by defining correspondences (links) between specific notational elements of the

different parts. These correspondences are general in that they apply to all specifications of

an integrated formalism. The above points can be illustrated with the help of the approach of

Smith and Derrick [2001], in which the notations of Object-Z and CSP are strictly separated:

the Object-Z notation is used to define the behaviour of the system components and the CSP

notation is used to define the configuration of these components and their interaction. The

link between the parts consists in identifying processes in the CSP part and classes in the

Object-Z part that have identical identifiers.

Instances of this class are LOTOS, RT-Z and the approach proposed by Smith and Derrick

[2001]. A further instance is the approach of Treharne [2000], who has developed an integra-

tion of B and CSP, which uses CSP process descriptions (called control executives) to con-

trol the order of executing the operations that are specified in a B Abstract System. Finally,

Choppy et al. [2000] have proposed a conserving integration of an algebraic specification

language and state transition diagrams; the integrated formalism is called Korrigan.

The most important feature of a conserving integration is the architecture of composing its

base formalisms. In fact, the used base formalisms should be exchangeable. For LOTOS,

e.g., as an instance of this class, it is planned to replace its abstract data type language.

A major benefit of conserving integrations, as just indicated, is their ability to reuse the exist-

ing infrastructure of their base formalisms, e.g., tool support, proof support and the know-

ledge and experience of existing users. Compared with viewpoint-oriented combinations,

however, this reuse potential is more restricted because of the interdependencies between

the integrated base formalisms. A disadvantage, on the other hand, which is a consequence

of the separation of the base notations, is the lower notational conciseness and convenience

than in monolithic integrations.

To conclude, conserving integrations are a compromise between viewpoint-oriented com-

binations and monolithic integrations; they hence avoid some disadvantages of the other

classes, but cannot fully exploit their advantages.

Part II

RT-Z: An Integration of

Z and Timed CSP

This part presents a conserving integration of the formal specification languages Z and timed

CSP. This integrated formalism is designed to support the development process of real-time

embedded systems in several phases—from the requirements engineering via the architec-

tural design to the detailed design.

Embedded systems usually exhibit complex interrelations with their external environment

in addition to complex internal structures. A specification language intended for the chosen

application domain must cope with several dimensions of this complexity, mainly

•the static structure,

•the dynamic behaviour and

•the data-related characteristics

of embedded systems.

Let us first clarify the above terminology. The term static structure refers to invariant char-

acteristics of an embedded system, e.g., the structure of its interface and its architecture.

We use the term dynamic behaviour to combine the terms external stimulus–response behaviour

and internal control behaviour. The external stimulus–response behaviour of an embedded

system incorporates aspects like the temporal ordering of external interactions with the en-

vironment and also real-time constraints on their occurrence. It defines the reaction of the

embedded system to external stimuli in terms of emitting responses into the environment.

The internal control behaviour, on the other hand, involves the distribution and control of

internal actions that implement the external interaction with the environment. Finally, the

term data-related characteristics encompasses aspects like the structure and the invariant prop-

erties of the data state1of an embedded system as well as the relationships that must hold

between the data values communicated with particular external interactions.

The above dimensions roughly correspond to the three views on embedded control sys-

tems identified by Weber [1997], which he termed architectural model, behavioural model

and functional model. We do not adopt this terminology, because these terms suggest a

viewpoint-oriented approach (cf. Chapter 5), which we do not follow as we will shortly ar-

gue.

The Z notation [Woodcock and Davies, 1996] is a powerful vehicle for specifying data-related

characteristics and fragments of the static structure. However, it is not designed to model

aspects of the dynamic behaviour. The real-time process algebra timed CSP [Schneider,

1999b], on the other hand, is a powerful tool for specifying the dynamic behaviour, includ-

ing real-time aspects, and fragments of the static structure. However, it does not provide

adequate constructs to model data-related characteristics. The two formalisms can hence be

considered to be complementary, covering disjoint aspects of real-time embedded systems.

Further, their underlying concepts are well suited to each other. This part deals with an

integration of Z and timed CSP, called RT-Z. It exploits the strengths of both formalisms in

1An embedded system maintains an internal data state in order to control its interaction with the environment.

This data state reflects relevant properties of its past interaction that determine its ability to interact with the

environment in the present and future. Transitions on that data state (operations) are defined in order to react

to the occurrence of external interactions.

order to provide a smoothly integrated, single formalism to model all relevant dimensions

of real-time embedded systems. The base formalisms of RT-Z are outlined in Appendix A.

For a description of the general features of RT-Z that is more compact than our treatment

in this thesis, consult [S¨

uhl, 2002] and [S¨

uhl, 1999]. A predecessor of RT-Z is discussed in

[Heisel and S¨

uhl, 1996].

This part is organised as follows. In Chapter 6, we describe the general principles underlying

our integration of Z and timed CSP. In particular, we distinguish between two models of

integration—an abstract and a concrete one—needed to cover the different abstraction levels

involved during the development process. Then, in Chapter 7, we introduce specification

units, the building blocks of RT-Z specifications, which constitute the frames within which

the notations of Z and timed CSP are integrated. Finally, the structuring mechanisms of RT-

Z, which allow us to decompose the specification of complex, highly concurrent systems, are

introduced and defined in Chapter 8.

Chapter 6

Integration Principles

According to our classification of approaches to combining formalisms proposed in

Chapter 5, RT-Z is a conserving integration of Z and timed CSP. The notations of the base

formalisms are hence separated from each other. Accordingly, each RT-Z specification con-

sists of two parts:

•The data-related characteristics and fragments of the static structure are specified by

using the Z notation. We refer to this part as the ‘Z part.’

•The dynamic behaviour and the remaining fragments of the static structure are spe-

cified by using the notation of timed CSP. We call this part ‘CSP part.’

As a conserving integration, RT-Z defines several links between specific elements of its parts;

these links achieve the integration of the notationally separated parts to constitute a single,

uniform specification.

The fragments of the notations of Z and timed CSP used in the parts and the links with which

the parts are related to each other depend on the particular phase within the development

process that is to be supported. There is an abstract and a concrete model of integration; they

are the subject of the following two sections.

6.1 Specifying Properties (Abstract Model of Integration)

The aim of the early phases of the development process, i.e., the system and software re-

quirements specification phases, is to specify properties of the artifact1in question without

fixing any implementation aspects. The following types of properties must be covered by a

formalism designed to specify real-time embedded systems.

1. The temporal ordering of interactions at the external interface of the considered artifact,

possibly including real-time constraints.

1An artifact can be a real (physical) system or a piece of software depending on the current phase of the system

development process.

40 Chapter 6. Integration Principles

2.Relationships that must hold between data values communicated between the considered

artifact and its environment via particular external interactions (I/O relations).

3.Properties of data states present at specific time instants during the evolution of the arti-

fact.

It depends on the current phase of the development process which of these types are really

relevant. In this section, a predicate language is introduced that is suited to the abstract

specification of all these types of properties, in separation as well as in connection with

each other. Evidently, properties of the first two types can hardly be specified in isolation,

because data values, about which requirements are to be specified, are communicated with

interactions at the external interface. The predicate language, informally introduced in this

chapter, is backed up formally in Chapter 9. The purpose of each predicate is to induce the

set of valid timed observations of the artifact under consideration. The structure of these

timed observations is defined in detail in Chapter 9; for the time being, let us outline their

structure as follows: each timed observation associated with an RT-Z specification consists

of a timed trace s, a timed refusal ℵand a timed state tst. The structure of the pair (s,ℵ)is

identical with the denotations of timed CSP processes and denotes the external interaction

of the specified artifact within the observation interval. The timed state tst, on the other

hand, is a function that records the evolution of the artifact’s data state in the observation

interval. In other words, the purpose of each predicate of RT-Z’s predicate language is to

induce a relation between the timed trace, timed refusal and timed state components of

timed observations (denotations). Throughout this thesis we use the convention that the

timed trace, timed refusal and timed state components of a timed observation are denoted

by the identifiers s,ℵand tst, respectively. That is, these identifiers are free variables of any

predicate. We do not make explicit this dependence of RT-Z predicates on these identifiers.

Concerning the specification of temporal ordering and real-time properties, i.e., properties

with respect to the acceptance and refusal of interactions at the external interface, we adopt

the macro language introduced by Schneider [1999b], which we discuss in Section A.2. These

macros refer to the timed failure component (s,ℵ)of a timed observation.

Regarding the second type of properties—the specification of I/O relations—we include a

new language construct into the predicate language: references to Z schemas. For each

(separately specified) Z schema

IORel == [ var1 : T1; . . . ;varN :TN |Pred ],

the expressions of the predicate language can contain the reference

IORel(var1b=expr1, . . . , varN b=exprN),

where expr1, . . . , exprN are timed CSP expressions evaluating to an (untimed) trace or re-

fusal.2These trace and refusal expressions contain the information which particular data

values have been communicated with the occurrence of particular events along the corres-

ponding channels (and have been refused to be communicated, respectively). The above

schema reference associates the schema components var1, . . . , varN with the expressions

2Untimed refusals and traces are sets and finite sequences corresponding to the Z type constructors Pand seq,

respectively. T1,...,TN have thus the form PXor seq X.

6.1. Specifying Properties (Abstract Model of Integration) 41

expr1, . . . , exprN. The informal meaning of this reference is that the evaluated expressions

expr1, . . . , exprN must satisfy the conditions specified by the schema IORel with respect to

the variables var1, . . . , varN.

Therefore, the ability to refer to Z schemas and to associate their components with trace and

refusal expressions allows us to express relationships between data values that are commu-

nicated with particular events at the external interface. This is achieved by means of the Z

notation, which is tailored to this task.

We illustrate the predicate language of RT-Z with the help of the requirements specification

of a reliable communication medium, which is situated between an input channel InChn

and an output channel OutChn and must transmit arbitrary messages in the correct order

without any corruption. In the following, we discuss the specification of three requirements

depicted in Figure 6.1, which the medium must meet.

The first requirement Req1concerns the temporal ordering of external interactions. At any

time during the protocol execution, at most one message delivered to the protocol machine

at the input channel (InChn) may be pending, i.e., not yet delivered to the environment at the

output channel (OutChn). This means that a new message should be accepted at the input

channel only when a successful output on the output channel has been acknowledged.

Req1b=∀t:T•0≤(sttr t)↓ttr {| InChn |} − (sttr t)↓ttr {| OutChn |} ≤ 1

The above predicate restricts the set of timed traces sthat are valid observations of the pro-

tocol behaviour (the components ℵand tst are left unrestricted). It uses functions operating

on timed trace expressions, which are explained in Appendix E. The expression sttr tyields

the timed trace up to and including time t, which records all timed events that occurred

before time t. Then, the expression sttr t↓ttr {| InChn |} yields the number of events that

occurred on channel InChn before time t. Thus, in the above predicate, we compare the num-

ber of events that are communicated along the channels InChn and OutChn, respectively, for

each time interval [0,t].

The second requirement Req2involves the data values communicated with external inter-

actions: if a message is delivered to the environment at the output channel OutChn, then

this message must not be corrupted, i.e., the contents of transmitted messages must not be

changed.

IsPrefix == [ in,out : seq Message |out prefix in ]

Req2b=∀t:T•IsPrefix(in b= strip((sttr t)ttr {| InChn |}),

out b= strip((sttr t)ttr {| OutChn |}))

The I/O relation schema IsPrefix simply specifies a relationship between the sequences in

and out:out must be an initial prefix of in. This Z schema, interpreted in isolation, does not

restrict the behaviour of the protocol at all; only the association of the schema components

in and out with particular trace expressions within the predicate Req2achieves this. The

schema reference associates in with the expression strip(sttr tttr {| InChn |})(the events

that occurred on channel InChn before time t) and the component out with the expression

strip(sttr tttr {| OutChn |})(the events that occurred on channel OutChn before time t).

Req2therefore requires, for each time instant t, that the sequence of messages delivered at the

output channel must be a prefix of the sequence of messages received at the input channel.

42 Chapter 6. Integration Principles

SPEC.UNIT ReliableMedium

TYPES & CONSTANTS

[Message]

INTERFACE

port InChn,OutChn domain Message

I/O RELATIONS

IsPrefix == [ in,out : seq Message |out prefix in ]

STATE PROPERTIES

State == [ pending : seq Message ]

Buffered == λin,out : seq Message •

[State |pending = (λi:N•i+ #out)o

9(domout −

Cin) ]

BEHAVIOURAL PROPERTIES

Req1b=∀t:T•0≤(sttr t)↓ttr {| InChn |} − (sttr t)↓ttr {| OutChn |} ≤ 1

Req2b=∀t:T•IsPrefix(in b= strip(sttr tttr {| InChn |}),

out b= strip(sttr tttr {| OutChn |}))

Req3b=∀t:T•

let in == strip(sttr tttr {| InChn |}); out == strip(sttr tttr {| OutChn |})•

Buffered(in,out)at t

Behaviour sat Req1∧Req2∧Req3

Figure 6.1: Reliable communication medium: requirements.

Finally, properties of the third type are specified in isolation as well as in connection with

properties of the first two types. On the one hand, one might want to specify invariants of the

data state of the artifact in question. On the other hand, one might be faced with properties

of the data state that must be satisfied depending on particular interactions at the interface.

To enable us to formulate requirements with respect to the evolution of the data state, i.e.,

6.1. Specifying Properties (Abstract Model of Integration) 43

to refer to the timed state component (tst) of a timed observation, we provide additional

specification macros. They state properties that particular data states within the observation

interval must exhibit.

We call such properties ‘time-variant state properties.’ Each of the additional specification

macros expressing time-variant state properties relates a Z schema, specifying a particular

property of the data state, and a time interval (or time instant). The timed state component

tst of a timed observation meets such a specification macro if, and only if, all data states that

are recorded in tst within the respective time interval (at the respective time instant) have

the property expressed by the respective schema.

In this section, we give only an informal description of these specification macros. A com-

plete definition is possible only after the discussion of the semantic model in Chapter 9.

Suppose in the following that Prop is a Z schema.

at: The specification macro (Prop at t) is satisfied by a timed state tst if, and only if, the last

data state that is recorded in the timed state tst before time instant t(inclusive) has

property Prop.

before: The specification macro (Prop before t) is satisfied by a timed state tst if, and only if,

the last data state that is recorded in the timed state tst before time instant t(exclusive)

has property Prop.

during: The specification macro (Prop during INT) is satisfied by a timed state tst if, and only

if, all data states of tst during interval INT have property Prop.

invariant: (Prop invariant) is satisfied by a timed state tst if, and only if, each data state of tst

has property Prop, i.e., if Prop is an invariant property.

Returning to our example, there is a time-variant state property we should require: at any

time during the protocol execution, the protocol machine must record in its data state the

sequence of messages (pending) received on the input channel but not yet delivered to the

output channel.3

State == [ pending : seq Message ]

Buffered == λin,out : seq Message •

[State |pending = (λi:N•i+ #out)o

9(domout −

Cin) ]

Req3b=∀t:T•

let in == strip((sttr t)ttr {| InChn |}); out == strip((sttr t)ttr {| OutChn |})•

Buffered(in,out)at t

The State schema introduces the data state of the protocol with a single component pending.

Further, Buffered is a function whose range are the subsets of schema bindings associated

with the schema State. Applied to the message sequences in and out, it restricts the com-

ponent pending to contain the difference between the sequences in and out, i.e., the messages

contained in in but not contained in out. The function is applied to the sequence of messages

received at the channel InChn and the sequence of messages delivered at the channel OutChn

3In our example, pending can contain at least one message.

44 Chapter 6. Integration Principles

in the context of the predicate Req3. Altogether, Req3requires that the protocol must always

record the messages already received but not yet delivered in an appropriate order.

Note that the specification of time-variant state properties makes sense only if a model of

the data state has been defined before. Specifying properties of the data state is reasonable

only in the system requirements specification phase,4in which one is concerned with systems

with a ‘physical’ state and where one must guarantee properties of this ‘physical’ state.

We add to the syntax of predicates as just described the ability to parametrise predicate

definitions by a list of identifiers.

ID(fp1, . . . , fpN)b=Pred

Pred in the above definition can contain free occurrences of fp1, . . . , fpN at arbitrary places.

Each reference to such a parametrised predicate definition must be supplied with a list of

actual parameters of the same length. Formal and actual parameters are identified accord-

ing to their position in both lists. The meaning of referring to such a parametrised predicate

definition is given by a simple textual substitution: the reference is substituted by the right

hand side of the predicate definition where all free occurrences of formal parameters are sim-

ultaneously substituted by the corresponding actual parameters, supplied in the reference.

Let us elaborate the above in the light of our classification of RT-Z as a conserving integra-

tion. Each RT-Z specification in the abstract model consists of two parts: a Z part encapsulat-

ing the Z notation, used to express properties of data values communicated at the external

interface and of the data state evolution; and a CSP part encapsulating the timed CSP nota-

tion, applied to formulate properties of the dynamic behaviour. Basically, there are three

types of links between the parts, which are outlined in Figure 6.2.

First, interactions between an artifact and its environment are modelled in timed CSP by

synchronous events, which may represent mere synchronisations or the communication of

arbitrarily complex data values. Accordingly, timed CSP allows one to associate type infor-

mation with channels. However, this is supported only in a rather rudimentary way, because

timed CSP lacks an appropriate notation to specify data types.5To overcome this problem

in RT-Z, we associate a value domain with each channel, i.e., an expression that, evaluated in

the context of the Z part, denotes a set of data values. That is, the occurrence of an event on

a particular channel coincides with the transmission of a data value that must be a member

of the associated set.

Second, the predicates in the CSP part, defining the dynamic behaviour, can refer to schemas

defined in the Z part in order to express relationships that must hold between data values

communicated with external interactions (I/O relations). Within such a schema reference,

data values communicated with particular events are bound to the components of the refer-

enced schema.

Finally, the predicates in the CSP part can refer to schemas specified in the Z part in order to

define time-variant state properties, i.e., properties that the evolution of the data state must

4as opposed to the software requirements specification phase

5Regarding plain CSP, the current input language of the model checker FDR2 [Formal Systems (Europe) Ltd,

2000], CSPM, comprises a syntax for expressions, types and channel declarations. Moreover, Scattergood

[1998] has defined a formal semantics for CSPM.

6.2. Specifying Models (Concrete Model of Integration) 45

INTERFACE

port In domain T1;

port Out domain T2

BEHAVIOURAL PROPERTIES

Behaviour sat

...

In.val1at t1

⇒

...

Out.val2live t2

∧

IORel(in b=val1,out b=val2)

∧

StateProp(...val1...)at t3

TYPES & CONSTANTS

[T1,T2]

I/O RELATIONS

IORel

in :T1

out :T2

out =...in ...

STATE PROPERTIES

State

StateProp == λval :... •

[State |...val ...]

I/O

relation

time-variant

state property

value

domain

CSP part

Z part

Figure 6.2: Links between the parts.

meet in the context of particular external interactions. To this end, we employ the macro

language introduced in this section.

The meaning of an RT-Z specification in the abstract model, as formally defined in Chapter 9,

is the meaning of its CSP part. The Z part serves to establish the context for the CSP part.

6.2 Specifying Models (Concrete Model of Integration)

The aim of the later phases of the development process, i.e., the system and software design,

is to fix a more or less detailed model of the implementation of the considered artifact, which

has to satisfy properties, abstractly specified as outlined in the previous section.

Consider first the Z part of an RT-Z specification in the concrete model. Its purpose is the

specification of the data-related characteristics and fragments of the static structure of the

artifact under consideration. The following aspects are to be covered.

•The structure and invariant properties of the valid data states.

•Operations on that data state, which define state transitions.

•Predicates on that data state, expressing conditions to be evaluated with respect to the

current data state.

46 Chapter 6. Integration Principles

•Constants denoting parameters of the artifact under consideration.

•Data types associated with the channels of the interface, restricting the set of data

values that can be communicated.

In the current, concrete model of integrating Z and timed CSP, we apply the predominant

state-oriented conventions of using Z to formulate the above aspects. This is a contrast to

the abstract model dealt with in the previous section.

Following Broy et al. [1992], the specification of a data state and its operations does not

necessarily constrain the final implementation to have an implementation of the data state

and all its operations. Rather, the state machine model is a tool for specifying the data-

related characteristics at the external interface more succinctly and conveniently. The current

data state of an artifact can be interpreted as representing the relevant properties of the past

interaction that determine the artifact’s ability to interact with the environment in the present

and future.

The CSP part, on the other hand, serves to specify the dynamic behaviour and the remaining

fragments of the static structure of the considered artifact, including the following aspects.

•The external stimulus–response behaviour, i.e., its reaction to external stimuli (input

events at the external interface which can carry arbitrarily complex values) in terms of

emitting responses (output events at the external interface which can also carry arbit-

rarily complex values) into the environment.

•The internal control behaviour, i.e., how it distributes and controls internal actions in

order to implement the external interaction with the environment.

•The architecture of the considered artifact, i.e., its decomposition into particular com-

ponents including their interaction via particular channels.

•The structure of its interface.

In the current, concrete model we use the process term language of timed CSP, which allows

us to fix concrete models covering the above aspects.

Links. Basically, there are four types of links between the Z part and the CSP part, which

are shown in the Figures 6.3 and 6.4.

The first type of link is also present in the abstract model of integration: channels in the CSP

part are associated with value domains defined in the Z part.

Second, timed CSP provides indexed forms of some operators, e.g., of the interleaving op-

erator |||. They are parametrised by an index set, whose members are used to identify the

individual processes being composed. However, timed CSP does not provide an adequate

notation to specify these index sets formally. In RT-Z, by contrast, each index set is formally

defined in terms of an expression that, evaluated in the context of the Z part, denotes a set

of index values.

Third, timed CSP extends (plain) CSP with real-time operators, which are operators with

real-valued parameters. The Z part serves, among other things, to declare and constrain

6.2. Specifying Models (Concrete Model of Integration) 47

Z part

TYPES & CONSTANTS

[Set1]

Set2 : PSet1

IS ::= ...

t:T

t>R...

STATE

State

...

Init

State

...

OPERATIONS

∆State

in?,out! : Set1

...

index

set

real-time

parameter

operation

termination

operation

invocation

INTERFACE

port In domain IS ×Set1;

port Out domain IS ×Set1

BEHAVIOUR

Behaviour b=

|||

i∈IS

In?val : ({i} × Set2) →

OpI?par : [ in? : Set1|in? = val.2 ] →

Wait t;

OpT?par : [ out!:Set1 ] →

Out!(i,par.out!) →...

|[{| In |} ∪ {| Out |} ]|

...

CSP part

value

domain

Figure 6.3: Links between the parts (double event approach).

constants of type T, which denotes the time domain of timed CSP and also of RT-Z. Each

real-valued parameter occurring in the CSP part must be given in terms of an expression

that, evaluated in the context of the Z part, denotes a value of type T.

Finally, one of the main tasks of the CSP part, as already indicated, is to control the execution

of the operations specified in the Z part. To model this control relationship, there are two

alternatives for relating Z operations and CSP events. The choice depends on the required

abstraction level; more specifically, it depends on whether or not the specifier intends to

abstract from the time needed to execute an operation.

In the case in which the time interval of executing an operation, say Op, is relevant, the op-

eration schema Op of the Z part is related to the pair of dedicated channels OpIand OpT,

on which the CSP part communicates in order to control the execution of the operation.

This case is depicted in Figure 6.3. Events on the channel OpIrepresent the invocation of

the operation Op with a particular assignment of values to the input parameters. The data

value that is communicated with such an invocation event between the invoking CSP pro-

cess and the invoked Z operation is a schema binding mapping each input parameter of the

corresponding operation schema to a value. It denotes the agreement of the two parts on

particular values of the input parameters with which the operation is invoked.6Events on

the second channel of the pair, OpT, represent the termination of the invoked operation Op.

The produced output parameters are transmitted with such a termination event between the

6Each channel OpIis implicitly associated with the value domain that includes all bindings of the input par-

ameters of the operation schema Op.

48 Chapter 6. Integration Principles

TYPES & CONSTANTS

[Set1]

Set2 : PSet1

IS ::= ...

t:T

t>R...

STATE

State

...

Init

State

...

OPERATIONS

∆State

in?,out! : Set1

...

Z part

operation

execution

index

set

INTERFACE

port In domain IS ×Set1;

port Out domain IS ×Set1

BEHAVIOUR

Behaviour b=

|||

i∈IS

In?val : ({i} × Set2) →

Wait t;

OpX?par : [ in?,out! : Set1|in? = val.2 ] →

Out!(i,par.out!) →...

|[{| In |} ∪ {| Out |} ]|

...

CSP part

real-time

parameter

value

domain

Figure 6.4: Links between the parts (single event approach).

terminated operation and the invoking CSP process.7

Relating an operation to a pair of channels and an operation execution to a pair of events,

respectively, allows us to specify requirements concerning the interval of an operation exe-

cution, for instance, constraints on its duration.

In the other case, in which these time intervals are not relevant, an operation schema Op

of the Z part is related to a single channel OpX. This case is depicted in Figure 6.4. Events

on this channel represent the instantaneous execution of the operation. The data value that

is communicated with such an execution event between the executed Z operation and the

executing CSP process is a schema binding mapping each input and output parameter of the

corresponding operation schema to a value. It denotes the agreement of the two parts on

particular values of the input parameters and the sole fixing of the output parameter values

by the Z operation.8

According to the terminology proposed by Fischer [1998], these cases are called the double

and single-event approach, respectively. They can be combined arbitrarily in a single RT-Z

specification. That is, some operations of the Z part can be controlled by means of the single-

event approach, while the remaining operations are controlled by using the double-event

approach.

7Each channel OpTis implicitly associated with the value domain that includes all bindings of the output

parameters of the operation schema Op.

8Each channel OpXis implicitly associated with the value domain that includes all bindings of the input and

output parameters of the operation schema Op.

6.2. Specifying Models (Concrete Model of Integration) 49

external

interactions

internal actions

(operations)

|[ORE ]|

\ORE

timed CSP

interpretation

Z part

(timed)

CSP part

concrete specification unit

external behaviour at interface:

denotations without ORE

internal behaviour:

denotations with ORE

(operation related events)

Figure 6.5: Principle of composing the Z part and the CSP part.

Main Principle. Now, we are in a position to discuss the main principle underlying the

integration of Z and timed CSP in the concrete model. This principle follows an idea of Smith

[1997], which he applied to the integration of plain CSP and Object-Z. Following this idea

and adapting it to our specific context, we are able to interpret a Z specification as a timed

CSP process: a process that controls the events related to its operations as follows. It accepts

the invocation/execution of an operation with particular input parameters if, and only if, the

precondition of the corresponding operation schema is satisfied with respect to its current

data state and the supplied input parameters; otherwise, it blocks the invocation/execution

of the operation. The termination of an invoked operation with particular output parameters

is accepted under analogous conditions.

By interpreting the Z part of an RT-Z specification as a timed CSP process, the meaning of

the overall specification is defined as the parallel composition of the CSP part and the timed

CSP interpretation of the Z part, where both parts synchronise on the set of operation-related

events, i.e., on the execution, invocation and termination of operations. These operation-

related events are defined to be internal by hiding them from the environment of the parallel

composition. That is, the occurrence of operation-related events is completely controlled by

the considered artifact and not visible to the environment. This principle of composing the

parts is outlined in Figure 6.5.

As a consequence of composing the Z and the CSP part in the chosen way, an operation is

invoked/executed only if the corresponding invocation/execution event is accepted by both

parts simultaneously; when both parts accept an event, they also agree on a specific assign-

ment of values to the input parameters. This means that the specific values with which an

operation is invoked/executed are equally influenced by both the corresponding Z opera-

tion schema and the value denotation of the corresponding CSP event.

Note that we adopt a view of the application of Z operations that is usually called the ‘block-

ing view’: an operation can be invoked/executed only within its precondition; outside its

precondition, the invocation/execution is blocked.

Due to the chosen way of composing the two parts, we are able to express another relation-

ship between the Z and the CSP part by employing only the links already described. The

dynamic behaviour of an artifact, specified in the CSP part, usually depends on its current

data state, specified in the Z part. In RT-Z, such a kind of dependence is modelled in terms

50 Chapter 6. Integration Principles

of an operation schema, say Pred, that does not change the data state (ΞState) and whose pre-

condition is equivalent to the condition on the data state to be evaluated. According to the

integration principles just discussed, the occurrence of the execution event PredXimplies the

successful evaluation of the precondition of the operation schema with respect to the current

data state, in other words, the successful evaluation of the condition to be evaluated.

Parameter Exchange. Let us have a closer look at the interaction between the Z and the

CSP part that takes place when an operation is executed (single event approach). An exe-

cution event, representing the instantaneous application of an operation, communicates the

input and output parameters of the operation. The values of the input parameters must be

agreed on by both the Z operation and the executing CSP process, whereas the values of

the output parameters are solely determined by the executed Z operation. We discuss the

structure of the value denotation of an execution event within the CSP part.

The value communicated with an execution event is a binding, mapping each operation

parameter to a value. Since the output parameters should be solely determined by the Z op-

eration, the value denotation of the execution event in the CSP process must allow arbitrary

values for the output parameters. In contrast, the value denotation of the execution event

must allow us to express arbitrary constraints on the values of the input parameters. These

constraints usually depend on values bound by the CSP process during prior event occur-

rences. The Z operation, by definition, accepts all combinations of input parameter values

that satisfy its precondition with respect to the current data state.

Let us consider the value denotation of an execution event OpXas an example.

OpX?par : [ in? : T1; out! : T2|in? = in†]

The above schema expression defines a set of bindings of the input parameter in?and the

output parameter out!. In these bindings, in?is uniquely determined by the value in†, which

can be thought of as being a variable bound during a prior event occurrence. The Z part

accepts all input parameter values in?satisfying the precondition of Op with respect to the

current data state. That is, the execution event OpXoccurs if, and only if, the precondition

is satisfied with respect to the combination of the value in†and the current data state. The

value of out!, by contrast, is left unspecified by the schema expression and hence by the CSP

part.

Analogous remarks apply to the double event approach. Let us consider the value denota-

tion of an invocation event OpIas an example.

OpI!h| in? == in† |i

Since only input parameters are communicated with invocation events (no output param-

eters!), the binding set associated with an invocation event is singleton if, and only if, the

values of all input parameters are uniquely fixed by the invoking CSP process. This is the

case in the above example, where the channel output operator is used to fix this unique

binding of input parameters.

On the other hand, the value denotation of a termination event, e.g.,

OpT?par : [ out! : T2 ]

6.2. Specifying Models (Concrete Model of Integration) 51

must allow arbitrary output parameter values, which are solely determined by the invoked

operation.

This completes our discussion of the basic principles underlying the abstract and concrete

model of integrating Z and timed CSP. In the next chapter, we deal with the notation of the

two models of integration: abstract and concrete specification units.

52 Chapter 6. Integration Principles

Chapter 7

Specification Units

To manage the inherent complexity of systems, software and systems engineering1interpret

a system as a hierarchical composition of interacting subsystems and system components.2

Accordingly, the specification of a complex system in RT-Z is composed of a hierarchy of

units, which we call specification units. A basic specification unit defines the behaviour of a

single system component, and the appropriate composition of specification units, forming

compound specification units, produces subsystem and ultimately system specifications. In

other words, specification units are a means for structuring system and subsystem specifi-

cations. Specification units correspond to system units. A system unit can be thought of as

being an instance/implementation of a specification unit, which defines its structure and be-

haviour. Each specification unit can have any number of instances. Hence, the relationship

between specification units and system units in RT-Z can be compared with the relation-

ship between classes and objects in an object-oriented approach. See also Figure 7.1 for an

illustration of the used terminology.

Each RT-Z specification consists of two fragments: the global definitions, introducing con-

stants and data types that are global with respect to the whole specification, and the de-

finition of the structure and behaviour of the system under development, consisting of a

hierarchy of specification units.

Hierarchical decomposition is a means for coping with the complexity of large and highly

concurrent systems. First, the hierarchical decomposition of a system specification in RT-Z

can reflect conceptual or physical structures within the problem domain, and it supports

encapsulation and separation of concerns. Thus, it is a prerequisite for a clear and problem-

oriented system description and hence for the intelligibility of the specified system and the

ability to analyse it. Second, specification units in RT-Z constitute the frames within which

concurrent activities working on a common (data) state space can be encapsulated. That is,

the hierarchical decomposition of a system specification is the only way in RT-Z to model

concurrency on a common data state space.

Syntactically, a specification unit is a named and delimited piece of an RT-Z specification. Its

1For a detailed account of the concepts underlying systems engineering consult [Kronl¨

of, 1993, Chapter 1] and

[Leveson, 1995].

2System components are subsystems that are not decomposed any further.

54 Chapter 7. Specification Units

system

subsystem

system component

system

unit

aggregating

aggregated

specification

unit

system spec.

subsystem spec.

component spec.

compound

basic

instance/

implementation

Figure 7.1: Used terminology.

coarse-grained structure is given by two parts (the Z and the CSP part), and its fine-grained

structure is given by a number of sections, where each section belongs to one part.

All specification languages that aim to cope with complex systems provide syntax to com-

pose specifications of simpler units in a hierarchical manner. Generally speaking, the RT-

Z concept “specification unit” corresponds to the B concept “machine” [Abrial, 1996], the

TLA+concept “module” [Lamport, 2000], the LOTOS concept “process” [Bolognesi et al.,

1995], the ASTRAL concept “process type definition” [Coen-Porisini et al., 1997], the Object-

Z concept “class” [Smith, 2000] etc.

In this chapter, we introduce the notation for defining single specification units. The struc-

turing mechanisms for building compound specification units are the subject of the next

chapter. As described in Chapter 6, there are two different models of integrating Z and

timed CSP. The structure of a specification unit depends on the chosen model. We first dis-

cuss the structure of specification units in the concrete model; afterwards, we describe this

structure for the abstract model.

7.1 Concrete Specification Units

We discuss concrete specification units with the help of the example started in Section 6.1,

where we have provided the requirements specification of a reliable communication me-

dium. In this section, we prepare the specification of the design of a particular protocol that

achieves such a reliable communication, namely of the alternating bit protocol. This design

specification can be completed only after the introduction of structuring mechanisms in the

next chapter.

The alternating bit protocol (ABP) is a specific design to meet the requirements specification

of the reliable communication medium in Section 6.1. The design is outlined in Figure 7.2.

sender receiver

ack_medium

msg_medium

ABProtocol

MsgSend MsgRcv

AckRcv AckSend

In Out

Figure 7.2: Alternating bit protocol: architecture.

7.1. Concrete Specification Units 55

There are two protocol components, sender and receiver, responsible for the protocol imple-

mentation at the input and output location and for communicating with an external sender

and receiver, respectively. The protocol components are connected by a pair of unreliable,

unidirectional communication media, msg medium and ack medium, which are themselves

modelled as system components rather than channels, because they have a non-trivial, time-

consuming behaviour. The message medium serves to transmit messages with an additional

protocol information from the sender to the receiver component, and the acknowledgement

medium serves to transmit acknowledgement bits the other way around. The protocol com-

ponents interact with the communication media through the channels depicted by arrows;

the channel MsgSend, for example, serves the sender component to deliver message/bit pairs

to the message medium.

To illustrate the discussion of concrete specification units, we choose the sender component

as an example, whose specification unit is depicted in Figure 7.3. Note that—for reasons of

presentation—we have made the specification unit Sender more complex than necessary in

order to cover most aspects of concrete specification units.

A template of concrete specification units is given in Figure 7.4. In the following, we discuss

the sections of concrete specification units in the context of the example.

A specification unit, if concrete or abstract, can be parametrised by a list of formal param-

eters fp1, . . . , fpN. The instantiation of these formal parameters by the context of the speci-

fication unit is discussed in detail in Section 8.5. The concrete specification unit Sender is

parametrised by the identifiers MSG,ACK and MaxDelay, which represent the message and

acknowledgement domains the sender component must be able to process and the time

period the sender component must wait for an acknowledgement of a sent message before

repeating the sending procedure.

Since the considered specification unit is a basic one, it contains neither an EXTENDS sec-

tion nor a SUBUNITS section. They are discussed in the next chapter when dealing with

structuring mechanisms.

TYPES & CONSTANTS:We distinguish between two kinds of types and constants that can

occur in a specification unit.

•Local types and constants are declared and constrained in the TYPES & CON-

STANTS section by using the Z notation. Their scope is the current specifica-

tion unit. Therefore, local types must not be used to define the value domains

of interface ports, because the scope of these local types does not encompass the

specification unit’s context, which must be able to refer to the interface.

•Global types and constants are formal parameters of a specification unit. They

are instantiated by the context into which the specification unit is embedded. A

specification unit can express constraints on the possible instantiations of a formal

parameter. This is achieved by additionally declaring the formal parameter in the

TYPES & CONSTANTS section and by defining appropriate constraints.

This mechanism of defining formal parameters of specification units in conjunc-

tion with constraints on their allowed instantiations makes specification units

56 Chapter 7. Specification Units

SPEC.UNIT Sender [MSG,ACK,MaxDelay ]

TYPES & CONSTANTS

[MSG,ACK]MaxDelay :T#ACK = 2

INTERFACE

port In domain MSG;

port MsgSend domain MSG ×ACK;

port AckRcv domain ACK

ENVIRONMENTAL ASSUMPTIONS

EA b=∀t:T;pck :MSG ×ACK •MsgSend.pck open t

STATE

State == [ curr :MSG;ack :ACK ]

OPS & PREDS [ CorrectAck,IncorrectAck ]

CorrectAck == [ ∆State;rec? : ACK |rec?6=ack ∧ack06=ack ]

IncorrectAck == [ ΞState;rec? : ACK |rec? = ack ]

Update curr == [ ∆State;curr? : MSG |curr0=curr?∧ack0=ack ]

Lookup == [ ΞState;curr! : MSG;ack! : ACK |curr! = curr ∧ack! = ack ]

BEHAVIOUR

Behaviour b=Receive

Receive b=In?(rec :MSG)→Update curr(rec)→Send

Send b=σ(MsgSend!(curr,ack)→Acknowledge)

Acknowledge b= (AckRcv?(rec :ACK)→

IncorrectAckX!h| rec? == rec |i → Send

CorrectAckX!h| rec? == rec |i → Receive)

.{MaxDelay}Send

Figure 7.3: Sender component: specification unit.

more self-contained.3

3In particular, the information needed to type-check the Z part of a specification unit independently of its

context is available within that specification unit.

7.1. Concrete Specification Units 57

SPEC.UNIT Name [fp1, ..., fpN ]

EXTENDS

SUBUNITS

TYPES & CONSTANTS

INTERFACE

ENVIRONMENTAL ASSUMPTIONS

LOCAL

STATE

OPS & PREDS [ IDlist ]

BEHAVIOUR

Figure 7.4: Template of concrete specification units.

Global types can be used to define the value domains of the interface ports, be-

cause their scope encompasses the context into which the specification unit is em-

bedded.

A particular kind of constant introduced in the TYPES & CONSTANTS section are con-

stants of the predefined type T, which are used in the CSP part as parameters of real-

time operators.

As indicated, the context into which the specification unit Sender of our running ex-

ample is embedded instantiates the formal parameters. We are, however, able to ex-

press constraints on the freedom of the context to perform these instantiations. This is

achieved in the TYPES & CONSTANTS section. First, the identifiers MSG and ACK are

declared as given sets which constrains the context to instantiate these identifiers by

set expressions. Moreover, the identifier MaxDelay is declared as a time value. Finally,

ACK is required to consist of exactly two elements, which is vital for the chosen design.

INTERFACE:The interface of a specification unit consists of the communication channels,

called ports, via which the communication and synchronisation with the environment

is achieved. The declaration

58 Chapter 7. Specification Units

port chan domain S

associates the Z expression Swith the port chan, which is a communication channel in

CSP terms. The Z expression S, evaluated in the context of the corresponding Z part,

denotes the set of data values that can be communicated with events on that channel.

The predefined Z type SYNC is used for channels that serve mere synchronisation

without data transmission purposes.

The scope of the declared ports is the ENVIRONMENTAL ASSUMPTIONS and the BE-

HAVIOUR section of the current unit.

The declarations in the INTERFACE section of the specification unit Sender are self-

explanatory.

LOCAL:This section is used to introduce internal channels, which are not part of the external

interface but used only for internal communication and synchronisation purposes. The

declaration

channel chan domain S

associates the Z expression Swith the channel chan, where Sdenotes the set of data

values that can be communicated with events on that channel. Internal channels are

implicitly hidden from the environment of the process definition given in the BEHAV-

IOUR section.

The scope of the declared channels is the BEHAVIOUR section of the current unit.

The specification unit Sender does not have a LOCAL section, because there is no need

for an internal communication and synchronisation. In fact, a LOCAL section is needed

only for compound specification units that aggregate other ones and that need to con-

trol the interaction between the aggregated units; for more details see the next chapter.

ENVIRONMENTAL ASSUMPTIONS:This section serves to document the assumptions that

underlie the implementation of a specification unit with respect to the behaviour of

its environment at the interface. If the environment violates these assumptions, an

implementation of the specification unit is free to behave arbitrarily.

Environmental assumptions are formalised with the help of an extension of the predi-

cate language of timed CSP, defined in Section 9.2.4. The environmental assumptions

of a specification unit are defined by the dedicated predicate EA in the ENVIRONMEN-

TAL ASSUMPTIONS section. It is the task of this predicate to characterise a set of legal

interactions at the interface, which are formalised in RT-Z as timed failures (s,ℵ).

The ENVIRONMENTAL ASSUMPTIONS section of the example unit defines the predi-

cate EA, which induces a relation between timed traces sand timed refusals ℵ. In-

formally, the channel MsgSend is always required to accept any package consisting of

an arbitrary message and acknowledgement bit. This prevents the sender from being

blocked. The assumption is formulated in terms of the specification macro open, which

expresses that the environment must accept a communication on the given channel

MsgSend at the given time instant t.

STATE:The Z notation is used to define the space of valid data states and the subset in

which the implementations of a specification unit are allowed to start. This is achieved

7.1. Concrete Specification Units 59

by means of the dedicated schemas State and Init. If no Init schema is defined, the initial

subset is fixed to be equal to the whole data state space.4In addition to these dedicated

schemas, the STATE section can define further auxiliary schemas whose purpose is to

structure the definition. In any case, the STATE section can be reduced to the State and

Init schemas by expanding references to auxiliary schemas with their definition.

The context of this section is constituted by the TYPES & CONSTANTS section.

The data state of the example unit consists of the message and acknowledgement bit

to be currently transmitted to the receiver; the inversion of the bit is expected from the

receiver component as the acknowledgement for the reception of the current message.

This data state is very simple and hence does not allow us to make use of the features of

the Z notation to define invariant relationships between state components. Moreover,

the subset of initial data states is not restricted.5

OPS & PREDS:Transitions and conditions on the data state are specified by operation sche-

mas. All operation schemas are based on the dedicated schema State.

The OPS & PREDS section is parametrised by a list of identifiers of operations to be con-

trolled and predicates to be evaluated by the CSP part. This list distinguishes schemas

defining operations and predicates from auxiliary schemas.

For each operation schema Op, specifying an operation or predicate, the schema

NotOp == ¬preOp ∧ΞState

is supposed to be defined implicitly. It defines the predicate that is the negation of the

precondition of the operation schema Op.

In addition to the operations defined explicitly, each specification unit defines several

derived operations implicitly. First, it is a frequent task when defining the dynamic be-

haviour in the CSP part to access the current data state in order to communicate parts of

it to the environment. To this end, each specification unit defines the operation Lookup

implicitly, which binds each data state component to an equally named output param-

eter. The derivation of this operation schema from the State schema of a specification

unit is straightforward. The operation Lookup can be used to access the components

of the current data state via the corresponding output parameters. Second, it is also a

frequent task when defining the dynamic behaviour to update a particular component

of the data state with a value received from the environment. To this end, each speci-

fication unit defines the operation Update comp for each component comp of the data

state, which updates this component with the value of the equally named input par-

ameter comp?. The derivation of these operation schemas from the schema State is also

straightforward. The identifiers of all operations defined implicitly are not included

within the identifier list.

Returning to the unit Sender, there are two operations CorrectAck and IncorrectAck that

are defined explicitly and two operations Lookup and Update curr that are defined im-

plicitly (the third implicit operation Update ack is not needed in the following and

4Init == State

5We will see later that the initial data state of the sender can be constrained only in conjunction with the initial

data state of the receiver, with which we can deal when having introduced aggregation in the next chapter.

60 Chapter 7. Specification Units

hence omitted). The operations CorrectAck and IncorrectAck define the reaction to re-

ceiving a correct and incorrect acknowledgement from the receiver component, re-

spectively. The operation schemas Lookup and Update curr, which are in fact not visible,

demonstrate the straightforward derivation of these two kinds of operation schemas

from the state schema.

BEHAVIOUR:The base language for specifying the dynamic behaviour of specification units

is the process term language of timed CSP, which we have extended in order to accom-

modate the needs in the context of the integrated formalism. This extended process

term language is discussed in detail in Section 9.2.4.

The dynamic behaviour is defined by a process with the dedicated identifier Behaviour.

To structure its definition, the BEHAVIOUR section can define further processes, to

which the process Behaviour—directly or indirectly—refers. Process definitions in

timed CSP

ID b=ProcTerm

have two purposes:

•to structure large process expressions and

•to express simple and mutual recursion.

We add the ability to parametrise process definitions by a list of identifiers

ID(fp1, . . . , fpN)b=ProcTerm

to the syntax of timed CSP. ProcTerm in the above definition can contain occurrences

of fp1, . . . , fpN at arbitrary places. Each reference to such a parametrised process de-

finition must be supplied with a list of actual parameters of the same length. Formal

and actual parameters are identified according to their positions in both lists.

For parametrised process definitions to be well-defined, however, we must exclude

the possibility that they are involved in recursive definitions. That is, for each param-

etrised process definition

P(fp1, . . . , fpN)b=ProcTerm

ProcTerm must not contain—directly or indirectly—references to P. Having excluded

recursive definitions of parametrised processes, the meaning of referring to a param-

etrised process definition is given by a simple textual substitution: the reference is

substituted by the right hand side of the process definition where all free occurrences

of formal parameters are simultaneously substituted by the corresponding actual par-

ameters, supplied in the reference.

As already indicated, the dynamic behaviour consists of two aspects. The external

stimulus–response behaviour at the external interface defines the response to external

stimuli in terms of emitting responses into the environment. The internal control be-

haviour, on the other hand, defines the control of the application of internal operations

that have to take place in reaction to external interactions.

Let us return to the example. The BEHAVIOUR section of the unit Sender defines four

processes, which are mutually recursive. The process Receive first awaits a new mes-

sage on the channel In. Having received such a message it must update its current data

7.2. Abstract Specification Units 61

state. This update is defined by the notation Update curr(rec)which is an abbreviation

of the event Update currX!h| curr? == rec |i. According to the discussion in the OPS &

PREDS section, the operation schema Update curr is defined implicitly, and it models

the update of the state component curr. Thus, the above execution event defines the

update of this state component with the received value rec.

The task of the process Send is to deliver the package consisting of the current message

and acknowledgement bit to the channel MsgSend. Therefore, the current data state

must be accessed, before its components can be delivered. The notation

σ(MsgSend!(curr,ack)→. . .)

combines these two steps; it is a shorthand for the process

LookupX?st : [ curr! : MSG;ack! : ACK ]→MsgSend!(st.curr!,st.ack!) →. . .

which accesses the current data state in the first step and uses the variable st, to which

the components of the current data states are bound, in the second step.

The purpose of the process Acknowledge is to await and process the acknowledgement

of the current message, which must be re-sent if an incorrect acknowledgement has

been received or if no acknowledgement has been received for MaxDelay time units.

After an acknowledgement has been received on the channel AckRcv, the subsequent

behaviour of the unit Sender depends on the relationship between the received acknow-

ledgement bit and the current data state. This dependence on the current data state is

expressed by the external choice whose two branches are guarded by the execution

events of the operations IncorrectAck and CorrectAck. As stipulated in the previous

chapter, the execution event of an operation is accepted by the “Z process” if, and

only if, the precondition of the operation schema is satisfied with respect to the cur-

rent data state and the supplied input parameters. Note further that the preconditions

of the operation schemas CorrectAck and IncorrectAck partition the data state. Thus,

for each combination of the current data state and received acknowledgement bit, the

precondition of exactly one operation is satisfied, which resolves the external choice

accordingly.

7.2 Abstract Specification Units

A template of abstract specification units is given in Figure 7.5. We have already presented an

example of abstract specification units in Section 6.1, namely the requirements specification

of a reliable communication medium.

We concentrate only on the differences between the structure of abstract and concrete specifi-

cation units. Since it is not reasonable in the abstract model to stipulate the internal structure

of an artifact, there is neither a SUBUNITS nor a LOCAL section. The purpose of the TYPES &

CONSTANTS, the INTERFACE and the ENVIRONMENTAL ASSUMPTIONS sections is identical

to that of the corresponding sections of concrete specification units.

I/O RELATIONS:This section serves to introduce Z schemas expressing relationships that

must hold between data values communicated with external events. They are referred

62 Chapter 7. Specification Units

SPEC.UNIT Name [fp1, ..., fpN ]

EXTENDS

TYPES & CONSTANTS

INTERFACE

ENVIRONMENTAL ASSUMPTIONS

I/O RELATIONS

STATE PROPERTIES

BEHAVIOURAL PROPERTIES

Figure 7.5: Template of abstract specification units.

to in the BEHAVIOURAL PROPERTIES section. Within such a schema reference, data

values communicated with particular events are bound to the components of the ref-

erenced schema.

STATE PROPERTIES:If present, this section defines the dedicated schema State, which,

like in the concrete model, defines the space of valid data states. At first glance, this

seems to contradict the real purpose of abstract specification units. In the context of

the system development phases, however, in which one is often faced with a physic-

ally fixed state, the model of this system state should be taken into account already in

the abstract requirements specification. Based on this state model one is interested to

express further properties of the state that must hold in particular situations depend-

ing on the external interaction. Additional Z schemas specified in the current section

define time-variant state properties, i.e., properties that the evolution of the system

state must meet in the context of particular external interactions. They are referred to

in the BEHAVIOURAL PROPERTIES section, too.

BEHAVIOURAL PROPERTIES:This section is the core of abstract specification units, spe-

cifying all relevant types of system properties discussed in Section 6.2 by referring to

the definitions of the previous two sections. Its purpose is to specify the properties

of the dynamic behaviour of the artifact under consideration, including aspects of the

temporal ordering of external interactions, real-time constraints and properties of the

data values communicated with these external interactions. The language for specify-

ing the dynamic behaviour in abstract specification units is the predicate language of

7.2. Abstract Specification Units 63

the timed failures/states model, which we introduce in Section 9.2.5. The dedicated

predicate Behaviour defined in the BEHAVIOURAL PROPERTIES section induces a re-

lation between timed failures (s,ℵ)and timed states tst, corresponding to legal timed

observations at the interface of the artifact at hand.

64 Chapter 7. Specification Units

Chapter 8

Structuring Mechanisms

A basic specification unit as discussed in Chapter 7 is suited to specify a single system com-

ponent with a relatively low complexity from scratch. Basic specification units have thus

several shortcomings. First, they are not appropriate to specify large and complex systems;

to be able to cope with such systems, we must provide adequate structuring concepts in or-

der to stepwise reduce a complex problem to simpler problems and to compose the resulting

component specifications to obtain a system specification. Second, a single specification unit

is not able to model parallel activities on a common data state space. To model such parallel

threads of control as well, we need a means for composing individual sequential threads of

control, encapsulated within different specification units. Third, it would be useful to reuse

the definition of existing specification units within different system specifications. There-

fore, a mechanism is needed that allows us to build a system specification on a library of

RT-Z specification units.

To overcome all three shortcomings of single specification units as just discussed, we basic-

ally provide two structuring constructs which compose specification units to more complex

ones. Aggregation copes with the first two limitations and extension with the last.

Aggregation models physical or conceptual ‘part-of’ relationships: an aggregating unit con-

tains several smaller or simpler units, called aggregated units. The data state and the dy-

namic behaviour of an aggregating unit is the (individually defined) composition of the data

states and dynamic behaviour patterns of its aggregated units, respectively. Any specifica-

tion unit within a hierarchy that is induced by the aggregation relationship encapsulates the

structure and behaviour of an entire system, of a subsystem or of a basic system component,

depending on its specific position within the hierarchy. The process term language of timed

CSP is used by an aggregating specification unit to fix the configuration of its aggregated

units including their interaction via particular communication channels. Since each aggre-

gated unit encapsulates its separate data state, composing two aggregated units in parallel

allows us to model parallel threads of control that work on disjoint parts of the overall, com-

posed data state. This issue of parallelism is dealt with in the next section.

Extension, on the other hand, is a concept that supports reuse. It is orthogonal to aggregation:

it allows any specification unit within an aggregation hierarchy to be defined as an extension

of previously defined specification units, for instance, constituents of a specification library.

66 Chapter 8. Structuring Mechanisms

Extension can be regarded as an import mechanism for general-purpose definitions, but also

as a means for incremental specification.

In Chapter 9, we define the formal meaning of single specification units. In this chapter, we

informally explain the relationships between aggregating and aggregated specification units

on the one hand and between extending and extended specification units on the other hand.

To formally define the meaning of aggregation and extension, we develop transformation

rules that reduce a hierarchy, constituted by the aggregation or extension relationship, to a

single specification unit; and we identify the meaning of a hierarchy of specification units

with the meaning of the single specification unit resulting from the process of reduction.

Both transformations—concerning aggregation and extension—do not mean that we gener-

ally drop the idea of decomposing a specification; they have only the purpose to define the

semantics. This “transformational approach” to defining the semantics of structured speci-

fications is not uncommon: the semantics of Object-Z [Smith, 2000], e.g., is defined in terms

of transformation rules from Object-Z to (plain) Z syntax.

This process of reducing a hierarchy of specification units into a single one is a recursive

process from the leaves of the hierarchy towards the root. Its elementary step is to reduce

an aggregating (extending) and all its aggregated (extended) specification units to a single

specification unit. This elementary step is part of the subject of the subsequent discussion.

8.1 Aggregation

Aggregation, as just indicated, is a structuring mechanism that defines the internal—physic-

al or conceptual—structure of the artifact under consideration. It is therefore applicable only

in the concrete model, i.e., to concrete specification units. The only mechanism to structure

abstract specification units is extension.

8.1.1 Example

To illustrate the aggregation mechanism and the consequences of applying it, we consider a

simple example: fragments of the requirements specification of a ticket sale system, which is

shown in Figure 8.1. The sale of tickets might concern, e.g., a particular performance with a

restricted capacity. We suppose that the ticket sale is distributed to two offices, both specified

by the specification unit TicketOffice. The overall sale system, TicketSale, is the aggregation of

the two offices.

The data state of each office is given by the number of tickets sold so far, where each office

has a fixed maximum allocation of cards (Alloc) that must not be exceeded. The behaviour

of both offices is cyclic, where each cycle concerns a single card request: a request to issue a

particular number of cards (ticket req) is responded successfully (ticket out) if the respective

office is allowed to issue the requested number; otherwise the request fails (failure). The

overall ticket sale system is the composition of the two offices. Its data state is the union of

the data states of the offices, represented by the state components officeA and officeB, and its

dynamic behaviour is the interleaving of the behaviour patterns of the offices.

There are two main aspects related to aggregation we would like to indicate before going

into further details. The first aspect is the concurrency inherent in the ticket sale system: the

8.1. Aggregation 67

SPEC.UNIT TicketOf£ce

INTERFACE

port ticket req,ticket out domain N;

port failure domain SYNC

TYPES & CONSTANTS

Alloc :N

STATE

State

sold :N

sold ≤Alloc

Init

State

sold = 0

OPS & PREDS [ Sell ]

Sell

∆State

num? : N

sold +num?≤Alloc

sold0=sold +num?

BEHAVIOUR

Behaviour b=IDLE

IDLE b=ticket req?n:N→

(SellX?par :h| num? == n|i → ticket out!n→IDLE

¤NotSellX?par :h| num? == n|i → failure →IDLE)

SPEC.UNIT TicketSale

INTERFACE

...

SUBUNITS

subunit of£ceA spec.unit TicketOf£ce

rename ticket req to ticket reqA,ticket out to ticket outA,

failure to failureA;

subunit of£ceB spec.unit TicketOf£ce

rename ticket req to ticket reqB,ticket out to ticket outB,

failure to failureB;

TYPES & CONSTANTS

Capacity :N

of£ceA.Alloc ≤Capacity ∧of£ceB.Alloc ≤Capacity

STATE

SubunitStates

of£ceA :TicketOf£ce.State

of£ceB :TicketOf£ce.State

GlobalInv

SubunitStates

of£ceA.sold +of£ceB.sold ≤Capacity

BEHAVIOUR

Behaviour b=

of£ceA.Behaviour

|||

of£ceB.Behaviour

Figure 8.1: Example: ticket sale system.

68 Chapter 8. Structuring Mechanisms

aggregated offices are composed by the interleaving operator (|||) and thus they evolve (in

principle) independently of each other. In particular, this means that the operations defined

by the two offices may be applied concurrently. The second aspect is the concept of so-called

global invariants. In addition to the local invariants of the data states of the offices, the schema

GlobalInv of the ticket sale system specifies a constraint on the relationship between the state

components of the two offices: both offices together must not sell more cards than the overall

capacity of the performance. This global invariant has some important consequences with

respect to the interaction of the aggregated offices.

Consider the data state of the overall system in which the two offices together have almost

exhausted the capacity. If the offices receive requests simultaneously that together but not

alone will exceed the capacity, then the considered RT-Z specification does not prevent the

parallel execution of the corresponding operations. The interpretation prescribed by the

RT-Z semantics is that the system will diverge in this case, i.e., it will behave in an arbit-

rary way. This means that an implementation of the ticket sale specification is required

to respect the overall capacity unless there is a simultaneous request to the two offices

whose cumulative amount exceeds the capacity. The requirements specification simply ab-

stracts from the consideration of this specific situation. It is the task of a more concrete

design specification to devise mechanisms preventing the parallel execution of two requests

under such circumstances. For instance, the offices might be connected by a channel via

which they could coordinate the issue of cards; or the allocations might be fixed such that

officeA.Alloc +officeB.Alloc ≤Capacity holds.

8.1.2 Global Invariants

Global invariants arise in conjunction with aggregation.1A global invariant is a constraint

that an aggregating unit imposes on the relationship between state components of several

aggregated units, see the example in the previous section. To understand the implications

of global invariants, we first elaborate on the mentioned process of reducing an aggregation

hierarchy of specification units, which is used to define the meaning of aggregation.

Global invariants are a concept that have a counterpart in the B language [Abrial, 1996], in

which they are called glue invariants,2and in the formal specification language ASTRAL

[Coen-Porisini et al., 1997].

Let us first consider the structure of the data state of a compound RT-Z specification. In

the context of an RT-Z specification that is composed of an aggregation hierarchy of speci-

1We will see later that global invariants also arise in conjunction with extension.

2In brief, B specifications are composed of machines. Machines can include other machines. Each B machine

encapsulates a data state, which is specified in a way similar to Z. Glue invariants are state invariants that

refer to the state variables of several of the included machines.

Although the two concepts are very similar, the consequences they have in B and RT-Z are absolutely different.

The B system model is sequential: it does not take into account the concurrent execution of operations. Thus,

the interaction between operations of different machines working on different subspaces of the overall data

state but all affecting the satisfaction of the glue invariant, need not be considered in B.

As we will see later in this thesis, the ability of RT-Z to relate the data states of different units through global

invariants while allowing operations working on the data states of different units to be executed concurrently

(under particular conditions) is a major achievement of the model underlying RT-Z, but at the same time a

major source of complexity.

8.1. Aggregation 69

fication units, the overall data state of the specified system is hierarchically partitioned into

subspaces according to the hierarchical decomposition of the RT-Z specification into specifi-

cation units, where each specification unit defines its associated data state.

As mentioned in the beginning of this chapter, the meaning of aggregation is defined in

terms of transformation rules, reducing a hierarchy of specification units to a single one.

These rules are the subject of Section 8.1.4 and Section 8.1.5. During this reduction process,

each operation, defined in a particular specification unit of the aggregation hierarchy, is lif-

ted (promoted) from the data state of its associated specification unit to the overall data state

of the specified system. That is, each operation, which is originally—in the context of its as-

sociated specification unit—interpreted with respect to the corresponding part of the overall

data state, is lifted to a system operation working on the overall data state of the system.

This lifting is defined such that the state transitions characterised by the resulting system

operation satisfy the following conditions.

•The projection of the state transitions to the subspace of the associated specification

unit coincides with the interpretation of the operation in the context of the associated

specification unit.

•The projection of the state transitions to the remaining subspaces of the overall data

state yields no change.

At this level of consideration, the concurrent application of system operations originating

from different specification units entails no problem: since the “real” state changes they

cause concern disjoint parts of the overall data state, they do not interfere each other and

their state transitions can be combined in a consistent way. Things, however, become more

complicated when global invariants are taken into consideration: a global invariant relates

state components of different specification units, and consequently the independence of sys-

tem operations originating from different specification units is no longer guaranteed. In

other words, global invariants have the consequence that the application of a system opera-

tion, originally defined on the data state of its associated specification unit, may now depend

on the overall data state.

Let us discuss global invariants in more detail with the help of the example depicted in

Figure 8.2, in which we consider the aggregation of two components Comp1and Comp2.

Comp1consists of a state variable xand an operation Op1that increases x, and Comp2consists

of a state variable yand an operation Op2that decreases y. We (alternatively) consider two

global invariants defined in the aggregating unit, which relate the state variables xand y.

The first one requires their equality, and the second one requires that xis less than y.

Consider the first global invariant, the equality of the state components xand yof the aggre-

gated units. It turns out that this overly strong global invariant does not allow the operations

of Comp1and Comp2to be lifted (promoted) in a consistent manner, because both operations

insist on one state component to be changed while the lifting process insists that the other

state component remains unchanged; this is an obvious contradiction to the global invariant.

Thus, the lifted system operations are inconsistent which means that they define no transi-

tion on the overall data state at all. The problem caused by this global invariant is the strong

coupling between the state components of the aggregated units.

70 Chapter 8. Structuring Mechanisms

SPEC.UNIT System

SUBUNITS

subunit c1spec.unit Comp1;

subunit c2spec.unit Comp2

STATE

SubunitStates

c1 : Comp1.State

c2 : Comp2.State

GlobalInv

SubunitStates

c1.x=c2.y

c1.x<c2.y

...

SPEC.UNIT Comp1

STATE

State == [ x:N]

OPERATIONS

Op1 == [ ∆State |x0=x+ 1 ]

SPEC.UNIT Comp2

STATE

State == [ y:N]

OPERATIONS

Op2 == [ ∆State |y0=y−1 ]

alternatively

}

(1)

(2)

Figure 8.2: Example of global invariants.

One rationale behind specification units is “separation of concerns.” Specification units

should satisfy the criterion of cohesion: the elements of a unit should be related as close

as possible, and as few as possible (globally formulated) relationships to elements of other

specification units should exist. In the above example, it is questionable if the decomposi-

tion of the data state space into the units Comp1and Comp2is reasonable due to the strong

equality relationship between xand y. Dispensing with the decomposition into the units

Comp1and Comp2would relieve us of employing global invariants. In the case that the de-

composition into specification units is used in order to fix physical aspects, e.g., distribution,

(strong) global invariants are even more problematic. If, in the example, the specification

units represented distributed system units, the global equality invariant would be infeas-

ible: there is no way to guarantee that distributed system units have always the identical

state of a variable.

Consider now the second global invariant. Since the state components of the specification

units are related via an inequality relationship, their operations, Op1and Op2, are more in-

dependent of each other than in the context of the first global invariant. According to the

semantics of RT-Z defined in Chapter 9, the concurrent application of the two operations to

a particular data state is well-defined if, and only if, the set of final data states that the rela-

tional composition of the operations produces is not empty and independent of their order.

The concurrent application of operations that is not well-defined results in divergence, i.e.,

in an arbitrary behaviour. If Op1and Op2are applied concurrently to a data state satisfying

x=y−2, the first operation terminates in a state satisfying x=y−1, in which the precon-

dition of the other operation is not fulfilled. The set of final data states that can be produced

by their relational composition is hence empty. Thus, the concurrent application of the two

operations to the data state x=y−2results in divergence. The invalidation of the precondi-

8.1. Aggregation 71

tion of one operation by the termination of the other one, both changing disjoint subspaces

of the overall data state, is the consequence of the global invariant: taking the global invari-

ant into account, the preconditions of the lifted system operations do not depend only on

their original part of the data state but also on the remaining part. The preconditions of the

lifted operations Op1and Op2are both x<y−1.

The approach taken in RT-Z is to allow scenarios of concurrent operation applications that

are not well-defined and result in an arbitrary behaviour. It depends on the level of abstrac-

tion whether such nondeterminisms are acceptable. In an abstract requirements specifica-

tion, it is frequently the deliberate intention of the specifier to abstract from the consequences

of such a kind of concurrency in order to allow a design to exhibit an arbitrary behaviour.

A sufficiently concrete design specification, on the other hand, must eliminate such non-

determinisms by defining measures that prevent the concurrent application of operations

that interfere each other.

To conclude, a great amount of information about the potential effects of applying opera-

tions can potentially be distributed to several specification units. This distribution leads to a

relatively strong coupling between specification units when global invariants are involved,

making it harder to understand and review a specification, because the ‘separation of con-

cerns’ principle is more or less compromised, depending on how closely components of

different units are related by the used global invariants. Global invariants can lead to close

relationships between operations of different specification units and can introduce a lot of

implicit properties, which are not (necessarily) immediately discernible. They should hence

be used very carefully. On the other hand, they are a very powerful notation that can be

used to structure complex invariants more clearly. The concept of global invariants is also

supported by Object-Z [Smith, 2000].

A discussion of the interaction between global invariants and the concurrent application of

operations from a more semantical point of view can be found in Chapter 9.

8.1.3 Syntax

The SUBUNITS section of concrete specification units is used to express the aggregation re-

lationship: it declares the system units that aggregate each instance of the specification unit

under consideration. These declarations associate each aggregated system unit with a speci-

fication unit, determining its structure and behaviour.

Any aggregation hierarchy of specification units is induced by the information contained in

the SUBUNITS section. A specification unit (and its corresponding system units) containing

aSUBUNITS section is called aggregating unit, and the specification units (and its corres-

ponding system units) recorded therein are called aggregated units.

The declaration

subunit agg spec.unit Spec

introduces a single system unit agg, whose structure and behaviour is determined by the

specification unit Spec, as a part of each instance of the current specification unit. By declar-

ing

72 Chapter 8. Structuring Mechanisms

subunit agg(IS)spec.unit Spec

a collection of system units is introduced, one for each member of the index set IS. Their

structure and behaviour is determined by Spec. Such an indexed collection models a num-

ber of equally structured and equally behaving system units, each of which identified by a

member of IS, which must be a finite set of index values.

8.1.4 Simple Aggregation

As already indicated in the introduction to this chapter, the meaning of aggregation is

defined in terms of transformation rules that reduce a hierarchy of specification units to

a single one: the meaning of an aggregation hierarchy is defined to be the meaning of the

single specification unit resulting from the reduction. This reduction is a recursive process

from the leaves towards the root of a hierarchy. Its elementary step is to reduce an aggre-

gating and all its aggregated specification units. We first explain this elementary step for a

specification unit whose SUBUNITS section uses only simple aggregation. Indexed aggrega-

tion is dealt with afterwards.

This elementary step is described separately for each section of concrete specification units.

We suppose in the following that the concrete specification unit CSU contains the SUBUNITS

section

subunit agg1spec.unit Spec1;

. . .

subunit aggNspec.unit SpecN.

The reduction process described in the following takes the aggregated units agg1, . . . , aggN

and the aggregating unit CSU as input and produces a single specification unit, whose mean-

ing is the meaning of the whole aggregation.

To understand the following transformation rules, we must have in mind that the aggregat-

ing unit CSU can aggregate several instances of a single specification unit, i.e.,

Speci=Specjfor i6=j;i,j∈ {1, . . . , N}.

Constants and types declared in a specification unit need not be uniquely fixed. That is, there

can be different interpretations of a constant or type. Concerning the constants and types

declared in Speci(= Specj), both aggregated units aggiand aggjshould have the freedom to

choose different interpretations. We must hence ensure that there are two instances of each

constant and type with distinct identifiers. For this reason, the reduction process prefixes

each constant and type declared in Speciby the identifier of the respective aggregated system

unit, e.g.,

aggi.cvs. aggj.c.

Because of the transformation of constant and type identifiers, all Z expressions within an

aggregated unit, which could refer to those identifiers, must be transformed syntactically.

This syntactic transformation is denoted by the syntactic meta function lift simple Z.

The expressions of the CSP part must undergo a similar transformation. As will be discussed

later, the reduction process prefixes the identifiers of internal channels of aggregated units

8.1. Aggregation 73

by the identifier of the respective aggregated unit. Thus, each CSP expression referring to an

internal channel must be transformed syntactically. This syntactic transformation is denoted

by the syntactic meta function lift simple CSP.

TYPES & CONSTANTS.A constant, declared and constrained by an axiomatic definition,

needs not be uniquely fixed, because several values might satisfy the constraints as-

sociated with that constant. Different instances of a single specification unit can hence

choose distinct values for that constant. Accordingly, for each axiomatic definition in

the aggregated unit aggi(Speci)

c:T

Pred

the specification unit resulting from the reduction process will contain the axiomatic

definition

aggi.c:lift simple Z(aggi,T)

lift simple Z(aggi,Pred)

where lift simple Z(aggi,Pred)is obtained from Pred by substituting each occur-

rence of a constant or type, say a, by aggi.a.

In Z, the declaration of a given set does not constrain the set that denotes the intro-

duced identifier—not even the structure of the objects that are members of this set is

constrained. Different instances of a single specification unit can hence choose distinct

interpretations for such a given set. Accordingly, for each given set declaration in the

aggregated unit aggi(Speci)

[S]

the specification unit resulting from the reduction process will contain the declaration

[aggi.S].

Free type definitions

T1::= c11 |. . . |c1N1|i11hhS11ii | . . . |i1M1hhS1M1ii

&. . . &

are expanded during the reduction process into axiomatic definitions and declarations

of given sets corresponding to the semantic transformation rules defined in the Z

Standard [ISO, 2002, Chapter 14], see also [Woodcock and Davies, 1996, p. 139].

74 Chapter 8. Structuring Mechanisms

c11, . . . , c1N1:T1

. . .

cK1, . . . , cKNK:TK

i11 :S11 T1;. . . ;i1M1:S1M1T1

. . .

iK1:SK1TK;. . . ;iKMK:SKMKTK

h{c11}, . . . , {c1N1},rani11, . . . , rani1M1ipartition T1

. . .

h{cK1}, . . . , {cKNK},raniK1, . . . , raniKMKipartition TK

∀S1:PT1;. . . ;SK:PTK|

{c11, . . . , c1N1} ∪ i11(|S11[S1, . . . , SK/T1, . . . , TK]|)∪. . . ∪

i1M1(|S1M1[S1, . . . , SK/T1, . . . , TK]|)⊆S1

∧. . . ∧

{cK1, . . . , cKNK} ∪ iK1(|SK1[S1, . . . , SK/T1, . . . , TK]|)∪. . . ∪

iKMK(|SKMK[S1, . . . , SK/T1, . . . , TK]|)⊆SK•

S1=T1∧. . . ∧SK=TK

Thus, when an aggregated specification unit contains a free type definition, it is trans-

formed into the corresponding given set declaration and axiomatic definitions, which

are in turn subject to the corresponding transformation rules already explained.

Analogously, each definition by syntactic equivalence

S== Expr

is expanded during the reduction process into an axiomatic definition corresponding

to the syntactic transformation rule defined in the Z Standard [ISO, 2002, Chapter 12].

S:{Expr}

To summarise, the specification unit resulting from the reduction process contains all

types and constants of the aggregating unit CSU and all types and constants of the

aggregated units Spec1, . . . , SpecN, transformed as just described.

STATE.We have already outlined the structure of the data state in connection with aggre-

gation: the data state space of an aggregating unit encompasses the data state spaces

of the aggregated units, including their local invariants. An aggregating unit does not

define its individual data state space. That is, a unit containing a SUBUNITS section

must not define a State schema, because it is automatically defined as a result of the

considered reduction process.

State

SubunitStates

GlobalInv

The data state spaces of the aggregated units are introduced by SubunitStates, which is

itself a schema derived by the reduction process as follows.

8.1. Aggregation 75

SubunitStates

agg1:lift simple Z(agg1,Spec1.State)

. . .

aggN:lift simple Z(aggN,SpecN.State)

For each aggregated system unit recorded in the SUBUNITS section, an equally named

state variable is declared whose type is the schema type of the state schema of the

associated specification unit.3Note that this schema can be immediately derived from

the SUBUNITS section of the aggregating unit.

Global invariants, constraining the relationships between state components of different

aggregated units, are defined in the dedicated schema GlobalInv in the STATE section of

an aggregating unit. The concept of global invariants has been treated in Section 8.1.2.

The schema

Init

SubunitInit

GlobalInit

defines the initialisation of the overall data state space of the aggregation. The initial-

isation of the subspaces of the aggregated system units is defined by the schema

SubunitInit

State

agg1∈lift simple Z(agg1,Spec1.Init)

. . .

aggN∈lift simple Z(aggN,SpecN.Init)

which is derived as another result of the reduction process. Each aggregated system

unit must be in a state as defined by the Init schema of the corresponding aggregated

specification unit.

Additional constraints on the initialisation of the overall data state space can be stipu-

lated in the dedicated schema GlobalInit. This concerns constraints on the relationship

between state components of different aggregated units, which must be met in addi-

tion to the local initialisation constraints.

OPS & PREDS.As already outlined with regard to a whole aggregation hierarchy, the op-

erations (and predicates) of the aggregated units agg1, . . . , aggNare originally defined

on the data state space of the corresponding specification unit, and they are lifted to

the overall data state space during the reduction process. This lifting is achieved by

applying the Z concept of promotion.

As a further part of the definition of the reduction process, the promotion schema Φaggi

is derived for each aggregated system unit aggirecorded in the SUBUNITS section as

follows.

3We use schema variables denoting states of aggregated system units rather than simply importing the corres-

ponding state schemas, because several aggregated system units may be associated with a single specification

unit.

76 Chapter 8. Structuring Mechanisms

aggiState == lift simple Z(aggi,Speci.State)

Φaggi

∆State

∆aggiState

θaggiState =aggi

agg0

i=θaggiState0

agg0

1=agg1∧. . . ∧agg0

i−1=aggi−1

agg0

i+1 =aggi+1 ∧. . . ∧agg0

N=aggN

This promotion schema serves to lift the operations defined on the data state space of

the aggregated system unit aggi(∆aggiState) to the overall data state space (∆State). It

stipulates that the subspaces of the other aggregated system units are left unchanged,

while the transformation within the subspace of the aggregated system unit aggiis in

accordance with the operation to be promoted.

Based on this preliminary definition, the single specification unit resulting from the

reduction process contains the promoted operation schema

aggi.Op == (Φaggi∧lift simple Z(aggi,Speci.Op)) \∆aggiState

for each operation schema Op contained in the identifier list of the aggregated specifi-

cation unit Speci. The operation schema Speci.Op can contain references to other opera-

tion schemas of the considered unit, which are themselves lifted during the reduction

process. Accordingly, the meta function lift simple Z substitutes each reference to

an operation schema ref by the new identifier aggi.ref, which the referenced operation

schema will have after the lifting.

This syntactical transformation has essential consequences. Using this approach to

deal with references to operation schemas, each operation schema is lifted in accord-

ance with the lifting of the context into which it is embedded.

An alternative approach would be to expand references to operation schemas imme-

diately. However, this would not allow us to refer to properties of operation schemas

that they have in the context (of the overall data state) into which they are embedded

during the reduction process, as will become apparent by revisiting the ticket selling

example of p. 67. In the aggregated unit TicketOffice, the process term Behaviour refers

to the operation schema NotSell, which is defined implicitly as follows.

NotSell == ¬preSell ∧ΞState

Following the alternative approach (of immediate reference expansion), the reference

¬preSell would be expanded immediately in the local context of the unit TicketOffice

and its data state: NotSell would have as its precondition the negation of the precon-

dition of Sell, computed within the local context of TicketOffice, namely that the local

capacity Alloc must not be exceeded. After the reduction process, however, both lifted

operation schemas would not have the intended properties in the global context. For

example, the property that the preconditions of the two operations partition the data

state space. This property is not satisfied because of the additional global invariant,

8.1. Aggregation 77

which affects the precondition of the lifted operation TicketOffice.Sell: an additional

conjunct of the precondition is that the total capacity must not be exceeded. Since the

reference ¬preSell of the definition of NotSell is already expanded in the local context,

the precondition of TicketOffice.NotSell does not incorporate this case of the invalida-

tion of the additional global invariant. Thus, those data states in which the application

of Sell would exceed the total but not the local capacity would not be covered by the

preconditions of the lifted operations and hence the process Behaviour would deadlock

in these data states.

Following the first approach (of delayed reference expansion), on the other hand, the

reference ¬preSell is expanded only in the global context, so the lifted operation

schema NotSell does take the invalidation of the global invariant into account as inten-

ded. Note that all identifiers of local entities of aggregated specification units (such as

operations and predicates) are prefixed during the reduction process by the respective

unit identifier. This is elaborated in the discussion of the INTERFACE and the LOCAL

section.

Note also that we lift only operation schemas contained in the identifier list of the

OPS & PREDS section. Auxiliary schemas need not be lifted because they are elimin-

ated by means of normalisation.

Since we treat predicates as a specific kind of operations, there is no need to distinguish

between operation schemas defining operations and those defining predicates.

INTERFACE.The interface of the specification unit resulting from the reduction process is

identical with the interface of the aggregating specification unit CSU. Declarations

of the INTERFACE sections of the aggregated specification units must be contained

either in the INTERFACE or the LOCAL section of the aggregating specification unit.

This depends on whether or not these interface elements are hidden in the behaviour

definition of the aggregating specification unit.

The identifiers of external ports (in contrast to the identifiers of internal channels) of

the aggregated units are not prefixed by the respective unit identifier. Therefore, by de-

fault, equally named external ports of different aggregated units are identified during

the reduction process. When this is not intended, they can be appropriately renamed

by using the renaming operator defined for specification units, see Section 8.3. We

have already used this renaming operator in the example on p. 67.

LOCAL.All internal channels declared by the aggregating unit CSU are part of the LOCAL

section of the specification unit resulting from the reduction process. Moreover, for

each declaration

channel chan domain Set

in the LOCAL section of the aggregated unit Speci, the declaration

channel aggi.chan domain Set

is part of the LOCAL section of the resulting unit. That is, the identifiers of internal

channels of the aggregated units are prefixed by the identifier of the respective aggre-

gated system unit. This allows us to distinguish equally named internal channels of

different aggregated system units (e.g., operation-related events).

78 Chapter 8. Structuring Mechanisms

ENVIRONMENTAL ASSUMPTIONS.The environmental assumption of the specification unit

resulting from the reduction process is the environmental assumption of the aggregat-

ing specification unit CSU. The environmental assumptions of the aggregated units

must be ensured by the aggregation context, which is a verification condition that

should be checked for each aggregation.

BEHAVIOUR.Finally, we discuss how the definition of the behaviour patterns of the aggre-

gating and of the aggregated specification units are composed to obtain the behaviour

definition of the specification unit resulting from the reduction process. The behaviour

definition of the aggregating unit CSU (process term Behaviour) refers to the behaviour

of the aggregated unit aggiby means of aggi.Behaviour. This reference denotes the ap-

plication of the syntactic meta function lift simple CSP to the behaviour definition

of the specification unit Speci.

aggi.Behaviour b=lift simple CSP(aggi,Speci.Behaviour)

This syntactic transformation concerns the renaming of internal channels, discussed

with respect to the LOCAL section.

The process Behaviour of the aggregating unit CSU can compose the behaviour patterns

of the aggregated units by arbitrary process operators. The combination of units by the

parallel operators enables the separation of concurrent behaviour patterns working on

disjoint parts of the overall data state within different system units. Hence, while a

basic specification unit can define only sequential state-dependent behaviour patterns,

aggregation makes it possible to consider concurrency (and distribution). Thereby, the

process term Behaviour of an aggregating unit characterises the (physical or conceptual)

configuration of the aggregated units to constitute the whole aggregation.

8.1.5 Indexed Aggregation

In this section, we describe the reduction process for a specification unit whose SUBUNITS

section contains indexed aggregation. We describe only the differences to the reduction pro-

cess for simple aggregation. When a specification unit contains simple and indexed aggre-

gation, the described transformations are combined in the obvious way.

We assume that the considered specification unit, say CSU, contains (among others) the

declaration

subunit agg(IS)spec.unit Spec

in its SUBUNITS section where IS is a finite set of index values. Again, the reduction process

is described separately for each section of concrete specification units.

As we will shortly argue in the description of the transformation rules, each constant c:T

declared in the aggregated unit Spec must be lifted to the function agg.c:IS →T, because we

have to take into account that each instance of the indexed aggregation chooses a different

value for that constant. Consequently, each expression of the Z part must be transformed

syntactically: each occurrence of a constant cintroduced by the aggregated unit must be

substituted by the function application (agg.c index), where index is a dedicated identifier

that is assumed not to occur in the aggregated unit; it identifies a particular instance of the

8.1. Aggregation 79

indexed aggregation. The syntactical transformation of Z expressions is represented by the

syntactic meta function lift indexed Z.

A similar syntactical transformation must be applied to the expressions of the CSP part of

the aggregated unit. Since the interaction of different instances of the indexed aggregation

via external and internal channels must be distinguished, the values transmitted via these

channels by different instances must be distinguishable. Basically, this is achieved by ex-

tending each communicated value with the identifier of the involved instance. The corres-

ponding syntactic transformation working on process terms is represented by the syntactic

meta function lift indexed CSP.

TYPES & CONSTANTS.A constant, declared and constrained by an axiomatic definition,

needs not be uniquely fixed. When building an indexed collection of a specification

unit, we have to take into account that each instance of such a collection can choose

its own value for such a constant. This means that the reduction process must lift each

constant to a function mapping each instance to a particular value.

Accordingly, for each axiomatic definition in the aggregated specification unit Spec

c:T

Pred

the specification unit resulting from the reduction process will contain the definition

agg.c:IS →lift indexed Z(agg,T)

∀index :IS •lift indexed Z(agg,Pred)

where lift indexed Z(agg,Pred)is obtained from Pred by substituting each occur-

rence of a constant, say a, by the function application (agg.a index).

Analogously to the procedure described in the context of simple aggregation, the re-

duction process expands each definition by syntactic equivalence

S== Expr

into the axiomatic definition

S:{Expr}

which in turn is subject to the transformation rule just described.

Specification units instantiated by means of indexed aggregation must not contain type

declarations (given sets or free types). The technical reason for this decision is that the

Z notation does not allow us to lift type declarations in accordance with our approach

to lifting constants. However, also from a conceptual point of view it would not be

80 Chapter 8. Structuring Mechanisms

reasonable if different instances of an indexed collection had different interpretations

of a type, which would be the consequence of lifting the types.4

STATE.The state schema of the aggregated unit may depend on any constant, say c:T,

declared by this unit. As discussed, each such constant is lifted to the function agg.c:

IS →T. Therefore, the state schema must be lifted, too. Each occurrence of a constant,

say c, is transformed into the function application (agg.c index), where index is an ad-

ditional state component characterising the index by which the considered instance of

the indexed collection is identified.

aggState == lift indexed Z(agg,Spec.State)∧[index :IS ]

The data state space of the specification unit resulting from the reduction process is

constituted by the data states of all instances of agg indexed by members of IS. Hence,

the derived schema SubunitStates contains a function mapping each identifier in IS to

a data state in aggState.

SubunitStates

agg :IS →aggState

. . .

∀id :IS •(agg id)∈[aggState |index =id ]

. . .

Each occurrence of a constant in the initialisation schema of the aggregated specifica-

tion unit is lifted analogously.

aggInit == lift indexed Z(agg,Spec.Init)∧[index :IS ]

After initialisation, each instance of the indexed collection must be in an initial state

as defined by the Init schema of the aggregated unit. The derived schema SubunitInit

thus contains the following definitions.

SubunitInit

State

∀id :IS •(agg id)∈[aggInit |index =id ]

. . .

OPS & PREDS.Similar to the case of simple aggregation, a promotion schema is defined,

which lifts each operation schema defined on the individual data state space of a single

instance of the indexed collection to the overall data state space.

4Simply preventing the lifting of types, however, would lead to an inconsistency, because free types are defined

in terms of the introduction of constants and injective functions. Thus, the declaration of free types would

indirectly imply the lifting of the corresponding constants and injections, which would in turn imply that

different instances of an indexed aggregation would have different interpretations of the free type.

8.1. Aggregation 81

Φagg

∆State

∆aggState

id? : IS

θaggState = (agg id?)

(agg0id?) = θaggState0

index0=index =id?

∀id :IS |id 6=id?•(agg0id) = (agg id)

Then, the specification unit resulting from the reduction process contains the lifted

operation

agg.Op == (Φagg ∧lift indexed Z(agg,Spec.Op)) \∆aggState,

for each operation schema Op in the aggregated specification unit Spec. The identifier

id?of the involved instance is an additional input parameter.

INTERFACE.The interface of the resulting specification unit is identical with the interface

of the aggregating unit. Thus, for each declaration

port chan domain Set

in the INTERFACE section of the aggregated unit Spec, either the declaration

port chan domain IS ×Set

must be part of the INTERFACE section or the declaration

channel chan domain IS ×Set

must be part of the LOCAL section of the aggregating unit.

The extension of the domains with the set IS reflects the remark made in the beginning

of this section: the particular instance of the indexed aggregation responsible for an

interaction must be identified by the transmitted value.

LOCAL.For each declaration

channel chan domain Set

in the LOCAL section of the aggregated unit Spec, the declaration

channel agg.chan domain IS ×Set

is part of the LOCAL section of the specification unit resulting from the reduction pro-

cess. Note that, in contrast to external ports, the names of internal channels are prefixed

by the respective unit identifier.

BEHAVIOUR.The behaviour definition of the aggregating unit (process term Behaviour)

refers to the behaviour of a particular instance of the aggregated collection with iden-

tifier id ∈IS by means of agg.Behaviour(id), e.g.,

Behaviour b=|||

id∈IS

agg.Behaviour(id).

82 Chapter 8. Structuring Mechanisms

The notation agg.Behaviour(id)abbreviates the application of the syntactic meta func-

tion lift indexed CSP to the behaviour definition of the aggregated unit Spec:

agg.Behaviour(id)b=lift indexed CSP(agg,Spec.Behaviour)[id/index].

As discussed, the dedicated identifier index, which is substituted by the value id, rep-

resents the index by which an instance of the indexed collection is identified.

The meta function lift indexed CSP causes the following syntactic transforma-

tions.

First, each set or value expression (of an instance of the channel input or output oper-

ator) must be adapted in order to be consistent with the change of the domains associ-

ated with external and internal channels. Each expression

chan?x:S

is transformed into

chan?x:{index} × Sor agg.chan?x:{index} × S

depending on whether chan is an external or internal channel. Further, each expression

chan!v

is transformed into

chan!(index,v)or agg.chan!(index,v)

again depending on whether chan is an external or internal channel.

For operation-related events, in contrast, the transformation is slightly different, be-

cause the identifier of the involved instance is transmitted as an input parameter of the

communicated schema binding. Each expression

OpX?par :S

is transformed into

agg.OpX?par : (S∧[id? : IS |id? = index ])

where id?is the input parameter used in the promotion schema Φagg.5Thus, each

binding of input and output parameters is extended with the pair id?7→ index, taking

into account the additional parameter introduced by the lifting process.6

This completes our description of the transformation rules for simple and indexed aggrega-

tion. In this way, we have defined the meaning of aggregation in a semi-formal yet system-

atic manner.

5We assume that the set of bindings is expressed in terms of a schema expression.

6The transformation of invocation and termination events (double-event approach) is defined analogously.

8.2. Extension 83

stage 1

stage 2

...

library (stage 0)

stage N

aggregation

extension

concrete specification unit

Figure 8.3: Structure of concrete specifications in RT-Z.

8.2 Extension

Extension is a structuring mechanism that is orthogonal to aggregation: any specification

unit within an aggregation hierarchy can extend other specification units outside this ag-

gregation hierarchy. Informally speaking, an extending specification unit imports the de-

finitions of the specification units it extends and is able to add new entities, to add new

constraints on imported entities or to redefine imported entities.7Extension is intended to

support the reuse of “libraries of specification units” and an incremental way of specifica-

tion. It is in some sense comparable with inheritance in object-oriented approaches, but more

restricted. In this section, we explain the use of the extension mechanism and its meaning.

Extension applies to concrete and abstract specification units. We first deal with the exten-

sion of concrete specification units.

Figure 8.3 outlines the structure of concrete specifications in RT-Z. From a structural point

of view, a concrete specification is a finite directed graph whose nodes are constituted by

concrete specification units and whose edges represent aggregation and extension relation-

ships. Aggregation is depicted by dotted arrows, and extension is depicted by solid arrows.

Such a graph must have the property that it can be partitioned into a set of trees, each of

which connected solely by aggregation relationships: these trees are what we have called

up to now aggregation hierarchies. Nodes of different trees can be connected by extension

relationships. Finally, the graph must be acyclic, i.e., there must be no path from a specifica-

tion unit to itself via aggregation and/or extension edges. This latter property is vital for the

7The term ‘entity’ encompasses ports, channels, processes, constants, operations, etc.

84 Chapter 8. Structuring Mechanisms

definition of the meaning of the structuring mechanisms.

From a more conceptual point of view, the structure of a graph forming a concrete specifi-

cation is interpreted as follows. The core of a concrete specification is a single aggregation

hierarchy (tree) of specification units. In the figure, it is enclosed by the rectangle stage N.

This aggregation hierarchy defines the structure and behaviour of the system to be designed.

Using extension relationships to connect this core aggregation hierarchy with other ones, the

concrete specification is further structured along a chronological dimension: the ultimate re-

sult of the design process need not be set up in a single step, but can be defined in several

stages by means of stepwise extension; this allows us to pursue an incremental way of speci-

fication. Each stage 1, . . . , Nof the design process is depicted in the figure by a rectangle.

Specification units of a particular stage can extend specification units of a lower stage.

The rectangle stage 0has a special meaning: it represents a library of specification units,

which can be used to collect general-purpose, frequently used specification units that can be

instantiated during a variety of system development tasks. This library can be regarded as

the stage preceding stage 1of each design process.

Let us consider the schematic definition of the concrete specification unit CExt as an example

for the following discussion.

SPEC.UNIT CExt

EXTENDS

Base1

instantiate . . . ;

rename . . . ;

hide . . . ;

redefine . . . ;

...

BaseN

instantiate . . . ;

rename . . . ;

hide . . . ;

redefine . . . ;

TYPES & CONSTANTS

•new data types and constants

•additional constraints on imported constants

INTERFACE

•new ports

•additional constraints on domains of imported ports

8.2. Extension 85

ENVIRONMENTAL ASSUMPTIONS

•environmental assumptions concerning new ports

•additional environmental assumptions concerning imported ports (EAExt).

SUBUNITS

•new subunits

STATE

•new state components

StateExt == . . . InitExt == . . .

•additional global invariants

GlobalInv == . . . GlobalInit == . . .

OPS & PREDS [ ]

•new operation schemas

Op == [ ∆State;. . . |. . . ]

•redefinition of imported operation schemas (Op is member of redefine list)

Op == [ ∆State;. . . |. . . ]

•extension of imported operation schemas

OpExt == [ ∆State;. . . |. . . ]

LOCAL

•new channels

BEHAVIOUR

•redefinition

Behaviour b=. . . references to processes defined in Base1, . . . , BaseN. . .

•extension

BehaviourExt b=. . .

86 Chapter 8. Structuring Mechanisms

Analogously to aggregation, the meaning of extension is defined in terms of trans-

formation rules that reduce the definitions of the extending (CExt) and of the extended

(Base1, . . . , BaseN) specification units to a single specification unit. Again, we discuss this

reduction process separately for each section.

To understand the following transformation rules related to extension, we must emphasise

one important difference between aggregation and extension. Aggregation is a structuring

mechanism on the level of specification unit instances, i.e., it defines the structure of the in-

stances of specification units. An instance of a specification unit can aggregate instances of

other specification units. In particular, it can aggregate several instances of a single specifi-

cation unit. Extension, in contrast, is a structuring mechanism on the level of specification

units, i.e., it does not fix the structure of the corresponding instances. A specification unit

can extend another specification unit, but an instance of a specification unit cannot extend

an instance of another specification unit. This has important consequences on the following

transformation rules: since extension refers to specification units directly, these rules need

not lift definitions of the extended specification units like the transformation rules for aggre-

gation.

TYPES & CONSTANTS.The extending specification unit CExt is able

•to introduce new constants and data types and

•to add new constraints on those constants and data types imported by the ex-

tended units Base1, . . . , BaseN.

The specification unit resulting from the reduction process will contain all constants

and data types defined by the extending and the extended specification units. We

discuss in the following how the declarations of and constraints on a single constant

or data type, which may be distributed to several of the considered specification units,

are composed in the specification unit resulting from the reduction process.

First, several declarations of a single given set

[T]

in the considered specification units are simply identified with each other and hence

result in a single declaration.

Second, axiomatic definitions of a single constant in several specification units

c:S1

Pred1

... c:SK

PredK

are transformed into

c:S1∩. . . ∩SK

Pred1∧. . . ∧PredK

That is, the constraints on the constant ccontained in different specification units are

conjoined. For this transformation to yield a well-typed result, the set expressions

S1, . . . , SK must have the same type.

8.2. Extension 87

Third, the reduction process expands free type definitions

T::= c1|. . . |cK |i1hhS1ii | . . . |iMhhSMii

into axiomatic definitions and declarations of given sets corresponding to the approach

described in Section 8.1.4 in the context of aggregation. Thus, when an extended or

the extending specification unit contains a free type definition, it is transformed into

the corresponding given set declaration and axiomatic definitions, which are in turn

subject to the corresponding composition rules already explained.

Analogously, each definition by syntactic equivalence

S== Expr

is expanded into the axiomatic definition

S:{Expr}

which is semantically equivalent.

INTERFACE.The extending specification unit CExt is able

•to introduce new ports and

•to further restrict the domains of imported ports.

The specification unit resulting from the reduction process will contain all ports de-

clared by the extending and extended specification units. Declarations of a single port

in several of the considered specification units

port chan domain S1... port chan domain SK

are transformed into

port chan domain S1∩. . . ∩SK

That is, the derived domain is the intersection of the domains associated with

chan. Again, for this transformation to yield a well-typed result, the set expressions

S1, . . . , SK must have the same type.

ENVIRONMENTAL ASSUMPTIONS.The extending specification unit CExt can define the

predicate EAExt, which is, by convention, interpreted as defining additional environ-

mental assumptions. This predicate is able to refer to the interface ports of the extend-

ing and of the extended specification units and is therefore able to specify assumptions

relating the interface ports of all considered specification units.

EA b= ( V

j∈{1,...,N}

Basej.EA)∧EAExt

The environmental assumption resulting from the reduction process is the conjunction

of the environmental assumptions of the extending and the extended units. That is,

one is not free in composing the environmental assumptions of the extended units.

This reflects the nature of extension where existing definitions should not be ignored

but only be augmented in a consistent way.

88 Chapter 8. Structuring Mechanisms

SUBUNITS.The extending specification unit CExt is able to introduce new aggregated sub-

units in addition to those introduced by the extended specification units.

Declarations of a single subunit in several of the considered specification units are

identified with each other, so there must not be any difference between these declar-

ations (concerning the instantiations, the renamed and hidden ports).8

STATE.The resulting data state space encompasses the data states of the extended units.

Optionally, the extending specification unit CExt can define its individual data state,

introducing new state components in addition to the state components of the extended

specification units. By convention, the individual data state, if any, is defined by the

schema StateExt.

The specification unit resulting from the reduction process contains the state schema

State

BaseStates

StateExt

GlobalInv

where the subspaces of the extended units are introduced by BaseStates, which is de-

rived as follows.9

BaseStates

Base1.State

. . .

BaseN.State

Global invariants, constraining the relationships between state components of sev-

eral extended units and the extending unit, can be defined by the dedicated schema

GlobalInv in the STATE section of the extending specification unit.

Also the definition of the overall data state space reflects the idea of extension: the state

invariants of the extended specification units cannot be ignored but only be extended.

The initialisation of the overall data state space is derived as follows.

Init

State

BaseInit

InitExt

GlobalInit

BaseInit

Base1.Init

. . .

BaseN.Init

The extending specification unit can define the schemas InitExt and GlobalInit to stip-

ulate relationships between the state components of the extending and the extended

specification units that must be satisfied by the initial data state.

OPS & PREDS.There are three alternatives for the extending specification unit CExt for de-

fining operations and predicates:

8The only case where this identification of multiply declared subunits should occur is when there are different

paths from an extending to an extended specification unit that declares a subunit.

9State components of different extended units with identical name are identified and must thus have compat-

ible types.

8.2. Extension 89

Introduction of new operation schemas: In this case, the extending unit defines an op-

eration schema, say Op, for which there is no corresponding definition in the ex-

tended units.

Redefinition of imported operation schemas: In this case, the extending unit defines

an operation schema, say Op, for which there are corresponding definitions in the

extended units; but these are ignored. The redefinition is made explicit by in-

cluding the identifier Op in the redefine list associated with the corresponding

extended unit.

Extension of imported operation schemas: In this case, the extending unit defines an

operation schema, say OpExt, for which corresponding operation schemas Op are

defined in the extended units.

The following discussion is carried out with respect to the operation/predicate Op.

In the first two of the above cases, the extending unit CExt must define the operation

schema

Op == [ ∆State;. . . |. . . ]

with respect to the overall data state. In the last case, the extending unit CExt must

define the operation schema

OpExt == [ ∆State;. . . |. . . ]

which defines further constraints on the operation Op. Note that OpExt is defined with

respect to ∆State rather than ∆StateExt: this allows OpExt to define constraints on the

data state components of the extended units not defining Op.

Assume that Op is defined by the extended units Basei1, . . . , BaseiM. Then, the specifi-

cation unit resulting from the reduction process contains the definition

Op == ( V

j∈{i1,...,iM}

Basej.Op)∧OpExt

If, for an operation schema Op defined by an extended unit, the extending unit does

neither define Op nor OpExt, the last case applies with the schema OpExt being set to

[|true ]by default.

LOCAL.The transformation of the declared channels is analogous to that discussed with

respect to the INTERFACE section.

BEHAVIOUR.The extending specification unit CExt is able

•to extend the imported behaviour patterns of the extended units or

•to completely redefine the dynamic behaviour.

In the first case, the extending unit defines, by convention, the process term

BehaviourExt. The defined process is composed in parallel with the behaviour patterns

of the extended units, which corresponds to a logical conjunction.

Behaviour b= ( k

i∈{1,...,N}

Basei.Behaviour)kBehaviourExt

90 Chapter 8. Structuring Mechanisms

The synchronising parallel operator kenforces a synchronisation of all processes on

the operation-related events.

In the second case, the dynamic behaviour is defined from scratch in the extending

unit by means of the process term Behaviour. This can be done by referring to processes

defined in the extended units Base1, . . . , BaseN.

Let us turn our attention to abstract specification units. The structure of abstract specifica-

tions in RT-Z is less complex than the structure of concrete specifications, because extension

is the only structuring mechanism applicable to abstract specification units. Therefore, an

abstract specification in RT-Z is simply a tree, where the nodes are constituted by abstract

specification units and where the edges represent extension relationships.

We now address the extension of abstract specification units. Let us consider the schematic

definition of the abstract specification unit AExt as an example for the subsequent discussion.

SPEC.UNIT AExt

EXTENDS

Base1

instantiate . . . ;

rename . . . ;

... BaseN

instantiate . . . ;

rename . . . ;

TYPES & CONSTANTS

•new data types and constants

•additional constraints on imported constants

INTERFACE

•new ports

•additional constraints on domains of imported ports

ENVIRONMENTAL ASSUMPTIONS

•environmental assumptions concerning new ports

•additional environmental assumptions concerning imported ports (EAExt)

8.2. Extension 91

I/O RELATIONS

•new I/O relations

•extension of imported I/O relations

•redefinition of imported I/O relations

STATE PROPERTIES

•new state components

StateExt == . . . InitExt == . . .

•additional global invariants

GlobalInv == . . . GlobalInit == . . .

•new time-variant state properties

•additional constraints on imported time-variant state properties

BEHAVIOURAL PROPERTIES

•redefinition

Behaviour b=. . .

•extension

BehaviourExt b=. . .

Again, the meaning of the extension of abstract specification units is defined in terms of

transformation rules, which we explain separately for each section.

TYPES & CONSTANTS,INTERFACE,ENVIRONMENTAL ASSUMPTIONS.The rules for redu-

cing these sections of the extending specification unit AExt and of the extended speci-

fication units Base1, . . . , BaseNare identical with those in the context of concrete speci-

fication units.

I/O RELATIONS.There are three alternatives for the extending specification unit AExt for

defining I/O relations:

Introduction of new I/O relations: In this case, the extending unit defines a schema, say

IORel, for which there is no corresponding definition in the extended units.

Redefinition of imported I/O relations: In this case, the extending unit defines a

schema, say IORel, for which there are corresponding definitions in the extended

units; but these are ignored.

92 Chapter 8. Structuring Mechanisms

Extension of imported I/O relations: In this case, the extending unit defines a schema,

say IORelExt, for which corresponding schemas IORel are defined in the extended

units.

The following discussion is carried out with respect to the I/O relation IORel. In the last

of the above cases, the extending specification unit must define the schema IORelExt,

which is interpreted as extending the I/O relation schema IORel. We assume that IORel

is defined by the extended specification units Basei1, . . . , BaseiM. Then, the specification

unit resulting from the reduction process will contain the definition

IORel == ( V

j∈{i1,...,iM}

Basej.IORel)∧IORelExt

If, for a schema IORel defined by an extended unit, the extending unit does neither

define IORel nor IORelExt, the last case applies with the schema IORelExt being set to

[|true ]by default.

STATE PROPERTIES.For abstract specification units, the derivation of the State schema

from the data states of the extending unit AExt and of the extended units

Base1, . . . , BaseNis identical with the corresponding derivation in the context of con-

crete specification units. Among other things, this means that the extending unit AExt

can define the schemas StateExt and GlobalInv in its STATE PROPERTIES section.

There are three alternatives for the extending specification unit AExt for defining time-

variant state properties:

Introduction of new time-variant state properties: In this case, the extending unit

defines a schema, say Prop, for which there is no corresponding definition in the

extended units.

Redefinition of imported time-variant state properties: In this case, the extending unit

defines a schema, say Prop, for which there are corresponding definitions in the

extended units; but these are ignored.

Extension of imported time-variant state properties: In this case, the extending unit

defines a schema, say PropExt, for which corresponding schemas Prop are defined

in the extended units.

The following discussion is carried out with respect to the time-variant state property

Prop. In the first two cases, the extending unit AExt must define the schema

Prop == [ State;. . . |. . . ]

with respect to the overall data state. In the last case, the extending unit AExt must

contain the schema

PropExt == [ State;. . . |. . . ]

which defines further constraints on the time-variant state property Prop. Note that

PropExt is defined with respect to State rather than StateExt: this allows PropExt to define

constraints on the data state components of the extended units not defining Prop.

8.2. Extension 93

Assume that Prop is defined by the extended units Basei1, . . . , BaseiM. Then, the specifi-

cation unit resulting from the reduction process will contain the definition

Prop == ( V

j∈{i1,...,iM}

Basej.Prop)∧PropExt

If, for a schema Prop defined by an extended unit, the extending unit does neither

define Prop nor PropExt, the last case applies with the schema PropExt being set to [|true ]

by default.

BEHAVIOURAL PROPERTIES.The extending specification unit AExt is able

•to extend the imported behaviour patterns of the extended units or

•to completely redefine the dynamic behaviour.

In the first case, the extending unit defines, by convention, the predicate BehaviourExt.

The defined predicate is conjoined with the behaviour definitions of the extended

units.

Behaviour b= ( V

i∈{1,...,N}

Basei.Behaviour)∧BehaviourExt

In the second case, the dynamic behaviour is defined from scratch in the extending

unit by means of the predicate Behaviour. This can be done by referring to predicates

defined in the extended units Base1, . . . , BaseN.

Having described the transformation rules for extension, we have defined the meaning of

extension in a semi-formal yet systematic manner.

The syntax for extension used so far is the vertical form. In cases in which the extension of a

specification unit is carried out without instantiating or renaming identifiers, the horizontal

form can be used.

SPEC.UNIT Ext EXTENDS Base

...

In the horizontal form, the identifier of the specification unit to be extended is recorded in

the headline of the extending specification unit.

In the current and previous section, we have treated the transformation rules for aggregation

and extension separately. In general, however, an RT-Z specification contains both aggrega-

tion and extension relationships. So, we must address the interplay between the two kinds

of transformation rules.

According to our previous remarks, an RT-Z specification is a finite, directed and acyclic

graph, whose nodes are constituted by (simpler) graphs and whose edges represent ex-

tension relationships. Each graph constituting a node of the top-level graph is a tree of

94 Chapter 8. Structuring Mechanisms

specification units whose edges represent only aggregation relationships (i.e., aggregation

hierarchies). Since the top-level graph is finite and acyclic, there must exist nodes without

outgoing edges. These leaf nodes, constituted by aggregation hierarchies, can be reduced

to single specification units by applying the transformation rules for aggregation. Then,

the extension relationships leading to these leaf nodes can be eliminated by applying the

transformation rules for extension. The resulting top-level graph is smaller than the original

graph, so finitely many of the above steps suffice to reduce the whole RT-Z specification

to a single specification unit whose meaning is the meaning of the whole specification by

definition.

8.3 Renaming

When instantiating a specification unit by means of aggregation or extension, the elements

of its interface can be renamed. The syntax in the context of aggregation is as follows.

subunit agg spec.unit Spec

rename chan1to chan0

1, . . . , chanNto chan0

The meaning of the renaming operator for specification units (which should not be confused

with the CSP renaming operator for processes) is the renaming of the involved external chan-

nels in the INTERFACE,BEHAVIOUR and ENVIRONMENTAL ASSUMPTIONS sections of the

specification unit Spec. The renaming of the channel identifiers must represent an injective

function.

8.4 Hiding

When instantiating a specification unit by means of aggregation, arbitrary elements of the

interface can be hidden. The syntax is as follows.

subunit agg spec.unit Spec

hide chan1, . . . , chanN

The meaning of the hiding operator is given by transferring the listed channels from the

INTERFACE to the LOCAL section within the specification unit Spec.

8.5 Parametrisation

To support the reuse of specification units in different contexts, any specification unit may

contain a list of formal parameters that must be instantiated by the respective aggrega-

tion/extension context with appropriate actual parameters. Formal parameters are place-

holders for data types or constants. They are introduced in the head of a specification unit

within square brackets. Formal parameters denoting data types allow us to define generic

specification units.

8.6. Example: Alternating Bit Protocol 95

Each formal parameter introduced by a specification unit must additionally be declared in

its TYPES & CONSTANTS section in order to allow us to type-check specification units in-

dependently of their context. A parametrised specification unit can define constraints on

the allowed instantiations of its formal parameters in its TYPES & CONSTANTS section by

expressing constraints on the formal parameters with the help of the Z notation.

When the specification unit

SPEC.UNIT Agg[fp1, . . . , fpN]

...

is aggregated by another specification unit

subunit agg spec.unit Agg

instantiate fp1with ap1, . . . , fpNwith apN

the formal parameters are substituted by the supplied actual parameters.

Note that the top-level specification unit of a specification must not contain formal param-

eters, because it is not embedded into a context which provides actual constants and types.

8.6 Example: Alternating Bit Protocol

To illustrate the structuring mechanism aggregation, we proceed with the example started

in Chapter 7: the alternating bit protocol. There, we have discussed the requirements speci-

fication of a reliable communication medium and one component of the design specification

of the AB protocol. In the following, we present the top-level specification unit ABProtocol

of the design, which aggregates the four components that are depicted in Figure 7.2.

SPEC.UNIT ABProtocol

INTERFACE

port In,Out domain Message

TYPES & CONSTANTS

Bit ::= true |false MaxTransDelay,MaxAckDelay :T

MaxAckDelay >RMaxTransDelay +RMaxTransDelay

96 Chapter 8. Structuring Mechanisms

ENVIRONMENTAL ASSUMPTIONS

EA b=∀t:T;msg :Message •

Out.msg live from t⇒

∃dt :T|dt ⩽R(MaxTransDelay +RMaxTransDelay)•Out.msg at (t+Rdt)

SUBUNITS

subunit sender spec.unit Sender

instantiate MSG with Message,ACK with Bit,

MaxDelay with MaxAckDelay;

subunit receiver spec.unit Receiver

instantiate MSG with Message,ACK with Bit,

MaxDelay with MaxAckDelay;

subunit msg medium spec.unit UnreliableMedium

instantiate MSG with Message ×Bit,MaxDelay with MaxTransDelay;

rename Send to MsgSend,Rcv to MsgRcv;

subunit ack medium spec.unit UnreliableMedium

instantiate MSG with Bit,MaxDelay with MaxTransDelay;

rename Send to AckSend,Rcv to AckRcv;

LOCAL

channel MsgSend,MsgRcv domain Message ×Bit;

channel AckSend,AckRcv domain Bit

STATE

GlobalInit

sender.ack =receiver.ack

BEHAVIOUR

Behaviour b= (sender.Behaviour

|[{| MsgSend |} ∪ {| AckRcv |} ]|

(msg medium.Behaviour ||| ack medium.Behaviour)

|[{| AckSend |} ∪ {| MsgRcv |} ]|

receiver.Behaviour)

Consider first the SUBUNITS section. It introduces the four components depicted in Fig-

ure 7.2 by means of simple aggregation. The aggregated units msg medium and ack medium

are both instances of the specification unit UnreliableMedium, because they have the same

8.6. Example: Alternating Bit Protocol 97

generic behaviour. To take their differences into account, both declarations associate the

formal parameter MSG with different sets (instantiate statement), and the identifiers

of the external channels are renamed appropriately in order to embed the media into their

respective context (rename statement).

The data state of the protocol is constituted by the data states of the aggregated units, in this

case of the units sender and receiver. The schema State of the aggregating unit ABProtocol is

derived as discussed in Section 8.1.4.

State

sender :Sender.State

receiver :Receiver.State

Since there are no constraints on the relationship between the data states of the sender and

receiver components, the schema GlobalInv is omitted. There is, however, a constraint on the

relationship between the states of the acknowledgement bits of the components at initialisa-

tion, stipulated by the schema GlobalInit: the bits must be initialised with the identical value,

but the particular value is irrelevant.

Finally, the BEHAVIOUR section fixes the configuration of the aggregated units, including

their interaction via internal channels. This is achieved by means of the process term lan-

guage of timed CSP. Note that all channels that are declared in the LOCAL section are hidden

from the interface by definition.

The specification units Receiver and UnreliableMedium, which define the behaviour of the

receiver component and of the unidirectional, unreliable message media, are given for the

sake of completeness.

The crucial aspect of the definition of the specification unit UnreliableMedium is how it makes

explicit the possible error modes of the message medium in the behaviour definition: after

receiving a message on the channel Send, it chooses an i∈Nnondeterministically. If i= 0,

then the interleaving process expression simplifies to |||i∈∅Trans(i,m), which is equivalent

to Skip. This case represents the loss of the received message. If i= 1, then the interleaving

process expression simplifies to |||i∈{1}Trans(i,m), which is equivalent to Trans(1,m). This

case represents the correct behaviour of the message medium, because one copy of the re-

ceived message is correctly delivered. The cases in which i>1represent the duplication of

the received message.

SPEC.UNIT UnreliableMedium [MSG,MaxDelay ]

TYPES & CONSTANTS

[MSG]MaxDelay :T

INTERFACE

port Send,Rcv domain MSG

98 Chapter 8. Structuring Mechanisms

BEHAVIOUR

Behaviour b=Cycle

Cycle b=Send?(m:MSG)→u

i∈N

|||

j∈1..i

Trans(j,m)

;Cycle

Trans(i,m)b=Wait((i−1) ∗RMaxDelay,i∗RMaxDelay]; Rcv!m→Skip

The specification unit Receiver is defined analogously to the specification unit Sender dis-

cussed in detail in Section 7.1.

SPEC.UNIT Receiver [MSG,ACK,MaxDelay ]

TYPES & CONSTANTS

[MSG,ACK]#ACK = 2

MaxDelay :T

INTERFACE

port Out domain MSG;

port MsgRcv domain MSG ×ACK;

port AckSend domain ACK

STATE

State == [ ack :ACK ]

OPS & PREDS [ CorrectAck,IncorrectAck ]

CorrectAck == [ ∆State;rec? : ACK |rec? = ack ∧ack06=ack ]

IncorrectAck == [ ΞState;rec? : ACK |rec?6=ack ]

BEHAVIOUR

Behaviour b=REC

REC b= (MsgRcv?(rec :MSG ×ACK)→

(CorrectAckX!h| rec? == rec.2|i →

(Out!(rec.1) →Skip ||| σ(AckSend!ack →Skip)); REC

IncorrectAckX!h| rec? == rec.2|i → σ(AckSend!ack →REC)))

.{MaxDelay}σ(AckSend!ack →REC)

8.6. Example: Alternating Bit Protocol 99

This completes our informal discussion of the integrated formalism RT-Z. We have intro-

duced two models of integrating Z and timed CSP, we have described the links between the

base formalisms in the two models, we have discussed the structure of abstract and con-

crete specification units and we have introduced and defined the structuring mechanisms

for organising large and complex specifications.

In the next part, we back up formally the RT-Z notation introduced in this part.

100 Chapter 8. Structuring Mechanisms

Part III

Formal Foundation

101

Chapter 9

Denotational Semantics

According to the classification of approaches to combining complementary formalisms pro-

posed in Chapter 5, a conserving integration must be equipped with a common semantics.

In this chapter, we define a denotational semantics for single specification units of RT-Z. Cor-

responding to the distinction between abstract and concrete specification units in Chapter 7,

we have to define two different semantic functions: in Section 9.2, we define the meaning of

concrete specification units; abstract specification units are dealt with in Section 9.3.

9.1 Basics

In correspondence with the denotational semantics of timed CSP, the denotational semantics

of RT-Z maps each RT-Z specification unit to the set of timed observations that could be made

during the evolution of the specified artifact. In the semantic model of RT-Z, such a timed

observation consists of two components.

•The external interaction of the artifact in the observation interval, consisting of

–the record of which events have occurred in which order and at which time in-

stants at the interface between the artifact and its environment (where an event

may involve the communication of a complex data value) and

–the record of which offered events have been refused by the artifact at particular

time instants.

This corresponds to the structure of process denotations in timed CSP, being composed

of timed traces and timed refusals.

•The evolution of the artifact’s data state in the observation interval. We call such a

record timed state. It has no counterpart in the semantic model of timed CSP.

The above description already incorporates an essential design decision, namely that the

evolution of the data state should be part of the denotations. This decision is in accordance

with the semantic model of TCOZ [Mahony and Dong, 1999a] but in contrast to the one of

103

104 Chapter 9. Denotational Semantics

CSP-OZ [Fischer, 2000], see Chapter 4. Let us first briefly discuss the decision to include the

evolution of the data state in the denotations of an RT-Z specification.

The semantics of CSP-OZ maps each CSP-OZ class to a set of failure/divergence pairs1,

thereby abstracting from the evolution of the data state. From our point of view, too much

information is lost by ignoring the data state evolution, because some kinds of requirements

with respect to the behaviour of an object cannot be expressed in this case. More precisely,

it is not possible in a satisfactory manner to restrict the allowed behaviour patterns of an

object that has performed a nondeterministic operation whose nondeterminism is not visible

to the environment (not visible via an external interaction). In other words, in CSP-OZ,

the ability to express internal nondeterminisms related to the data state of the object under

consideration stands in contradiction to the ability to make any statements about its required

external behaviour.

We provide an example of such a situation in Figure 9.1.

LossyCoffeeMachine

Capacity :N1

cups :N

cups ≤Capacity

INIT

cups =Capacity

Output

∆(cups)

cups >0

cups0=cups −1

Loss

∆(cups)

cups >0

cups0<cups

main = (Output →Skip uLoss →Skip); main

Figure 9.1: Lossy coffee machine.

The CSP-OZ class models a lossy coffee machine with two operations: Output models the

output of one cup of coffee to the user, and Loss models a malfunction of the machine, loosing

an arbitrary number of cups of coffee nondeterministically. It is important to note that this

nondeterminism—the amount of coffee lost—is not visible to the environment. According to

the semantics of CSP-OZ, the failure (hLossi,{Output,Loss})is an observation of the specified

machine: after a loss has occurred, the machine is able to refuse to output further cups of

coffee, regardless of whether or not it has still coffee available. The reason is that the Loss

operation could potentially lead to a completely empty coffee machine, which is unable to

output further coffee. Since the data state that actually resulted from the Loss event is ignored

by the semantics, one cannot make the acceptance of the output of coffee dependent on the

1in the sense of the failures–divergences model of (untimed) CSP

9.2. Concrete Specification Units (Open System View) 105

real amount of coffee available. This means that, on the basis of the CSP-OZ semantics, it is

not possible to express requirements with respect to the behaviour of the machine like: “the

machine is ready to output coffee as long as it is not empty.”

To model such systems properly, including nondeterminisms not visible to the environment,

the evolution of the data state must be taken into account.

As discussed in Chapter 2, we must distinguish between two system views in the course of

the system development process. In the open system view, the artifact at hand is considered

as a white box, i.e., its internal properties are visible, whereas it is considered as a black box

in the closed system view. The intention pursued by the above argument was to justify the

need for the open system view from the semantic point of view. This, however, does not

imply that we can dispense with a semantic model reflecting the closed system view.

Accordingly, the approach taken in this chapter is as follows. We first deal with the timed

failures/states model of RT-Z in Sections 9.2 and 9.3, which reflects the open system view

and is the more complex model. Afterwards, we treat the extended timed failures semantics

of RT-Z specification units in Section 9.4, which reflects the closed system view and which

can be easily derived from the former.

9.2 Concrete Specification Units (Open System View)

The structure of concrete specification units and the principles of how they integrate the Z

and timed CSP notation are discussed in Section 7.1. In this section, we define a common

semantic model unifying the semantic models of the base formalisms in order to map each

concrete specification unit of RT-Z to a unique meaning.

In Section 9.2.1, we elaborate the consequences of the potential concurrency of operations

working on different parts of the data state space. In particular, we define constraints on the

possibility to apply operations concurrently. They ensure that scenarios of concurrent oper-

ation applications can be related to corresponding evolutions of the underlying data state in

a reasonable manner. Then, in Section 9.2.2, we give an overview of the semantic integra-

tion within concrete specification units and outline its major steps. Sections 9.2.3 and 9.2.4

introduce intermediate semantic models that are the basis for the final timed failures/states

model dealt with in Section 9.2.5. The formal definition of the semantic integration of the Z

part and the CSP part of a concrete specification unit in Section 9.2.6 on the grounds of the

timed failures/states model concludes the current section.

In Section 9.3, we define the timed failures/states semantics of abstract specification units,

which is done much more succinctly, given their less complex structure and the definitions

in the current section.

9.2.1 Concurrency on Common Data State

Let us consider in the following an RT-Z system specification that is composed of an aggrega-

tion hierarchy of specification units. In this case, the overall data state of the specified system

106 Chapter 9. Denotational Semantics

can be regarded as being hierarchically partitioned into subspaces according to the hierarch-

ical decomposition of the system specification into specification units, where each specifica-

tion unit defines its associated data state. Roughly speaking, each operation defined in one

of the specification units depends on and transforms only the subspace of the overall data

state that is associated with its specification unit. When applied, it should leave the other

subspaces of the overall data state unchanged and its transformation should depend only

on the current values of variables within this subspace of the data state. However, when we

take the concept of global invariants into account, this clear separation between different sub-

spaces is dropped: a global invariant establishes relationships between variables in different

subspaces of the overall data state, which must be respected when an operation transforms

one subspace of the data state.

As a consequence, RT-Z addresses the concurrent application of operations only under two

specific conditions that are discussed in the following paragraph; if these conditions are not

met, RT-Z refuses to make any statements about the result of the concurrent application.

More specifically, the behaviour that is specified if these conditions are not met is that of the

diverging process, which denotes the set of all timed failures and timed states.

Roughly speaking, the concurrent application of operations is addressed by RT-Z only if

these operations do not interfere with each other, that is, if their corresponding transform-

ations of the data state do not affect each other. More precisely, the effect of concurrently

applying a set of operations, say OpSet, with particular input parameters is well-defined

with respect to the current data state only if the following two conditions are satisfied:

1. The subspaces of the data state potentially changed by applying the operations of

OpSet must be pairwise disjoint. In other words, there must not be any state com-

ponent that might be subject to change by more than one of the concurrently applied

operations.

2. The particular order in which the individual transformations of the data state take

place must not be relevant. That is, the set of final data states and output parameters

the concurrent application of the operations in OpSet may produce must be independ-

ent of the particular order in which the corresponding transformations of the data state

really take place. Moreover, this set of final data states and produced output param-

eters must not be empty. This excludes the case that the application of some of the

operations of OpSet violates the preconditions of others, ensuring that each operation

of OpSet can be applied to the data state resulting from the application of any combin-

ation of other operations of OpSet.

In brief, these conditions allow operations transforming disjoint subspaces of the overall

data state to be applied concurrently if they do not interfere with each other via global in-

variants.

If the concurrent application of a set of operations meets the above ‘non-interference’ con-

ditions with respect to the current data state, then its effect on the current data state is the

sequential composition of the individual state transformations in an arbitrary order. If, on

the other hand, operations are applied concurrently without satisfying these conditions, the

effect on the data state is left unspecified: RT-Z does not really prevent the concurrent ap-

plication of operations interfering with each other, but refuses to define its result. It is the

9.2. Concrete Specification Units (Open System View) 107

State == [ n,m:N|n≤m]

Op1 == [ ∆State |n0=n+ 1 ∧m0=m]

Op2 == [ ∆State |m0=m−2∧n0=n]

tt1t2t3t4

invocation / termination Op1IOp2IOp1TOp2T

(n,m) (2,5) (2,5) (3,5) (3,3)

(3,5) (3,5) (4,5) divergence

(4,5) X(5,5) X

Figure 9.2: Concurrent application of operations.

responsibility of the specifier to guarantee that the concurrent application of interfering op-

erations is prevented. This gives rise to a specific kind of validation condition.

As already explained, there are two alternatives for modelling state transitions (operations);

either an operation is modelled to be applied during a time interval where this interval is

delimited by the events of invocation OpIand termination OpT, or an operation is modelled

to be applied instantaneously, marked by the event of execution OpX. These two cases must

be distinguished regarding the above ‘non-interference’ conditions.

In the double-event approach, the application of an operation, say Op, starts with the occur-

rence of the invocation event OpI. For the operation to be invoked, the precondition of the

operation must be satisfied with respect to the current data state, where the evaluation of

the precondition may depend on the overall data state, not only on the subspace associated

with the operation (see the example on p. 66). The application of the operation is completed

with the occurrence of the termination event OpT; the caused state transition takes effect at

this time instant: it is based on the data state that is present at termination. It is important

to note that the overall data state may have changed during the application—due to the ter-

mination of other operations applied concurrently. In the double-event approach, the above

‘non-interference’ conditions apply to operation applications whose application intervals—

the intervals between invocation and termination—overlap.

In the single-event approach, on the other hand, the instantaneous application of an opera-

tion, say Op, is marked by the occurrence of the execution event OpX. For the operation to

be executed, its precondition must be evaluated successfully with respect to the current data

state. The above ‘non-interference’ conditions apply to operations executed simultaneously,

i.e., at the same time instant.

We illustrate the above discussion with the help of the example in Figure 9.2. The underlying

data state consists of two components nand m, where nmust be less than or equal to m.

Further, there are two operations, Op1and Op2, incrementing nby 1 and decrementing mby

2, respectively.

We consider three scenarios in which the operations are applied concurrently in the context

of different data states.

108 Chapter 9. Denotational Semantics

0 t1 t2 t

...

Op1T, Op2T

(Op1X, Op2X)

Op1o

9Op2

(Op2o

9Op1)

Op2

Op2T

(Op2X)

Figure 9.3: Structure of timed states.

In the first scenario, Op1and Op2are invoked at t1and t2in this order with respect to the

data state (n,m) = (2,5). This data state allows the operations to be applied in a well-defined

manner, because in whatever order their state transformations take place, the final data state

will be (3,3). Let Op1and Op2terminate at t3and t4in this order. Then, the termination of

Op1leads to the data state (3,5).

Note first that the state transformation that is caused by the termination of Op2relates the

data states (3,5) and (3,3), where (3,5) is the data state that is present when Op2terminates.

At first glance, this might appear counterintuitive, because the state transformation of Op2

is not based on the data state (2,5) that is present when it is invoked. However, a closer look

reveals that any change of the data state that might have taken place between the invocation

at t2and the termination at t4cannot have any effect on Op2’s transformation within its

associated subspace of the overall data state, as long as we consider a well-formed (i.e., non-

interfering) application scenario.

Note also that, even though the state transition that is caused by Op2is based on the data

state (3,5) present at termination, it is the data state (2,5) present at invocation that is used

to determine whether Op2can be applied (by computing the precondition). Again, as long

as we consider a well-defined application scenario, the fact that the precondition of Op2is

satisfied at invocation implies that it must also be satisfied at termination.

In the second application scenario, Op1and Op2are applied concurrently with respect to the

data state (3,5), which does not allow the operations to be applied concurrently in a well-

defined manner; because the first operation terminates necessarily in a data state violating

the precondition of the other one. In the example, Op1terminates at t3in the data state (4,5),

in which the precondition of Op2is not satisfied. Hence, the termination of Op2at t4results

in divergence.

In the last application scenario, we consider a data state (4,5) that prevents the invocation of

Op2at t2, because its precondition is not satisfied. Thus, in contrast to the previous scenario,

the attempt to apply Op1and Op2concurrently does not result in divergence, but in the

application of only Op1.

Let us now consider the structure of timed states as outlined in Figure 9.3, each of which

is a constituent of a timed observation in RT-Z. A timed state has the purpose to record the

changes of the data state caused by the execution or termination of operations. Since ar-

bitrarily many operations may be executed simultaneously (single-event approach) and/or

may terminate simultaneously (double-event approach), a timed state must be able to record

9.2. Concrete Specification Units (Open System View) 109

arbitrarily many state changes for a single time instant. This is achieved as follows: a timed

state assigns a data state to any time instant at which at least one operation is executed or

terminates. This data state represents the result of all individual state changes at that time

instant. In other words, it combines the individual state changes to a single change. Ac-

cordingly, a timed state is a partial function mapping those time instants of the observation

interval at which at least one operation is executed or has terminated to the data state that

is the result of applying in an arbitrary order all these operations to the previously recorded

data state.

This leads to the following interpretation of a timed state. At initialisation (time instant 0),

the timed state records the initial data state, which is one of those data states characterised

by the Init schema of the Z part. For each time instant at which no execution or termination

event occurs, the timed state is undefined. The current data state at such a time instant is

the last data state recorded in the timed state before. For each time instant at which at least

one operation is executed or terminates, the timed state records all state changes that have

resulted from these operation executions or terminations.

9.2.2 Semantic Integration: Overview

We define a denotational semantics, which associates a set of mathematical objects with a

single concrete specification unit; the denotations represent possible timed observations that

could be made when observing the artifact under consideration. Concerning the design of

this denotational semantics, a major decision is not to begin from scratch, but to make use of

the denotational semantics of the base formalisms as far as possible. For both Z and timed

CSP, denotational semantics are provided by the Final Committee Draft of the ISO standard

for Z [ISO, 2002] and the finite timed failures model [Schneider, 1999b], respectively. Reusing

the denotational semantics by encapsulating their semantic functions within the semantic

function of RT-Z is not only more economical than defining an entirely new semantic func-

tion, but also makes the semantics of RT-Z more robust against potential changes of the

semantics of the base formalisms. Following the definition of the Z semantics in [ISO, 2002],

we use the Zermelo–Fraenkel (ZF) axiomatisation of set theory [Hamilton, 1982, Enderton,

1977] in combination with logic as the metalanguage for defining the denotational semantics

of the integrated formalism. We follow the syntactic conventions of using the ZF set theory

that are applied in the Z Standard [ISO, 2002, Chapter 4]. These syntactic conventions lead

to a notation that is similar to the Z notation itself. However, the two notations should not

be confused.

The main principle of integrating the semantic models of Z and timed CSP follows an idea of

Smith [1997] and adapts it to our specific context: each Z specification is given an interpreta-

tion in the semantic model of timed CSP. Using this interpretation, the combination of the Z

and the (timed) CSP part of a specification unit is interpreted as their parallel composition,

where the two parts synchronise on the events related to the operations of the Z part. The

definition of the semantics of concrete specification units consists of three steps associated

with corresponding intermediate semantic models, which are depicted in Figure 9.4: the his-

tory model, the extended timed failures model and the timed failures/states model; the Z

Standard and the timed failures model of timed CSP are their foundation.

In Figure 9.4, there are two lines of transformation. The first line deals with the transform-

110 Chapter 9. Denotational Semantics

Z Standard

history model

timed failures model

extended timed failures model

timed failures / states model

theory (set of models)

set of histories

set of timed failures

set of timed

failures / states

set of timed failures

Z part

(Z specification)

CSP part

(extended timed

CSP specification)

semantics of

concrete specification unit

operation

events

interpretation as

timed CSP process

state-oriented

interpretation

consideration of

data state evolution

Figure 9.4: Steps of the semantic integration.

ation of the denotation of a Z specification, as defined by the Z Standard, into a form com-

patible with the denotation of a timed CSP process, i.e., it gives a Z specification a timed

failures/states semantics. The second line is about giving a timed CSP specification a mean-

ing in the timed failures/states model of RT-Z. As just discussed, finally, the appropriately

transformed interpretations of the Z and the CSP part are composed in parallel to obtain the

semantics of the overall concrete specification unit.

The simplest intermediate model is the history model. The denotational semantics given in

the Z Standard maps each section of a Z specification to a set of so-called models. A model

is a function mapping each identifier occurring in the considered specification section to

a value, which the identifier may denote according to all constraints defined in the whole

specification. The Z Standard does not fix a particular interpretation of Z specifications; in

particular, it does not reflect the state-oriented conventions of interpreting Z specifications;

however, this is the mandatory interpretation in the context of concrete specification units.

Therefore, we transform a model into a form reflecting the state-oriented interpretation. This

interpretation regards a Z specification as defining a data state and a set of transitions on

it. Histories, as used by Smith [1997], are mathematical objects reflecting this state-oriented

interpretation. A history represents a possible observation of the specified artifact up to

a particular time instant. It consists of the sequence of data states the artifact has passed

9.2. Concrete Specification Units (Open System View) 111

through, together with the sequence of operation events the artifact has performed. After

this transformation, the meaning of a Z specification is expressed in terms of a set of histories.

The purpose of the extended timed failures model is twofold. First, it lifts the syntax and

the semantic model of timed CSP such that timed CSP expressions can be embedded within

a Z context. Second, it is the underlying model to give a Z specification—via the history

model—a ‘timed CSP-like’ meaning. Hence, it brings together the semantic models of Z and

timed CSP.

The main tasks related to the definition of this model are:

•The extension of the timed CSP syntax in order to express the links from the CSP to the

Z part of a concrete specification unit.

•The definition of the concepts of the timed failures model in ZF set theory, including

–the time domain of timed CSP processes

–the constituents of the denotations in the timed failures model and

–the properties of the timed failures model stating which sets of timed failures are

valid, consistent timed observations of a process.

•The definition of the meaning of the extended syntax based on the denotational se-

mantics of timed CSP.

The final model is the timed failures/states model; it augments the previous model by taking

into account the evolution of the data state of the specified artifact in the considered observa-

tion interval. The lifting from the extended timed failures to the timed failures/states model

concerns only the Z part, because the CSP part does not make any statements about the data

state.

So far, the meaning of the Z part of a concrete specification unit is defined in terms of a set

of pairs of timed failures and timed states, and the meaning of the CSP part is expressed in

terms of a set of timed failures. In the final step, the meaning of the RT-Z specification unit is

defined to be the relation between timed failures and timed states as defined by the Z part,

where the domain of this relation is restricted to the set of timed failures as defined by the

CSP part. More abstractly, the meaning of the specification unit is defined to be the parallel

composition of its parts synchronising on the set of operation-related events, see Figure 6.5.2

9.2.3 History Model

For the purpose of defining the meaning of concrete specification units, we fix a particular

interpretation of their Z parts. Roughly speaking, we adopt the state-oriented interpretation

of Z specifications. This state-oriented interpretation, which is the most widespread con-

vention of using Z in practice [Woodcock and Davies, 1996, Wordsworth, 1992], regards a

2To be more precise, the operation-related events are hidden after the parts have been composed in parallel.

The operation-related events serve only to connect the parts; they are not part of the external interface of a

specification unit. The information contained in Figure 6.5 is defined formally by the relations tfs of modelINT

and tfs of modelEXT on p. 144.

112 Chapter 9. Denotational Semantics

Z specification as characterising the specified artifact as a state-transition system. Follow-

ing this convention, a Z specification must define a dedicated schema that models the data

state. Moreover, operation schemas are defined that model transitions on that data state.

The meaning of a Z specification as defined by the Z Standard, however, is absolutely inde-

pendent of any particular kind of interpretation. This semantics associates a theory with each

(sectioned) Z specification, which is a mapping from section identifiers to sets of models. A

model, in turn, is a function mapping each introduced identifier to a value that this identi-

fier may denote according to all specified constraints. As already mentioned, it is the task

of the first sub-step of the semantic integration to transform a set of models, denoting the

meaning of the Z part of a concrete specification unit, into a set of histories, which reflect the

state-oriented interpretation of this Z part.

The metalanguage used in this section to define the denotational semantics of RT-Z is based

on logic and Zermelo–Fraenkel set theory, which is an untyped theory. Regarding the choice

of the semantic metalanguage, we follow the approach of the Z Standard to defining the

denotational semantics of the Z notation. The concrete syntax used in this section is identical

in appearance to that of the base language Z itself, but is grounded only on logic and ZF set

theory. Using the Z notation as the concrete syntax allows us to apply the powerful tool ESZ

[B¨

ussow and Grieskamp, 1998] for performing syntax checks: all formal definitions in this

chapter are type-checked. However, since ZF set theory, in contrast to Z, is untyped, we are

forced to “circumvent” the Z type system at different places.

To define the meaning of concrete specification units, we must be able to refer to their syn-

tactical constituents, which are entire Z specifications (Z part), timed CSP process terms (BE-

HAVIOUR section), predicates of the timed failures model (ENVIRONMENTAL ASSUMPTIONS

section) and Z expressions (channel signatures in the INTERFACE and LOCAL sections). Let

ZSpec,ZExpr,ETCSP PROCESS and ETFM PREDICATE denote these syntactical units of

the base formalisms. They are characterised by the corresponding syntax definitions of Z

and timed CSP.

The BEHAVIOUR section can define any number of processes, and it must define the dedi-

cated process Behaviour, which models the dynamic behaviour of the artifact under consider-

ation. Let PROCESS be the set of all identifiers of processes. Then, the information induced

by the BEHAVIOUR section is a function mapping the identifier of each defined process to

the corresponding defining expression. We call that function process environment.

ProcEnv == PROCESS 7 7→ ETCSP PROCESS

The INTERFACE and the LOCAL sections of a specification unit associate Z expressions with

external and internal channels, which are evaluated in the context of the Z part and denote

the value domains of the declared channels. Let CHANNEL be the set of all identifiers of

external and internal channels. The information induced by these two sections is a function

mapping channel identifiers to Z expressions. We call that function channel signature.

ChanSgn == CHANNEL 7 7→ ZExpr

9.2. Concrete Specification Units (Open System View) 113

Evaluated in the context of the Z part, each Z expression denotes the set of data values that

can be communicated along the corresponding channel.

A concrete specification unit, as introduced in Chapter 7, incorporates

•a Z specification (ZSpec) containing its TYPES & CONSTANTS,STATE and OPS & PREDS

section,

•two functions (I,L)mapping each external and internal channel, declared in the

INTERFACE and LOCAL sections, to a Z expression,

•a predicate (EA) of the extended timed failures model constituting the ENVIRONMEN-

TAL ASSUMPTIONS section,

•a behaviour definition (Behav) constituting the BEHAVIOUR section and

•a set of identifiers (OPS) characterising some schemas defined in the OPS & PREDS

section as specifying operations and predicates (as opposed to auxiliary definitions).

CSpecUnit == [Zpart :ZSpec;

I,L:ChanSgn;

EA :ETFM PREDICATE;

Behav :ProcEnv;

OPS :FNAME]

According to the rules for constructing the Z part of a concrete specification unit explained

in Chapter 7, each Z specification constituting such a Z part consists of the sections TYPES &

CONSTANTS,STATE and OPS & PREDS, which are related via the obvious parent-relation-

ships. The STATE section must introduce the dedicated schemas State and Init, and the

OPS & PREDS section must define an operation schema for each identifier in the set OPS.

The Z Standard introduces the set NAME to denote the set of all identifiers of a Z specifica-

tion and the function decor to define the decoration of identifiers. We assume that NAME,

PROCESS and CHANNEL are disjoint. The Z Standard also introduces the symbols Wto

denote “a world of sets, providing semantic values for Z expressions,” Uto denote “the

semantic universe, providing semantic values for all Z expressions, including generic defi-

nitions” and Model to denote the set of all models.

Furthermore, we refer to the semantic functions [[ ]]and [[ ]]Zdefined by the Z Standard.

They define the meaning of Z expressions and sections of Z specifications, respectively.

When following the state-oriented conventions, the name space of each Z operation is par-

titioned into plain names, primed names, names ending with a ‘?’ (input parameters) and

names ending with a ‘!’ (output parameters).

Primed == {n:NAME •decor 0n}

Inputs == {n:NAME •decor ?n}

Outputs == {n:NAME •decor !n}

PrimedOf == {n:NAME •n7→ (decor 0n)}

PlainOf == {n:NAME •(decor 0n)7→ n}

114 Chapter 9. Denotational Semantics

State Model. We first define the data state space that is induced by the schema State of the

STATE section of a concrete specification unit. More precisely, each particular model of the

meaning of the Z part induces its specific data state. Accordingly, the entire discussion of the

transformation from the Standard’s semantics to the history semantics is done with respect

to a particular model of the meaning of the considered Z part.

A binding, as usual, is defined as a finite function from identifiers to values.

Binding == NAME 7 7→ W

The set of data states associated with a model Mis the set of bindings that is related to the

dedicated identifier State. The set of initial data states that are related to a model Mare

defined analogously.

StateModel == {M :Model;data state :Binding |State ∈domM ∧ data state ∈ M State}

InitModel == {M :Model;init state :Binding |Init ∈domM ∧ init state ∈ M Init}

Since we assume that the Init schema of each concrete specification unit imports the State

schema, it follows that InitModel(|{M}|)⊆StateModel(|{M}|)for all M:Model.

Furthermore, the set of (undecorated) state variables introduced by the state schema is de-

termined by the domain of the bindings that are the denotation of the schema State.

StateVars == λM:Model |State ∈domM • dom(S(MState))

Operation Model. As discussed in Chapter 7, the OPS & PREDS section must define an op-

eration schema for each identifier in the set OPS.

Each operation schema has a unique identifier and introduces a set of input and output par-

ameters with corresponding types. Hence, an operation application is characterised by the

identifier of the applied operation and the assignment of values to the operation’s input and

output parameters (the transformation of the data state caused by an operation application

is considered separately).

OP APP == NAME ×Binding op name == first[NAME,Binding]

op params == second[NAME,Binding]

The relation OpModel characterises, for each operation schema in OPS, the set of correspond-

ing operation applications (i.e., the assignment of values to the input and output parameters

of the operations) and the set of data state transitions (i.e., the pairs of pre and post states)

they are able to cause. Any model Massociates a set of bindings with each operation schema

op. These bindings contain the state variables of the pre state (in StateVars), the variables

9.2. Concrete Specification Units (Open System View) 115

of the post state (in PrimedStateVars), input variables (in Inputs) and output variables (in

Outputs). A pair of data states is related to a particular assignment of values to input and

output parameters if, and only if, their union is a member of the binding set characterised

by the model.

OpModel == {M :Model;OPS :FNAME;op :NAME;

inout :Binding;delta state :Binding ×Binding |

op ∈OPS ∧OPS ⊆domM ∧

dominout ⊆Inputs ∪Outputs ∧

(∃1pre == delta state.1; post == delta state.2•

dompre =dompost =StateVars M ∧

(∃bind :Mop •bind =pre ∪(post ◦PlainOf)∪inout))

•((M,OPS),(op,inout,delta state))}

More abstractly, each operation schema induces a relation between operation applications,

as defined by OP APP, and data state transitions.

The function AssocSubspace maps each operation op to the subspace of the overall data state

whose components are potentially subject to change when the operation is applied. This sub-

space is needed to formalise the non-interference conditions already presented informally.

AssocSubspace == λM:Model;OPS :FNAME;op :NAME |

op ∈OPS ∧OPS ⊆domM •

StateVars M\{var :StateVars M | ∀ bind :Mop •bind var =bind(PrimedOf var)}

The relation OpSetNonInterference formally specifies the conditions that must be met for a set

of operations OpSet to be applied concurrently with respect to a particular data state current,

which have been informally stated in Section 9.2.1.

Firstly, the subspaces of the data state associated with the operations by the function Assoc-

Subspace must be pairwise disjoint.

Secondly, the order in which the operations of OpSet really cause their corresponding state

transformations must not be relevant for the set of possible final data states and produced

output parameters. More formally, each pair of permutations (perm1,perm2) of operation

applications within OpSet must result in the same set of final data states and produced out-

put parameters. This set must not be empty, ensuring that the operations within OpSet do

not violate the preconditions of each other. The relation OpSeqEffects, which is an auxiliary

definition, associates with each permutation of operation applications the set of final data

states final and produced output parameters ops outpar.

116 Chapter 9. Denotational Semantics

OpSeqEffects == {M :Model;OPS,OpSet :FNAME;current,final :Binding;

ops inpar,ops outpar :NAME 7 7→ Binding;perm :N7 7→ NAME |

domops outpar =OpSet ∧

(∃stseq : 1 . . #OpSet + 1 →Binding •

stseq 1 = current ∧stseq(#OpSet + 1) = final ∧

(∀i: 1 . . #OpSet •

(perm i,ops inpar(perm i)∪ops outpar(perm i),

(stseq i,stseq(i+ 1))) ∈OpModel(|{(M,OPS)}|)))

•(((M,OPS),perm,current,ops inpar,OpSet),(final,ops outpar))}

OpSetNonInterference == {M :Model;OPS :FNAME;current :Binding;

ops inpar :NAME 7 7→ Binding |

∃1OpSet == domops inpar •

(∀op1,op2 : OpSet |op16=op2•

AssocSubspace(M,OPS,op1) ∩AssocSubspace(M,OPS,op2) = ∅)∧

(∀perm1,perm2 : 1 . . #OpSet →OpSet •

OpSeqEffects(|{((M,OPS),perm1,current,ops inpar,OpSet)}|)

=OpSeqEffects(|{((M,OPS),perm2,current,ops inpar,OpSet)}|)

6=∅)

•((M,OPS),(current,ops inpar))}

We have to distinguish between the two approaches to relating events and operations dis-

cussed in Section 6.2. In the single-event approach, each operation application is related to

a single execution event, including the record of the input and output parameter values. In

the double-event approach, an operation application is split into the operation invocation,

including the record of the input parameter values, and the operation termination, including

the record of the output parameter values. The purpose of the set POP APP is to distinguish

between operation invocations, terminations and executions, which we call partial operation

events.

Exec == {1} × OP APP

Invoc == {2} × OP APP

Term == {3} × OP APP

POP APP == Exec ∪Invoc ∪Term

pop name == first[NAME,Binding]◦

second[N,OP APP]

pop params == second[NAME,Binding]◦

second[N,OP APP]

Partial operation events are modelled as tuples, where the first component determines the

kind of event.

The sets Invocations,Terminations and Executions define relations between a model M, an

operation identifier op and the set of all corresponding invocations, terminations and execu-

tions, respectively.

9.2. Concrete Specification Units (Open System View) 117

Invocations == {M :Model;OPS :FNAME;op :NAME;invoc :Binding |

op ∈OPS ∧OPS ⊆domM ∧

dominvoc ⊆Inputs ∧

(∃term,pre,post :Binding •domterm ⊆Outputs ∧

(op,invoc ∪term,(pre,post)) ∈OpModel(|{(M,OPS)}|))

•((M,OPS),(2,(op,invoc)))}

The sets Terminations and Executions are defined analogously and are hence omitted.

History Model. The state-oriented semantics of the Z part of a concrete specification unit,

as outlined in Section 9.2.2, is the set of all possible histories in which the specified artifact

may participate. A history of an artifact at a particular point of its evolution, modelled by

a member of the set History, is characterised by the sequence of partial operation events

it has undergone and the sequence of states it has passed through. In addition, a history

incorporates a component that is derived from the sequence of partial operation events,

namely the corresponding sequence of (complete) operation applications. The derivation of

this additional component is defined later.

Actually, we do not deal with real-time information in the current history model. However,

in order to express the well-formedness conditions of partial operation event sequences in

the following, we need a particular aspect of the timing of events: the information which

partial operation events have occurred simultaneously. The set PartialOpSeq contains all

pairs consisting of a sequence of partial operation events and a relation indicating which of

the events of the sequence have occurred simultaneously.

PartialOpSeq == {events : seq POP APP;simultan :N↔N|

simultan ⊆domevents ×domevents ∧simultan ∈EquivRel[N]∧

(∀i,j:domevents |(i,j)∈simultan • ∀ k:i. . j•(i,k)∈simultan)}

History == PartialOpSeq ×(seq Binding ×seq OP APP)

events of == first[seq POP APP,N↔N]◦first[PartialOpSeq,seq Binding ×seq OP APP]

simultan of == second[seq POP APP,N↔N]◦first[PartialOpSeq,seq Binding ×seq OP APP]

states of == first[seq Binding,seq OP APP]◦second[PartialOpSeq,seq Binding ×seq OP APP]

ops of == second[seq Binding,seq OP APP]◦second[PartialOpSeq,seq Binding ×seq OP APP]

For a sequence of partial operation events to be a consistent record of the invocation, ter-

mination and execution of operations, it must satisfy different well-formedness conditions,

which are introduced in the following. We introduce these well-formedness conditions in

different steps, where each condition includes the conditions of the previous steps.

The first well-formedness condition concerns the relationship between the invocation and

termination of operations within a sequence of partial operation events. Roughly speaking,

an operation can terminate only if it has been invoked before. Formally speaking, for any

prefix of a well-formed sequence, the number of invocations of a particular operation must

be greater than or equal to the number of its terminations. Further, the difference between

118 Chapter 9. Denotational Semantics

the numbers must be lower than or equal to one, because at any time at most one instance

of any operation can be invoked without being terminated. This is a consequence of the fact

that any operation interferes with itself. The set WellFormed1contains all sequences satisfying

this condition at least for the first wf events.

WellFormed1== {M :Model;OPS :FNAME;h:History;wf :N|

∃1events == events of h •

(∀i: 1 . . wf •

events i ∈Invoc ∧events i ∈Invocations(|{(M,OPS)}|)

∨events i ∈Term ∧events i ∈Terminations(|{(M,OPS)}|)

∨events i ∈Exec ∧events i ∈Executions(|{(M,OPS)}|)) ∧

(∀id :OPS;n: 1 . . wf •

0≤#{i: 1 . . n|events i ∈Invoc ∧pop name(events i) = id}−

#{i: 1 . . n|events i ∈Term ∧pop name(events i) = id} ≤ 1)

•((M,OPS),(h,wf))}

The second well-formedness condition deals with the relationship between the sequence of

partial operation events and the corresponding sequence of data states, both being compon-

ents of a history h. First, the state sequence must contain at least one data state, namely the

initial state. Second, each termination/execution event of the component events is related to

a corresponding pair of data states of the states component, so states must have exactly one

member more than the projection of events to termination and execution events.

The function ev to st is introduced to map each event of the component events to the data

state of the component states that is present when the event occurs (more precisely, their

indices are related). The index of the component states by which this data state is determined

depends on the number of termination and execution events that have occurred before.

WellFormed2== {M :Model;OPS :FNAME;h:History;wf :N;ev to st :N7 7→ N|

(h,wf)∈WellFormed1(|{(M,OPS)}|)∧

(∃1events == events of h;states == states of h •

states 6=hi ∧

(∀i:N\ {0} • i+ 1 ∈domstates ⇔i∈dom(events (Term ∪Exec))) ∧

domev to st =domevents ∧

(∀i:domevents •

ev to st i = #{j:domevents |j<i∧events j ∈Term ∪Exec}+ 1))

•((M,OPS),(h,wf,ev to st))}

The third well-formedness condition requires that the ‘non-interference’ conditions are met

by the sequence of partial operation events. For any index of the sequence, the set of currently

invoked or executed operations must satisfy the ‘non-interference’ conditions with respect

to the current data state. The set of currently invoked and executed operations is determined

by the auxiliary function ConcOps.

9.2. Concrete Specification Units (Open System View) 119

ConcOps == λOPS :FNAME;h:History;index :N|index ∈dom(events of h)•

let events == events of h;simultan == simultan of h •

{op :OPS;inpar :Binding |

∃i:domevents |op =pop name(events i)∧inpar =Inputs Cpop params(events i)•

events i ∈Exec ∧(i,index)∈simultan

∨

events i ∈Invoc ∧(i<index ∨(i,index)∈simultan)∧

¬(∃j:domevents |events j ∈Term ∧pop name(events j) = op •

i<j∧j<index ∧(j,index)/∈simultan)}

WellFormed3== {M :Model;OPS :FNAME;h:History;wf :N;ev to st :N7 7→ N|

∃1events == events of h;simultan == simultan of h;states == states of h •

(h,wf,ev to st)∈WellFormed2(|{(M,OPS)}|)∧

(∀i: 1 . . wf •

(states(ev to st i),ConcOps(OPS,h,i)) ∈OpSetNonInterference(|{(M,OPS)}|))

•((M,OPS),(h,wf,ev to st))}

A sequence of partial operation events that is not well-formed models the divergence of

the specified artifact, i.e., an arbitrary behaviour. We distinguish between two parts of a

sequence: an initial part, which is well-formed, and the remaining part (possibly empty),

which is divergent. In the above definitions, wf is an index expressing that the corresponding

sequence is well-formed at least for the first wf events. In the following, we are interested

only in the maximal values of this index.

MaxWellFormed == {M :Model;OPS :FNAME;h:History;max wf :N;

ev to st :N7 7→ N|

(h,max wf,ev to st)∈WellFormed3(|{(M,OPS)}|)∧

(∀n:N|(h,n,ev to st)∈WellFormed3(|{(M,OPS)}|)•n≤max wf)

•((M,OPS),(h,max wf,ev to st))}

The aim of the subsequent relation InvTermComb is to determine the sequence of (complete)

operation applications (operations) that corresponds to a given sequence of partial operation

events (events), i.e., to define the required relationship between the corresponding compon-

ents of a history h.

120 Chapter 9. Denotational Semantics

InvTermComb == {M :Model;OPS :FNAME;h:History;max wf :N;ev to st :N7 7→ N|

(h,max wf,ev to st)∈MaxWellFormed(|{(M,OPS)}|)∧

(∃1events == events of h;operations == ops of h •

domoperations = 1 . . #{i: 1 . . max wf |events i ∈Term ∪Exec} ∧

(∃1term exec of :domoperations domevents |

(∀i,j:domoperations |i<j•term exec of i <term exec of j)∧

ranterm exec of ={i: 1 . . max wf |events i ∈Term ∪Exec} •

(∀i:domoperations •

events(term exec of i)∈Term ∧

op name(operations i) = pop name(events(term exec of i)) ∧

(∃1invoc == max{j:domevents |j<term exec of i ∧

events j ∈Invoc ∧pop name(events j) = op name(operations i)} •

op params(operations i) =

pop params(events(term exec of i)) ∪pop params(events invoc))

∨

events(term exec of i)∈Exec ∧

op name(operations i) = pop name(events(term exec of i)) ∧

op params(operations i) = pop params(events(term exec of i)))))

•((M,OPS),(h,max wf,ev to st))}

Each (complete) operation application of operations is composed either of an invocation and

the corresponding termination event or of a single execution event of events. Since an oper-

ation application is completed only with the occurrence of the termination/execution event,

each operation application in operations is identified with its corresponding termination/exe-

cution event of events by means of the injective, monotone function term exec of. The pairing

of corresponding invocation and termination events is done only for the well-formed part

of the sequence (1. . max wf). This is important because the derivation of the possible data

state evolutions in later definitions are based on the sequence of (complete) operation ap-

plications.

The set Histories relates each model Mof the meaning of the Z part of a concrete specification

unit to the set of histories of the specified artifact. The component events of a history records

operation invocations, terminations and executions. The derived component operations is the

sequence of operation applications resulting from the combination of corresponding invo-

cation and termination events of the former component, as defined by the previous relation.

9.2. Concrete Specification Units (Open System View) 121

Histories == {M :Model;OPS :FNAME;h:History |

∃1events == events of h;states == states of h;operations == ops of h;

max wf :N;ev to st :N7 7→ N|

(h,max wf,ev to st)∈InvTermComb(|{(M,OPS)}|)•

(∀i:domoperations ∪ {0} • states(i+ 1) ∈StateModel(|{M}|)) ∧

states 1∈InitModel(|{M}|)∧

(∀i: 1 . . max wf |events i ∈Invoc ∪Exec •

(∃post,out :Binding |domout ⊆Outputs •

(pop name(events i),(Inputs Cpop params(events i)) ∪out,

(states(ev to st i),post)) ∈OpModel(|{(M,OPS)}|))) ∧

(∀i:domoperations •

(op name(operations i),op params(operations i),

(states i,states (i+ 1))) ∈OpModel(|{(M,OPS)}|))

•((M,OPS),h)}

A tuple consisting of a sequence of partial operation events (events), a sequence of data states

(states) and a sequence of operation applications (operations) is related to a model Munder

the following conditions. First, all data states in the well-formed part of the states sequence

must satisfy the state invariant, and the first data state must additionally fulfil the initial

state predicate. Second, for any invocation or execution event in events, the data state in

states that is present when the event occurs (determined with the help of ev to st) must

satisfy the precondition of the corresponding operation schema.3Third, for each operation

application in operations, the state pair that is constituted by the data state that is present

before the termination/execution event occurs and the data state that is the result of the

termination/execution must be a member of the operation model, i.e., be related by the

corresponding operation schema.

Note, again, that the sequence of partial operation events of a history needs not be com-

pletely well-formed; the evolution of the data state corresponding to the diverging part of

such a sequence is arbitrary. This is a consequence of the definition of InvTermComb, in

which only the well-formed part of a sequence of partial operation events is used to build

the corresponding sequence of operation applications. Only the latter sequence is the basis

for expressing constraints on the data state evolution in the set Histories.

Finally, the relation PreHist relates two histories if, and only if, the first is a prefix of the

second one (component-wise).

PreHist == {h1,h2 : History |

events of h1prefix events of h2∧

states of h1prefix states of h2∧

simultan of h1 = (simultan of h2) ∩(dom(events of h1) ×dom(events of h1))}

For each pair of histories (h1,h2) ∈PreHist,h1is called a pre-history of h2.

3Note that this condition is necessary in addition to the last condition, because the data state present when an

execution or invocation event occurs needs not be identical to the data state to which the operation is applied.

122 Chapter 9. Denotational Semantics

This completes the description of the history model, which is depicted in Figure 9.4 by the

rectangle with the corresponding name.

9.2.4 Extended Timed Failures Model (ETFM)

The purpose of the extended timed failures model, which is depicted in Figure 9.4 by the

rectangle in the centre, is

•to define the constituents (notions) of the timed failures model within ZF set theory,

•to extend the syntax of timed CSP in order to accommodate the needs of the CSP part

in the context of the Z definitions within a concrete specification unit and

•to define the semantics of the extended syntax based on the denotational semantics of

timed CSP as given in [Schneider, 1999b].

We base RT-Z on the finite timed failures model, because it is not reasonable to deal with

infinite evolutions of the data state: there is simply no possibility to characterise the data

state of the artifact under consideration after an infinite sequence of operation applications

has occurred. As a consequence, we deal only with finite timed observations (timed traces).

Time Domain

The time domain of timed CSP processes are the positive real numbers. Although real

numbers are not primitive objects of ZF set theory, it is well-known (c.f. [Hamilton, 1982,

Chapter 1]) how to construct Rfrom Nvia Zand Q. First, the natural numbers are defined

by virtue of the ZF axioms to be specific kinds of sets, and it is shown that these “abstract

natural numbers” satisfy all required laws (e.g., Peano axioms). Then, integers are defined

as equivalence classes over pairs of natural numbers with identical difference, rational num-

bers are defined as equivalence classes over pairs of integers with identical quotient, and

real numbers are defined as equivalence classes over Cauchy sequences of rational numbers

converging at the identical limit. In [Hamilton, 1982] it is demonstrated that real numbers

constructed in this way exhibit all required properties, and it is shown how to define the

basic constants, relations and functions on real numbers on the grounds of rational numbers

and limits of Cauchy sequences. We assume in the following that the tuple (R,0R,1R,+R,

∗R,<R) is defined accordingly within ZF set theory.

The Z part of each RT-Z specification unit is based on the Z section Reals, which is depicted

in Figure 9.5, via the parent relationship of Standard Z. That is, the section Reals is an im-

plicit prelude for the Z part of any RT-Z specification unit (analogously to the mathematical

toolkit). Actually, this prelude introduces only the symbols of the carrier set, its elements,

its functions and its relation without any definition. The mapping of these symbols to the

corresponding entities of the semantic universe (R,0R,1R,+R,∗R,<R) is fixed only on

the semantic level of RT-Z: the models of the Z part taken into account when computing the

meaning of an RT-Z specification unit are restricted to those that map the above symbols

to the intended entities of the semantic universe. This is reflected by the definition of the

semantic functions timed failures statesC[[ ]] and timed failures statesA[[ ]] on pp. 145 and 147,

9.2. Concrete Specification Units (Open System View) 123

section Reals

[R]

0R,1R:R

+R,∗R:R×R→R

<R:R↔R

>R:R↔R

⩽R:R↔R

⩾R:R↔R

−R:R×R→R

inf : P R →R

sup : P R →R

(∀x,y,z:R•

x>Ry⇔y<Rx∧

x⩽Ry⇔ ¬ y<Rx∧

x⩾Ry⇔ ¬ x<Ry∧

x−Ry=z⇔z+Ry=x)

∀S:P R;x:R•inf S=x⇔

(∀y:S•x⩽Ry)∧(∀z:R|(∀y:S•z⩽Ry)•z⩽Rx)

∀S:P R;x:R•sup S=x⇔

(∀y:S•y⩽Rx)∧(∀z:R|(∀y:S•y⩽Rz)•x⩽Rz)

Figure 9.5: Z section Reals.

where only a subset of the models of the meaning of the Z part are taken into consideration.

The following expression is only a definition fragment used to illustrate the above statement.

. . . M: [[ . . . ]]Z|

. . .

{R,0R,1R,+R,∗R, <R} ⊆ domM ∧

MR=R ∧ M 0R= 0R∧. . .

. . .

Based on these considerations, the time domain of RT-Z is defined to be the positive real

numbers including zero.

T== {x:R | ¬ x<R0R}

T+== {x:R | 0R<Rx}

Constituents

In the remainder of this chapter, we use functions and relations working on objects of the

timed failures model introduced in [Schneider, 1999b]. They are explained in Appendix E.

124 Chapter 9. Denotational Semantics

In RT-Z specifications, we have to distinguish between two different kinds of events. The

first kind of events, which we call operation-related events, are related to the invocation, ter-

mination and execution of operations. The values transmitted by these events are the values

of input and output parameters. The second kind of events are called plain events and con-

cern the internal and external synchronisation and communication. These events are pairs

of channel identifiers and communicated values, too. The set ChannelValue encompasses all

values that can be communicated along channels, either parameters of an operation invo-

cation, termination or execution or arbitrary values of plain events.4

ChannelValue == W

Let the functions InvOf,TermOf and ExecOf map each operation identifier to the identifier

of the channel carrying the corresponding invocation, termination and execution events,

respectively. The set ORC (abbreviates ’operation-related channels‘) encompasses all identi-

fiers of channels carrying operation-related events.

ORC == ranInvOf ∪ranTermOf ∪ranExecOf

An event is a pair of a channel identifier (CHANNEL) and a communicated value (Channel-

Value). According to the semantic models of CSP, a trace is a finite sequence of events, a

refusal is a set of events, and a failure is a pair consisting of a trace and a refusal, where the

observed process has engaged in the events recorded in the trace and is subsequently able to

deadlock if the environment is willing to offer only the events contained in the refusal set.

Event == CHANNEL ×ChannelValue chan of == first[CHANNEL,ChannelValue]

val of == second[CHANNEL,ChannelValue]

Trace == {s: seq Event | ∀ i: 1 . . #s−1•s i 6=X}

Refusal == PEvent

Failure == Trace ×Refusal

According to the timed failures model of timed CSP [Schneider, 1999b], a timed event is

a pair consisting of an event and the time instant it is observed. A timed trace is a finite

or infinite sequence of timed events subject to the following conditions. The sequence of

timed events recorded in a timed trace must be ordered in time, the termination event (X) is

allowed to appear only as the last event in a finite timed trace and any infinite trace must not

4This is a place where we must “circumvent” the type system of Z: the values communicated with operation-

related events are bindings, which in the untyped ZF set theory can be required to be contained in W. This is

not possible in the strongly typed Z notation. We have circumvented the Z type system by means of invisible

(in L

EX) conversion functions.

9.2. Concrete Specification Units (Open System View) 125

be bounded in time, which is dictated by the principle of finite variability.5In the context of

the finite timed failures model, however, we consider only finite timed traces.

TimedEvent == T×Event time of == first[T,Event]

ev of == second[T,Event]

TimedTrace == {s: seq∞[TimedEvent]|

(∀i,j:doms|i<j•time of(s i)⩽Rtime of(s j)) ∧

(∃n:N•doms= 1 . . n)∧

X/∈ {i: 1 . . #s−1•ev of(s i)}

∨doms=N∧

(∀t:T• ∃ t∗:T;e:Event |t<Rt∗•(t∗,e)∈rans)∧

X/∈ {i:N•ev of(s i)}}

To define the concept of a timed refusal, we need the set HalfOpenInterval, containing all

bounded half-open intervals of time instants, the set RefusalToken, containing all pairs of

time intervals and event sets, and the set FinRefusalTokenSet, which contains all unions of a

finite number of refusal tokens. Using these sets, a timed refusal is defined to be a set of

timed events such that its restriction to any finite interval is a member of FinRefusalTokenSet,

which is again dictated by the principle of finite variability.

HalfOpenInterval == {TI :P T | ∃ b,e:T|0R⩽Rb∧b<Re•TI ={t:T|b⩽Rt∧t<Re}}

RefusalToken == {S:PTimedEvent | ∃ I:HalfOpenInterval;A:PEvent •S=I×A}

FinRefusalTokenSet == {tref :PTimedEvent | ∃ C:FRefusalToken •tref =SC}

TimedRefusal == {tref :PTimedEvent | ∀ t:T•

{t0:T;e:Event |(t0,e)∈tref ∧t0<Rt} ∈ FinRefusalTokenSet}

A timed failure is a pair of a timed trace and a timed refusal.

TimedFailure == TimedTrace ×TimedRefusal

In Section A.2, we discuss in detail the properties TF1–TF3 that a set of timed failures must

meet in order to represent some timed CSP process. To understand the following definition

of the set TimedFailuresModel, which encompasses all sets of timed failures that satisfy these

conditions, read the informal explanation on p. 249.

5The principle of finite variability requires a process to undergo only finitely many changes in any finite time

interval.

126 Chapter 9. Denotational Semantics

TimedFailuresModel == {S:PTimedFailure |

(hi,∅)∈S

(TF1)

∧

(∀s,s0:TimedTrace;ℵ,ℵ0:TimedRefusal •

(s,ℵ)∈S∧(s0,ℵ0)(s,ℵ)⇒(s0,ℵ0)∈S)

(TF2)

∧

(∀s:TimedTrace;ℵ:TimedRefusal |(s,ℵ)∈S•

(TF3)

(∃ ℵ0:TimedRefusal | ℵ ⊆ ℵ0∧(s,ℵ0)∈S•

(∀t:T;a:Event •

((t,a)/∈ ℵ0⇒((sttr t)ah(t,a)i,ℵ0|tref t)∈S)(C1)

∧

t>R0R∧ ¬ (∃:T+• {t∗:T|t−R⩽Rt∗∧t∗<Rt}×{a} ⊆ ℵ0)

⇒((s|ttr t)ah(t,a)i,ℵ0|tref t)∈S)))}(C2)

The relation occurring in the above definition represents the information order on timed

failures.

== {s,s0:TimedTrace;ℵ,ℵ0:TimedRefusal |s0∈FinTimedTrace ∧

(∃s2 : TimedTrace •s=s0as2∧ ℵ0⊆ ℵ |tref beginttr(s2))

•((s0,ℵ0),(s,ℵ))}

The timed trace component s0of the first timed failure must be a prefix of the timed trace

component sof the second one, and its timed refusal component ℵ0may contain only refusal

information also present in the timed refusal component ℵof the second timed failure up to

the time instant at which sextends s0.

Extended Timed Failures Semantics of Z Specifications

As discussed, the main idea underlying the semantic integration of Z and timed CSP is to

give a Z specification a timed failures semantics. This allows us to regard the Z part and

the CSP part of a concrete specification unit as two parallel processes. The first step towards

this goal, achieved in Section 9.2.3, was to associate a set of histories with each model of the

meaning of a Z specification. The second step, which is the subject of the current section,

is to translate the concept of a history into the concepts of (untimed) CSP, namely traces,

refusals and failures.

We first need to define the auxiliary function ev of op. It maps an operation application to

the corresponding event. An operation application, as recorded in a history, corresponds to

an event if its operation identifier translates into the channel identifier of the event and if

the values transmitted with the operation application and the event occurrence are identical,

each embedded in the respective context.

9.2. Concrete Specification Units (Open System View) 127

ev of op == λop :POP APP •

let chan == (if op ∈Invoc then InvOf(pop name op)

else if op ∈Term then TermOf(pop name op)

else ExecOf(pop name op)) •

(chan,(pop params op))

The functions InvOf,TermOf and ExecOf map each operation identifier to the identifier of

the channel carrying the corresponding event; they have been introduced on p. 124.

The function tracesZmaps histories of the Z part to corresponding traces of operation-related

events, which represent possible observations of the CSP interpretation of the Z part. Basic-

ally, a trace is mapped to a history if it corresponds to the sequence of partial operation

events contained in the history. Both the trace and the history event sequence must have

the same length, and for each index of the sequence the operation application and the trace

event must be related by ev of op.

tracesZ== λh:History •(λi:dom(events of h)•ev of op((events of h)i))

Failures of operation-related events, which represent possible observations of the CSP inter-

pretation of the Z part, and histories of the Z part are related by failuresZ. The trace com-

ponent tr of these failures is determined by tracesZ. Regarding the refusals ref related to a

particular trace tr there are two reasons for the membership of an operation-related event e

in ref.

The first reason for the refusal of the event eis that the modelled artifact is not able to

perform eafter having performed the operation-related events in tr. The inability to per-

form an operation-related event corresponds to the inability of the modelled artifact to in-

voke/execute this operation if the operation’s precondition is not satisfied with respect to

the current data state. Technically speaking, an event cannot be performed after a particu-

lar trace has been observed if the concatenation of this trace and the event is not a possible

observation of any history of which the considered history is a pre-history.

The other reason for an operation-related event eto be a member of ref (to be refused) is that

there is another operation-related event e0that is not a member of ref (not refused) and that

is related to esuch that both events represent the termination or execution of the same oper-

ation. If they represent the execution of an operation, then they must assign the same values

to the input parameters of this operation. The background of this second alternative is our

decision that the Z part chooses the values of the output parameters nondeterministically;

they are constrained only by the definition of the Z operation schema. Therefore, given a set

of valid assignments of values to the output parameters of an operation, the Z part must be

free to refuse all but one assignment.

128 Chapter 9. Denotational Semantics

failuresZ== {h:History;hset :PHistory;fail :Failure |

∃1tr == fail.1; ref == fail.2•

tr =tracesZh∧

(∀e:ref •

tr ahei/∈ {ext :hset |(h,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |e0/∈ref •chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C((val of e)) = Inputs C((val of e0)))))

•((h,hset),fail)}

Note that we need the set of all histories hset that are possible observations of the specified

artifact in order to define the failures corresponding to a history h, because the refusal infor-

mation refers to the inability to expand the considered history hby another valid history.

Timed failures of operation-related events, which represent possible timed observations of

the timed CSP interpretation of the Z part, and histories of the Z part are related by the set

timed failuresZ. To understand the association of timed failures with histories, it is import-

ant to realise that the Z part does not fix any time aspects of the occurrence or refusal of

operation-related events. A (finite) timed failure is related to a history hunder the following

conditions. First, the (untimed) trace that is obtained by ignoring the time information of

the timed trace component must be mapped to hby tracesZ. Second, considering an arbit-

rary time instant t, the set of events refused at that time instant (member of the timed refusal)

must be a refusal associated with the (untimed) trace that is obtained by restricting the timed

trace to the interval ending at time instant t(inclusive) and subsequently ignoring the time

information.

timed failuresZ== {h:History;hset :PHistory;tf :TimedFailure |

∃1s== tf.1; ℵ== tf.2; simultan == simultan of h •

(∀i,j:N|(i,j)∈simultan •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T•

(∃1tr == strip(sttr t); ref == {e:Event |(t,e)∈ ℵ} •

∃prefix :hset |(prefix,h)∈PreHist •

(tr,ref)∈failuresZ(|{(prefix,hset)}|)))

•((h,hset),tf)}

The time information contained in the timed trace component smust be consistent with

the information of the component simultan of the history hconcerning the simultaneity of

operation-related events.

In Appendix B, we prove that the above definitions really map each Z specification to a

timed CSP process, i.e., to a set of timed failures satisfying the properties of the timed failures

model as defined on p. 126.

9.2. Concrete Specification Units (Open System View) 129

Process Term Language

According to the description in Chapter 7, the syntax of the CSP part of concrete specification

units slightly extends the syntax of timed CSP processes in order to incorporate the following

adaptations.

•Each application of the channel input operator (c?(x:S)→P(x)) is parametrised by a

Z set expression S, which is evaluated in the context of the Z part.

•Each instance of the channel output operator (c!v→P) is parametrised by a Z value

expression v, which is evaluated in the context of the Z part.

•The index sets used as parameters of the indexed nondeterministic choice (uid∈S), in-

terleaving (|||id∈S) and synchronised parallel (kid∈S) operators are evaluated in the con-

text of the Z part.

•The real-time operators of timed CSP (timeout (.{t}), timed interrupt (4t) and delay

(Wait t)) have time parameters whose values are evaluated in the context of the Z part.

Let ETCSP PROCESS denote the set of extended process terms as specified by the syntax

definition in Appendix D.

Process terms in the BEHAVIOUR section of concrete specification units can refer to arbitrary

channel identifiers declared in the LOCAL and INTERFACE sections, and they can contain

arbitrary time, value and set expressions, which are interpreted in the context of the corres-

ponding Z part. The CSP definitions of concrete specification units can hence be interpreted

only in the context of three pieces of information:

•The assignment of value domains to those channel identifiers to which the CSP defi-

nitions refer. Such an assignment is characterised by a member of ChanSgn.

•The assignment of values to the value, set and time expressions to which the CSP

definitions refer. Such an assignment is determined by a model, being a member of

the denotation of the corresponding Z part.

•The assignment of timed CSP expressions to free process variables occurring in the

process terms. Such an assignment is a member of ProcEnv.

The semantic function of the extended timed failures model for process terms has the fol-

lowing signature.

timed failuresETCSP [[ ]] : ETCSP PROCESS ×(ProcEnv ×(Model ×Model)×ChanSgn)→

TimedFailuresModel

There is a pair of parameters of type Model for the following reason. Some process operators,

e.g., channel input, update the information that is available for evaluating Z expressions. The

channel input operator binds the communicated value to its variable, to which Z expressions

in the subsequent process expression can refer. The current information used to evaluate Z

expressions—including variable bindings—is recorded in the first parameter of the pair.

The scope in which variable bindings are visible is limited. In the process expression,

130 Chapter 9. Denotational Semantics

Pb=c?x:S→d!x→Q

e.g., the variable x, bound by the communication on the channel c, can be referred to only in

the process expression subsequent to the channel input: it can be referred to in the channel

output but it cannot be used in order to evaluate the process term Q. Variables are visible

only in the process term in which they are bound. Whenever a process is instantiated, all

variable bindings are discarded. That is, all processes are evaluated with respect to the iden-

tical model, which encodes the information of the Z part without containing any variable

bindings. This model is called the initial model, and it is the second parameter of the pair.

The definition of the semantic function timed failuresETCSP is based on the semantic function

of the timed failures model, which we define in Section A.2. In the following, we provide the

definitions of the extended/adapted operators. The meaning of these operators is defined

in the form

timed failuresETCSP [[ P(par1, . . . , parN) ]](Env,(M,MI),IL)=. . .

where the triple (Env,(M,MI),IL)contains the underlying information of the Z part and

the INTERFACE and LOCAL sections needed to interpret the process definition and where

par1, . . . , parN are simple parameters of the process definition, e.g., the channel name of the

prefix operator or the index set of the indexed nondeterministic choice.

Channel Input Operator: The channel input operator chan?(var :Set)→Phas three param-

eters: the channel identifier chan, the identifier var, to which the value that is transmit-

ted with the event occurrence is bound, and the set expression Set, which restricts the

set of values that can be communicated with the event occurrence.

The denotation assigned to the channel input operator is split into three subsets. The

first subset deals with an inconsistent use of the parameters: either the channel iden-

tifier is not declared as an external or internal channel or the set associated with the

expression Set is not a subset of the set associated with the considered channel by the

channel declaration. In these cases, the semantics refrains from defining the meaning

of the operator: it just allows an arbitrary behaviour.

The second and third subsets reflect, in essence, the definition of the channel input

operator in timed CSP. The second subset addresses the case that the initial event has

already occurred, while the third subset addresses the case that this initial event is still

awaited.

timed failuresETCSP [[ chan?(var :Set)→P]](Env,(M,MI),IL)=

{tf :TimedFailure |chan /∈domIL ∨chan ∈domIL ∧

¬[[ Set ]]M ⊆ [[ IL chan ]]M}

∪{s:TimedTrace;ℵ:TimedRefusal;t:T;val :W|

chan ∈domIL ∧[[ Set ]]M ⊆ [[ IL chan ]]M ∧ val ∈( [[ Set ]]M)∧

(s,ℵ)˙

−tfail t∈timed failuresETCSP [[ P]](Env,(M⊕{var7→val},MI),IL)

•(h(t,(chan,val))ias,ℵ)}

∪{ℵ :TimedRefusal |chan ∈domIL ∧[[ Set ]]M ⊆ [[ IL chan ]]M ∧

{t:T;val :W|val ∈[[ Set ]]M • (t,(chan,val))}∩ℵ=∅

•(hi,ℵ)}

9.2. Concrete Specification Units (Open System View) 131

In the definition of the second subset, it is first required that all parameters are used in

a consistent way. The data value val transmitted with the event occurrence must be a

member of the set associated with the expression Set by the Z part, and the value val

is bound to the variable var. This procedure of binding the chosen value to the vari-

able is reflected in the definition of the model used to interpret the remaining process

expression P: the original model Mis updated with the pair var 7→ val of the variable

and the transmitted value.

Channel Output Operator: Again, the denotation of the channel output operator chan!val →

Pis split into three subsets, where the structure is identical to the case of the channel

input operator above. The substantial difference is the treatment of the value val to be

transmitted: since it is now the considered process that determines the concrete value

transmitted along the respective channel, the remaining process Pdoes not depend on

this value and thus the model used to interpret Pneed not be updated like in the above

case.

timed failuresETCSP [[ chan!val →P]](Env,(M,MI),IL)=

{tf :TimedFailure |chan /∈domIL ∨chan ∈domIL ∧

( [[ val ]]M)/∈[[ IL chan ]]M}

∪{s:TimedTrace;ℵ:TimedRefusal;t:T|

chan ∈domIL ∧( [[ val ]]M)∈[[ IL chan ]]M ∧

(s,ℵ)˙

−tfail t∈timed failuresETCSP [[ P]](Env,(M,MI),IL)

•(h(t,(chan,( [[ val ]]M)))ias,ℵ)}

∪{ℵ :TimedRefusal |chan ∈domIL ∧( [[ val ]]M)∈[[ IL chan ]]M ∧

{t:T•(t,(chan,( [[ val ]]M)))}∩ℵ=∅

•(hi,ℵ)}

Indexed Nondeterministic Choice: The index set expression Sof an indexed nondetermin-

istic choice uid∈Sis interpreted in the context of the Z part.

The definition of the meaning of this operator is divided into two subsets. The first

subset addresses the inconsistent use of the index set parameter, in which the Z part

assigns the empty set to the index set parameter.

The second subset deals with the consistent case. An arbitrary index jis chosen from

the index set assigned to the expression Sby the considered model M, and the par-

ametrised process P(i)is interpreted with parameter isubstituted by index j, which is

modelled by updating the model Mwith the pair i7→ j.

timed failuresETCSP [[ ui∈SP(i) ]](Env,(M,MI),IL)=

{tf :TimedFailure |( [[ S]]M) = ∅}

∪

{tf :TimedFailure | ∃ j: ( [[ S]]M)•

tf ∈timed failuresETCSP [[ P(i) ]](Env,(M⊕{i7→j},MI),IL)}

Indexed Interleaving: Analogously to the indexed nondeterministic choice operator, the in-

dexed interleaving operator |||id∈Shas an index set parameter, which is interpreted in

132 Chapter 9. Denotational Semantics

the context of the Z part. According to the laws of timed CSP, this set must be finite.

Then, the commutativity and associativity of the binary interleaving operator justify

the following definition.

timed failuresETCSP [[ |||i∈SP(i) ]](Env,(M,MI),IL)=

let IS == ( [[ S]]M)•

{tf :TimedFailure |IS /∈F W}

∪

{tf :TimedFailure |IS ∈F W ∧tf ∈(rec interleave [[ P(i) ]](Env,M,IL))IS}

The first subset addresses the inconsistent case, in which the index set expression is

evaluated to an infinite set, while the second subset deals with the consistent case by

referring to the function rec interleave. This function is defined recursively with respect

to the index set IS. The function rec interleave, applied to the set of index values IS,

yields the inductively computed interleaving of the processes P(i)for i∈IS, where IS

must be finite. Note the difference between the parameter Sof the above and IS of the

following definition: Sis a Z expression whereas IS is the corresponding evaluated set

of index values; while we cannot define a recursive function based on Z expressions,

there is an induction principle for finite sets.

rec interleave [[ P(i) ]](Env,M,IL)=λIS :P W •

{tf :TimedFailure |IS =∅∧tf ∈timed failuresETCSP [[ Skip ]](Env,(M,M),IL)}

∪

{s,s1,s2 : TimedTrace;ℵ1,ℵ2 : TimedRefusal |

IS 6=∅∧(∃j:IS •

(s1,ℵ1) ∈timed failuresETCSP [[ P(i) ]](Env,(M⊕{i7→j},M),IL)∧

(s2,ℵ2) ∈(rec interleave [[ P(i) ]](Env,M,IL))(IS \ {j})) ∧

(s1,s2) interleaves s∧

ℵ1\(T× {X}) = ℵ2\(T× {X})

•(s,ℵ1∪ ℵ2)}

The first subset deals with the induction base—the empty set—where the indexed in-

terleaving process represents just the terminating process Skip.

Accordingly, the second subset deals with the induction step. An index jis arbitrarily

chosen from the non-empty set IS, and the process characterised by this index is com-

posed with the indexed interleaving process that is obtained by deleting the chosen

index from IS. The meaning of the latter process is determined by a recursive ap-

plication of the function rec interleave. The timed failures (s1,ℵ1) and (s2,ℵ2), being

denotations of the derived processes, are combined to the timed failure (s,ℵ1∪ ℵ2) of

the whole process, which reflects the definition of the binary interleaving operator in

timed CSP.

Indexed Parallel: The indexed (synchronised) parallel operator is defined analogously to the

indexed interleaving operator.

9.2. Concrete Specification Units (Open System View) 133

timed failuresETCSP [[ ki∈S[A]P(i) ]](Env,(M,MI),IL)=

let IS == ( [[ S]]M)•

{tf :TimedFailure |IS /∈F W}

∪

{tf :TimedFailure |IS ∈F W ∧tf ∈(rec parallel [[ (P(i),A) ]](Env,M,IL))IS}

The only difference is the way in which the denotations of the derived processes are

combined in the second subset of the recursive function rec parallel, which reflects the

induction step.

rec parallel [[ (P(i),A) ]](Env,M,IL)=λIS :P W •

{tf :TimedFailure |IS =∅∧tf ∈timed failuresETCSP [[ Skip ]](Env,(M,M),IL)}

∪

{s,s1,s2 : TimedTrace;ℵ1,ℵ2 : TimedRefusal |

IS 6=∅∧(∃j:IS •

(s1,ℵ1) ∈timed failuresETCSP [[ P(i) ]](Env,(M⊕{i7→j},M),IL)∧

(s2,ℵ2) ∈(rec parallel [[ (P(i),A) ]](Env,M,IL))(IS \ {j})) ∧

(∃1EvSet == [[ A]]

α(M,IL)•

((s1,s2),EvSet) synch s∧

ℵ1\(T×(EvSet ∪ {X})) = ℵ2\(T×(EvSet ∪ {X})))

•(s,ℵ1∪ ℵ2)}

Note also the evaluation of the alphabet expression Aby means of the semantic func-

tion [[ ]]

α, which is defined in the next section.

Predicate Language

Let us now address the other fragment of the extended timed CSP notation: the predicate

language of the extended timed failures model.

Predicates of the extended timed failures model are used in concrete and abstract specifi-

cation units to express environmental assumptions and/or to define requirements on the

dynamic behaviour. Each predicate is interpreted in the context of a model M, reflecting the

definitions of the Z part, and a channel signature IL, reflecting the channel declarations of

the INTERFACE and LOCAL sections; and it induces a relation between timed traces sand

timed refusals ℵ.

The semantic function for predicates of the extended timed failures model has thus the fol-

lowing signature:

timed failuresETFM [[ ]] : ETFM PREDICATE ×(Model ×ChanSgn)→PTimedFailure

We define the semantic function timed failuresETFM in terms of the function [[ ]]P

ETFM , which is

defined in the following. Both functions evaluate predicates of the extended timed failures

model. The difference between them is that the latter function does not take into account

the information contained in the INTERFACE and LOCAL sections. That is, it ignores that

134 Chapter 9. Denotational Semantics

the data values communicated with the occurrence of events on particular channels must

be members of the value domains associated with these channels. To address this further

requirement is the purpose of the semantic function timed failuresETFM:

timed failuresETFM [[ Pred ]](M,IL)={s:TimedTrace;ℵ:TimedRefusal |

((s,ℵ),M,IL)∈[[ Pred ]]P

ETFM ∧

∀i:doms•

chan of(ev of(s i)) ∈domIL ∧

val of(ev of(s i)) ∈[[ IL(chan of(ev of(s i))) ]]M}

It has proved to be convenient to decouple the two functions for reasons of separation of

concerns.

Syntax. We define the semantics of the “core” of the predicate language, containing all

those predicates in terms of which all other predicates can be expressed equivalently. Thus,

the process of computing the meaning of a predicate is divided into two phases. In the first

phase, the predicate is transformed into an equivalent “core” predicate (by using transform-

ation rules, which we do not completely treat in this thesis). In the second phase, the “core”

predicate is associated with a meaning according to the semantic function to be defined in

the following. This approach follows the one taken in the Z Standard [ISO, 2002], which also

defines transformation rules between equivalent Z terms and semantic functions only for

the “core” language.

The syntax of the predicate language is formally defined in Appendix D. The predicate

language provides the usual logical connectives (∧,∨,¬,⇒,⇔). Its atomic predicates

include all those provided by the predicate language of the (original) timed failures model

[Schneider, 1999b], which allow one to make statements about the timed trace and timed

refusal components sand ℵ. They make use of the various functions on timed traces and

timed refusals as defined by Schneider [1999b] and described in Appendix E.

Our extensions to the predicate language of the timed failures model concern two aspects.

First, we introduce references to Z schemas, say Prop,

Prop(v1b=expr1, . . . , vN b=exprN)

as additional atomic predicates. They allow us to specify relationships between data values

communicated along particular channels with particular events. Second, we add to our

predicate language universal and existential quantifications

∀v:S•Pred ∃v:S•Pred

over arbitrary set expressions S, evaluated in the context of the Z part. Both extensions

establish relationships between the model component Mand the timed failure component

(s,ℵ).

Semantics. The semantic function [[ ]]P

ETFM associates each predicate of the extended

timed failures model with its characterising set of timed failures (s,ℵ), models Mand chan-

nel signatures IL.

9.2. Concrete Specification Units (Open System View) 135

[[ ]]P

ETFM :ETFM PREDICATE →P(TimedFailure ×Model ×ChanSgn)

Logical Connectives.

[[ Pred1∧Pred2 ]]P

ETFM = [[ Pred1 ]]P

ETFM ∩[[ Pred2 ]]P

ETFM

[[ Pred1∨Pred2 ]]P

ETFM = [[ Pred1 ]]P

ETFM ∪[[ Pred2 ]]P

ETFM

[[ ¬Pred ]]P

ETFM = (TimedFailure ×Model ×ChanSgn)\[[ Pred ]]P

ETFM

[[ Pred1⇒Pred2 ]]P

ETFM = [[ ¬Pred1∨Pred2 ]]P

ETFM

[[ Pred1⇔Pred2 ]]P

ETFM = [[ Pred1∧Pred2∨ ¬ Pred1∧ ¬ Pred2 ]]P

ETFM

Universal Quantification. The predicate language of the ETFM allows us to introduce bound

variables var universally quantified over arbitrary Z set expressions S. The set of values de-

noted by the Z expression Sis computed with respect to a particular model Mof the mean-

ing of the Z part by using the semantic function for Z expressions [[ ]]defined by the Z

Standard.

[[ ∀var :S•Pred ]]P

ETFM =S{M :Model •T{val : [[ S]]M •

{tf :TimedFailure;IL :ChanSgn |(tf,M⊕{var 7→ val},IL)∈[[ Pred ]]P

ETFM •(tf,M,IL)}}}

Only those timed failures tf, models Mand channel signatures IL are part of the denota-

tion of the universal quantification that can be successfully extended by all values val of the

denotation of the set expression S; this is reflected by the distributed intersection operator

Existential Quantification. Existential quantification is defined by exploiting its duality to

universal quantification.

[[ ∃var :S•Pred ]]P

ETFM = [[ ¬ ∀ var :S• ¬ Pred ]]P

ETFM

Local Definitions. Local definitions associate an expression expr with an identifier var with-

in a local scope. Each local definition extends the model Mused to interpret the subsequent

predicate Pred.

[[ let var == expr •Pred ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

(tf,M⊕{var 7→ [[ expr ]]

Zval (tf,M,IL)},IL)∈[[ Pred ]]P

ETFM }

The expression expr can be an arbitrary expression evaluating to an untimed trace or an

untimed refusal. The function [[ ]]

Zval transforms untimed traces and refusals into corres-

ponding Z values, see the next section.6

6There are also semantic functions evaluating timed/untimed trace, timed/untimed refusal, time value, time

interval and natural number expressions. They are defined after we have dealt with the atomic predicates.

136 Chapter 9. Denotational Semantics

Atomic Predicates.

Schema reference. Introducing references to schemas defined in the Z part, say Prop, and

associating their components, say v1, . . . , vN, with untimed trace or refusal expres-

sions, say expr1, . . . , exprN, is the major link between our predicate language and the Z

language.

[[ Prop(v1b=expr1, . . . , vN b=exprN) ]]P

ETFM =

{tf :TimedFailure;M:Model;IL :ChanSgn |

{v17→ [[ expr1 ]]

Zval (tf,M,IL), . . . , vN 7→ [[ exprN ]]

Zval (tf,M,IL)} ∈ [[ Prop ]]M}

The expressions expr1, . . . , exprN are evaluated and transformed into Z values by the

function [[ ]]

Zval . The resulting Z binding must be a member of the denotation of the

Z schema, computed with the help of the semantic function [[ ]]of the Z Standard.

Timed trace inclusion/prefix. One purpose of the predicate language is to restrict the timed

trace component s. There are several predicates to achieve this, however, we deal only

with the basic predicates, namely inclusion and prefix. The other predicates on timed

traces can be derived.

[[ s1in s2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ s1 ]]

TTr (tf,M,IL)inETFM [[ s2 ]]

TTr (tf,M,IL)}

[[ s1prefix s2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ s1 ]]

TTr (tf,M,IL)⊆[[ s2 ]]

TTr (tf,M,IL)}

Note that the base predicate (s1in s2) is defined in terms of a corresponding relation

inETFM. The formal definition of this relation is part of the definition of the extended

timed failures model. For the sake of brevity, we have omitted its presentation. This

correspondence between base predicates of the predicate language and relations of the

semantic model also applies to subsequent definitions.

Trace inclusion/prefix.

[[ tr1in tr2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ tr1 ]]

Tr (tf,M,IL)inETFM [[ tr2 ]]

Tr (tf,M,IL)}

[[ tr1prefix tr2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ tr1 ]]

Tr (tf,M,IL)⊆[[ tr2 ]]

Tr (tf,M,IL)}

Timed refusal subset. Another purpose of the predicate language is to restrict the timed

refusal component ℵ. Again, there are several predicates to achieve this; however, we

deal only with the basic predicate used to restrict the timed refusal component, namely

the subset relationship. The other predicates on timed refusals can be derived.

•Base

[[ ℵ1⊆ ℵ2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ ℵ1 ]]

TRef (tf,M,IL)⊆[[ ℵ2 ]]

TRef (tf,M,IL)}

9.2. Concrete Specification Units (Open System View) 137

•Derived

ℵ1⊂ ℵ2≡ ℵ1⊆ ℵ2∧ ¬ ℵ1 = ℵ2

te ∈ ℵ1≡ {te} ⊆ ℵ1

Refusal subset.

•Base

[[ ref1⊆ref2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

[[ ref1 ]]

Ref (tf,M,IL)⊆[[ ref2 ]]

Ref (tf,M,IL)}

•Derived

ref1⊂ref2≡ref1⊆ref2∧ ¬ ref1 = ref2

e∈ref ≡ {e} ⊆ ref

Time comparison. The predicate language must also deal with the comparison of time

values, related to the occurrence or refusal of particular events. The base predicate

is ⩽R, from which the other predicates can be derived.

Furthermore, we do not consider time intervals as basic entities of the predicate lan-

guage. Accordingly, the membership of a time value to a time interval is transformed

into an equivalent pair of comparisons with the limits of the interval.

•Base

[[ t1⩽Rt2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

( [[ t1 ]]

T(tf,M,IL),[[ t2 ]]

T(tf,M,IL)) ∈(M⩽R)}

•Derived

t1<Rt2≡ ¬ t2⩽Rt1

t∈[t1,t2] ≡t1⩽Rt∧t⩽Rt2

t∈(t1,t2) ≡t1<Rt∧t<Rt2

t∈[t1,t2) ≡t1⩽Rt∧t<Rt2

t∈(t1,t2] ≡t1<Rt∧t⩽Rt2

Natural number comparison. Finally, the predicate language must deal with the comparison

of natural numbers, related to the length of timed or untimed traces. The base predicate

is ≤, from which the other predicates can be derived.

•Base

[[ n1≤n2 ]]P

ETFM ={tf :TimedFailure;M:Model;IL :ChanSgn |

( [[ n1 ]]

Nat (tf,M,IL),[[ n2 ]]

Nat (tf,M,IL)) ∈(M ≤)}

•Derived

n1<n2≡ ¬ n2≤n1

138 Chapter 9. Denotational Semantics

Semantic Functions on Expressions. According to the previous discussion of the predicate

language, there are different kinds of entities to be set into relationship. That is, the expres-

sions occurring in the predicate language evaluate to values of different “types,” namely

Z values, timed and untimed traces, timed and untimed refusals, time values and natural

numbers. For each type, we define a separate semantic function evaluating expressions of

this type.

The semantic function

[[ ]]

Zval :TimedFailure ×Model ×ChanSgn →W

is the interface between Z expressions and timed CSP expressions in our predicate language.

Its purpose is to transform entities of the timed failures model, such as traces and refusals,

into corresponding Z entities. The expressions that are bound to schema components within

schema reference expressions are evaluated with the help of this function.

Any expression tr evaluating to an untimed trace can be transformed into a Z sequence. This

is achieved by omitting the channel identifier from each event in the trace with the help of

the projection val of.

[[ seq tr ]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •val of ◦[[ tr ]]

Tr (tf,M,IL)

Similarly, any expression ref evaluating to an untimed refusal can be transformed into a Z

set. Again, this is achieved by omitting the channel identifier from each event in the refusal

with the help of the projection val of.

[[ set ref ]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •val of(|[[ ref ]]

Ref (tf,M,IL)|)

It is also possible to transform single events into Z values. There are only four possibilities to

denote untimed events: by applying the functions first,head,last and foot yielding the first

and last event of an untimed or timed trace. Since we do not intend to introduce a semantic

function to evaluate event expressions, we must embed separate event expressions within

set expressions, which in turn can be evaluated by means of the function [[ ]]

Ref . The unique

members of the resulting singleton sets are determined by the function unique mem.

[[ head tr ]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •

val of(unique mem( [[ {head tr}]]

Ref (tf,M,IL)))

[[ first s]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •

val of(unique mem( [[ {first s}]]

Ref (tf,M,IL)))

[[ foot tr ]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •

val of(unique mem( [[ {foot tr}]]

Ref (tf,M,IL)))

[[ last s]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •

val of(unique mem( [[ {last s}]]

Ref (tf,M,IL)))

Finally, also time expressions can be transformed into corresponding Z values.

[[ time t]]

Zval =λtf :TimedFailure;M:Model;IL :ChanSgn •[[ t]]

T(tf,M,IL)

9.2. Concrete Specification Units (Open System View) 139

Time-valued expressions are first-order citizens in our predicate language. They are eval-

uated with the help of the Z part, because reals including their associated functions and

relations are predefined in the Z part; thus, each model Mcarries the needed information to

interpret these expressions.

The semantic function

[[ ]]

TTr :TimedFailure ×Model ×ChanSgn →TimedTrace

evaluates timed trace expressions.

As mentioned, each predicate of the extended timed failures model induces a relation be-

tween the dedicated identifiers s,ℵ,Mand IL. The expression sis used to refer to the timed

trace component.

[[ s]]

TTr =λtf :TimedFailure;M:Model;IL :ChanSgn •tf.1

There are different constructors for timed traces. First, one can explicitly provide a finite

sequence of timed events. The timed events can be composed of arbitrary time and value

expressions, which are evaluated by the corresponding semantic functions. The empty timed

trace and the concatenation of timed traces are the other possibilities to construct timed

traces.

[[ h(t1,c1.val1), . . . , (tN,cN.valN)i]]

TTr =λtf :TimedFailure;M:Model;IL :ChanSgn •

λi: 1 . . N•( [[ ti]]

T(tf,M,IL),(ci,[[ vali]]

Zval (tf,M,IL)))

[[ hi ]]

TTr =λtf :TimedFailure;M:Model;IL :ChanSgn •∅

[[ s1as2 ]]

TTr =λtf :TimedFailure;M:Model;IL :ChanSgn •

( [[ s1 ]]

TTr (tf,M,IL)) aETFM ( [[ s2 ]]

TTr (tf,M,IL))

The meaning of the other functions of the timed failures model yielding timed traces, e.g.,

tail and init, is defined in terms of their counterparts in RT-Z’s semantic model. Since their

definition is straightforward, they are omitted.

The semantic function

[[ ]]

TRef :TimedFailure ×Model ×ChanSgn →TimedRefusal

evaluates timed refusal expressions.

The timed refusal component is referred to by the expression ℵ.

[[ ℵ]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •tf.2

There are three constructors for timed refusals: the explicit definition of a finite set of timed

events, the empty set and union.

140 Chapter 9. Denotational Semantics

[[ {(t1,c1.val1), . . . , (tN,cN.valN)}]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •

{i: 1 . . N•( [[ ti]]

T(tf,M,IL),(ci,[[ vali]]

Zval (tf,M,IL)))}

[[ ∅]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •∅

[[ ℵ1∪ ℵ2 ]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •

[[ ℵ1 ]]

TRef (tf,M,IL)∪[[ ℵ2 ]]

TRef (tf,M,IL)

We do not need to define a separate semantic function to evaluate timed event expressions.

The functions yielding timed events are evaluated in the context of singleton set expressions

with the help of the current semantic function.

[[ {head sexpr}]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •

{headETFM( [[ sexpr ]]

TTr (tf,M,IL))}

[[ {foot sexpr}]]

TRef =λtf :TimedFailure;M:Model;IL :ChanSgn •

{footETFM( [[ sexpr ]]

TTr (tf,M,IL))}

The various functions yielding timed refusals are defined in terms of their counterparts of

the semantic model of RT-Z. Again, their definition is omitted.

The semantic function

[[ ]]

Ref :TimedFailure ×Model ×ChanSgn →Refusal

evaluates (untimed) refusal expressions. A particular kind of refusal expression—expres-

sions denoting set of events—are alphabet expressions.

The alphabet of a channel chan, denoted {| chan |}, is the set of all value-carrying events

that can occur on this channel. It can be determined only on the basis of the value domain

associated with the channel—a piece of information fixed by the channel declarations of the

INTERFACE and LOCAL sections.

Alphabet expressions occur in the predicate language of the extended timed failures model,

but also as parameters of some timed CSP operators, e.g., of the parallel composition oper-

ator P|[A]|Q; so the current semantic function is also used to define the meaning of those

operators of the process term language, see the previous section. As mentioned, each ref-

erence to an external or internal channel ({| chan |}) denotes its alphabet. The INTERFACE

and LOCAL sections induce the channel signature IL that maps each channel identifier to a Z

expression, which is evaluated in the context of a particular model Mof the Z part.

[[ {| chan |} ]]

Ref =λtf :TimedFailure;M:Model;IL :ChannelType |chan ∈domIL •

{chan} × ( [[ IL chan ]]M)

Note that the expression {| chan |} is defined only if chan is declared as an external or internal

channel, i.e., chan ∈domIL.

When the function [[ ]]

Ref is used to evaluate alphabet expressions, the timed failure par-

ameter tf is not needed, see the above definition. For notational convenience, we introduce

the following abbreviation

9.2. Concrete Specification Units (Open System View) 141

[[ expr ]]

α(M,IL) = [[ expr ]]

Ref ((hi,∅),M,IL)

where we have arbitrarily chosen the simplest timed failure (hi,∅).

The semantic functions [[ ]]

Tr ,[[ ]]

T,[[ ]]

TInt and [[ ]]

Nat evaluate untimed trace, time,

time interval and natural number expressions. Since their definition is straightforward and

provides no further insight, we omit it.

To conclude, we have completely formalised the predicate language of the extended timed

failures model, in particular its novel features that go beyond the predicate language of

timed CSP, e.g., quantification over Z sets and references to Z schemas. This formalisation is

in contrast to the use of predicates in timed CSP, where quantification over data sets is used

but without any formal underpinning.

9.2.5 Timed Failures/States Model (TFSM)

We now discuss the transition from the extended timed failures model to the timed fail-

ures/states model (see Figure 9.4).

The timed failures/states model extends the (extended) timed failures model by taking into

account the evolution of the data state of the artifact under consideration, resulting from

the termination and execution of operations within the observation interval. A timed state

is a finite partial function, associating a data state with particular time instants within the

observation interval.

TimedState == T7 7→ Binding

A timed state is finite, because it is the result of operation terminations and executions, re-

corded in finite timed traces.

In the timed failures/states model, each specification unit is associated with a set of pairs

consisting of a timed failure and a timed state.

Predicate Language

Predicates of the timed failures/states model are used in abstract specification units7to

define the overall behaviour of the artifact under consideration. Each predicate in the timed

failures/states model is interpreted in the context of a model M, reflecting the definitions of

the Z part, and a channel signature IL, reflecting the channel declarations of the INTERFACE

and LOCAL sections; and it induces a relation between timed failures (s,ℵ)and timed states

tst.

The predicate language is a superset of the predicate language of the extended timed fail-

ures model defined in the previous section. The extension consists of the collection of speci-

fication macros expressing so-called ‘time-variant state properties,’ which we introduced in

7Therefore, this section is an anticipation of the definition of the semantics of abstract specification units in

Section 9.3.

142 Chapter 9. Denotational Semantics

Section 6.1; they are additional atomic predicates, to which all operators defined in the pre-

vious section can be applied. These specification macros allow us to specify properties of the

data state evolution by relating the timed state component tst to the remaining components

already present in the extended timed failures model.

The semantic function [[ ]]P

TFSM associates each predicate of the timed failures/states model

with its characterising set of timed failures (s,ℵ), timed states tst, models Mand channel

signatures IL.

[[ ]]P

TFSM :TFSM PREDICATE →P(TimedFailure ×TimedState ×Model ×ChanSgn)

We need to define the meaning of only the additional atomic predicates, i.e., of the specifica-

tion macros expressing time-variant state properties. Defining the meaning of the constructs

adopted from the extended timed failures model within the current model is analogous to

the definition in the ETF model; the only difference is the additional timed state component,

which is, however, not constrained by the adopted constructs.

Additional Specification Macros. The specification macro (Prop at t) is satisfied by a timed

state tst if, and only if, the last data state that is recorded in the timed state tst before time

instant t(inclusive) has property Prop.

[[ Prop at t]]P

TFSM ={tf :TimedFailure;tst :TimedState;M:Model;IL :ChanSgn |

Prop ∈domM ∧

∃1t1 == sup{t2 : domtst |t2⩽R[[ t]]

T(tf,M,IL)} •

tst t1∈[[ Prop ]]M}

Accordingly, the specification macro (Prop before t) is satisfied by a timed state tst if, and

only if, the last data state that is recorded in the timed state tst before time instant t(exclusive)

has property Prop.

[[ Prop before t]]P

TFSM ={tf :TimedFailure;tst :TimedState;M:Model;IL :ChanSgn |

Prop ∈domM ∧

∃1t1 == sup{t2 : domtst |t2<R[[ t]]

T(tf,M,IL)} •

tst t1∈[[ Prop ]]M}

The specification macro (Prop during TI) is satisfied by a timed state tst if, and only if, all

data states of tst during interval TI have property Prop.

[[ Prop during [t1,t2] ]]P

TFSM ={tf :TimedFailure;tst :TimedState;M:Model;IL :ChanSgn |

Prop ∈domM ∧

∃1TI == {t:domtst |[[ t1 ]]

T(tf,M,IL)⩽Rt∧t⩽R[[ t2 ]]

T(tf,M,IL)} •

∀t:TI •tst t ∈[[ Prop ]]M}

The definition of the macro during for the other possibilities to denote time intervals—[t1,t2),

(t1,t2] and (t1,t2)—is straightforward and hence omitted.

Finally, (Prop invariant) is satisfied by a timed state tst if, and only if, each data state of tst

has property Prop, i.e., if Prop is an invariant property.

9.2. Concrete Specification Units (Open System View) 143

1 i-1 i i+1 j... ... ...

0 t1 t2 t

well-formed diverging

h ...

t1 t2 t30 untimed state sequence

timed state

... ... ...

Figure 9.6: Mapping a state sequence to a timed state.

[[ Prop invariant]]P

TFSM ={tf :TimedFailure;tst :TimedState;M:Model;IL :ChanSgn |

Prop ∈domM ∧

∀t:domtst •tst t ∈[[ Prop ]]M}

This concludes the formalisation of the predicate language of the timed failures/states model

of RT-Z.

Timed Failures/States Semantics of Z Specifications

Consider Figure 9.6. It illustrates the transformation of an untimed state sequence, which is

one component of a history, to a timed state. We have to distinguish between two parts of

such an untimed state sequence: an initial part corresponding to a sequence of well-formed

operation applications (in which operations applied concurrently do not interfere with each

other), and the remaining, diverging part (possibly empty) corresponding to a sequence of

interfering operation applications. In the example of Figure 9.6, we suppose that the state

sequence is well-formed beyond state j. The data states with indices i−1,iand i+ 1 are all

mapped to the time instant t2. That is, all three data states are caused by operations executed

or terminated at t2. The data state recorded in the timed state at t2is that with the maximal

of those indices that are mapped to t2, namely i+ 1, because the other data states (i−1and

i) are only “intermediate” leading to the total result of applying all three operations to the

previous data state.

This process of transforming an (untimed) state sequence into a timed state is formally

defined by the relation timedst of stseq. Note that this relation does not fix a particular

mapping of the data states of the untimed sequence to time values. This mapping is pos-

sible only in the context of a particular timed trace, recording the time instants of operation

terminations and executions.

144 Chapter 9. Denotational Semantics

timedst of stseq == {h:History;tst :TimedState |

∃1states == states of h •

0R∈domtst ∧tst 0R=states 1∧

(∃index to time :domstates \ {1} →→ domtst \ {0R} |

(∀i,j:domstates |i<j•index to time i ⩽Rindex to time j)•

(∀t:domtst •tst t =states(max{i:domstates |index to time i =t})))

•(h,tst)}

The surjective, monotone function index to time maps the states of the untimed sequence to

the time values at which they are caused because of the termination or execution of opera-

tions.

The following relation timed statesZspecifies the association of histories of the Z part with

timed states tst that are possible evolutions of the data state provided a particular timed

failure tf has been observed.

timed statesZ== {h:History;tf :TimedFailure;tst :TimedState |

∃1s== tf.1•

tst ∈timedst of stseq(|{h}|)∧

domtst ={0R}∪{t:T| ∃ i:doms•

chan of(ev of(s i)) ∈ranTermOf ∪ranExecOf ∧time of(s i) = t}

•(h,(tf,tst))}

The domain of the timed state is defined to be the set of time values at which operations

have terminated or have been executed according to the timed trace s.

9.2.6 Semantic Integration: Definition

We have now available all preliminary definitions to deal with the last step of the semantic

integration. The semantic function of the model of timed failures/states for concrete speci-

fication units, written timed failures statesC[[ ]] , maps each concrete specification unit to a set

of pairs consisting of a timed failure and a timed state. To define this semantic function, we

still need two auxiliary relations, tfs of modelINT and tfs of modelEXT.

The relation tfs of modelINT formally specifies our informal description in Figure 6.5 of com-

posing the CSP part and the CSP interpretation of the Z part of a concrete specification unit.

Let (sCSP,ℵCSP)be a timed failure of the CSP part and (sZ,ℵZ)be a timed failure of the CSP

interpretation of the Z part. The conditions defined in tfs of modelINT to compose these two

timed failures to obtain the timed failure (s,ℵ)of the entire specification unit reflect the de-

finition of the interface parallel operator in timed CSP [Schneider, 1999b, p. 353]. Both parts

synchronise on the set of operation-related events ORE.

9.2. Concrete Specification Units (Open System View) 145

tfs of modelINT == {CSU :CSpecUnit;M:Model;s:TimedTrace;ℵ:TimedRefusal;

tst :TimedState |

∃1IL == CSU.I∪CSU.L;

ORE == ORC ×ChannelValue;OREX== (ORC ×ChannelValue)∪ {X} •

(∀i:doms•

chan of(ev of(s i)) ∈domIL ∧

val of(ev of(s i)) ∈[[ IL(chan of(ev of(s i))) ]]M)∧

(∃h:Histories(|{(M,CSU.OPS)}|); sZ,sCSP :TimedTrace;ℵZ,ℵCSP :TimedRefusal •

(sZ,ℵZ)∈timed failuresZ(|{(h,Histories(|{(M,CSU.OPS)}|))}|)∧

((sCSP,ℵCSP)/∈timed failuresETFM [[ CSU.EA ]](M,IL)

∨(sCSP,ℵCSP)∈

timed failuresETCSP [[ CSU.Behav Behaviour ]](CSU.Behav,(M,M),IL))∧

((sZ,sCSP),ORE) synch s∧

ℵZ\(T×OREX) = ℵCSP \(T×OREX)∧

ℵ=ℵZ∪ ℵCSP ∧

((sZ,ℵZ),tst)∈timed statesZ(|{h}|))

•((CSU,M),((s,ℵ),tst))}

As depicted in Figure 6.5, the operation-related events are hidden from the environment of

the parallel composition, which is formalised by the following relation.

tfs of modelEXT == {CSU :CSpecUnit;M:Model;tfail :TimedFailure;tst :TimedState |

∃1s== tfail.1; ℵ== tfail.2;

ORE == ORC ×ChannelValue •

(∃s∗:TimedTrace;ℵ∗:TimedRefusal •

((s∗,ℵ∗),tst)∈tfs of modelINT(|{(CSU,M)}|)∧

s=s∗ttr ORE ∧

ℵ∗=ℵ ∪ (T×ORE))

•((CSU,M),(tfail,tst))}

The conditions defined in tfs of modelEXT reflect the definition of the hiding operator in

timed CSP, see [Schneider, 1999b, p. 354].

Finally, we build the union over all models of the meaning of the Z part that are consistent

with the definition of the real numbers within ZF set theory. That is, we take only those

models of the Z part into account that map the symbols of the Z section Reals to the corres-

ponding entities of the semantic universe, whose existence is supposed on p. 122.

timed failures statesC[[ ]] == λCSU :CSpecUnit •

S{M :Model | M ∈ [[ CSU.Zpart ]]ZOpsPreds ∧

{R,0R,1R,+R,∗R, <R} ⊆ domM ∧

MR=R ∧ M 0R= 0R∧ M 1R= 1R∧

M+R= +R∧ M ∗R=∗R∧ M <R=<R

•tfs of modelEXT(|{(CSU,M)}|)}

146 Chapter 9. Denotational Semantics

This concludes the description of the semantic model of timed failures/states for concrete

specification units.

9.3 Abstract Specification Units (Open System View)

Having established the infrastructure of several semantic models in Section 9.2, the denota-

tional semantics of abstract specification units can be defined on this basis quite succinctly.

Recall the structure of abstract specification units as described in Section 7.2. The semantics

of such an abstract unit is the relation between timed failures and timed states as induced by

the predicate that is associated with the dedicated identifier Behaviour in the BEHAVIOUR-

AL PROPERTIES section.8

Let TFSM PREDICATE denote the set of predicates of the timed failures/states model as

specified by the syntax definition in Appendix D. These predicates constitute the nota-

tion of the BEHAVIOURAL PROPERTIES section of abstract specification units. The se-

mantic function of the model of timed failures/states for abstract specification units, written

timed failures statesA[[ ]] , associates a set of pairs consisting of a timed failure and a timed

state with each abstract specification unit being composed of

•a Z part, consisting of a TYPES & CONSTANTS,I/O RELATIONS and STATE PROP-

ERTIES section,

•an INTERFACE section,

•an ENVIRONMENTAL ASSUMPTIONS section and

•aBEHAVIOURAL PROPERTIES section, which, by referring to the definitions of the

other sections, fixes the required relation between timed failures and timed states.

ASpecUnit == [Zpart :ZSpec;

I:ChanSgn;

EA :ETFM PREDICATE;

BehavProp :TFSM PREDICATE]

A pair ((s,ℵ),tst)is part of the denotation of an abstract specification unit ASU if

•the timed failure (s,ℵ)violates the environmental assumption or

•there exists a model Msuch that M,(s,ℵ)and tst satisfy the predicate Behaviour of the

BEHAVIOURAL PROPERTIES section.

8The BEHAVIOURAL PROPERTIES section can contain other named predicates, but these are used only to

structure the predicate Behaviour, which refers—directly or indirectly—to the other predicates. Each set of

predicates can thus be normalised to a single predicate Behaviour.

9.4. Closed System View 147

timed failures statesA[[ ]] == λASU :ASpecUnit •

S{M :Model | M ∈ [[ ASU.Zpart ]]ZProps ∧

{R,0R,1R,+R,∗R, <R} ⊆ domM ∧

MR=R ∧ M 0R= 0R∧ M 1R= 1R∧

M+R= +R∧ M ∗R=∗R∧ M <R=<R•

{s:TimedTrace;ℵ:TimedRefusal;tst :TimedState |

(∀i:doms•

chan of(ev of(s i)) ∈domASU.I∧

val of(ev of(s i)) ∈[[ ASU.I(chan of(ev of(s i))) ]]M)∧

((s,ℵ)/∈timed failuresETFM [[ ASU.EA ]](M,ASU.I)

∨

((s,ℵ),tst,M,ASU.I)∈[[ ASU.BehavProp ]]P

TFSM ∧

(State ∈domM ⇒ (∀t:domtst •tst t ∈ M State)))

•((s,ℵ),tst)}}

This concludes the description of the semantic model of timed failures/states for abstract

specification units. Altogether, we have completed the semantic model for the open system

view and proceed with the closed system view in the following section.

9.4 Closed System View

The specification of an artifact in the closed system view incorporates only its behaviour

at the external interface, i.e., its internal properties are hidden. Based on the definition of

the semantic model of RT-Z for the open system view in the previous section, the semantic

functions of RT-Z for the closed system view can be specified quite succinctly; we need only

to hide the timed state component from the corresponding functions defined in the previous

section.

9.4.1 Concrete Specification Units

The semantic function of the timed failures model for concrete specification units, written

timed failuresC[[ ]] , maps each concrete specification unit to a set of timed failures. This

function yields the domain of the relation that is computed by the corresponding semantic

function for the open system view. This amounts to an existential quantification over the set

of timed states.

timed failuresC[[ ]] == λCSU :CSpecUnit •dom(timed failures statesC[[ ]] CSU)

9.4.2 Abstract Specification Units

The semantic function of the timed failures model for abstract specification units, written

timed failuresA[[ ]] , maps each abstract specification unit to a set of timed failures. Also this

function yields the domain of the relation that is computed by the corresponding semantic

function for the open system view.

148 Chapter 9. Denotational Semantics

timed failuresA[[ ]] == λASU :ASpecUnit •dom(timed failures statesA[[ ]] ASU)

This concludes the description of the semantic model of RT-Z.

9.5 Definedness of Recursive Process Equations

Combining process algebras that are based on denotational semantics with state-based tech-

niques generally raises the question if the fixed point theory underlying the denotational

semantics of the chosen process algebra can be adopted in the combined language. In de-

notational approaches to defining the semantics of process algebras, the meaning of a re-

cursive process equation X=F(X)is defined to be the least fixed point of the process term F

containing free occurrences of the process variable X. The assumption underlying this defi-

nition is the existence of a least fixed point for any valid process term F. To our knowledge,

there are two approaches to ensuring the existence of fixed points of process equations.

The first approach is to impose a complete partial order (CPO) structure on the set of pro-

cesses. The existence of least fixed points is guaranteed in this context, if all process operators

are continuous, consult [Davey and Priestley, 1990, Chapter 4] for details.

The second approach is to impose a complete metric space (CMS) structure on the set of

processes, based on a particular distance function between processes. The existence and

uniqueness of fixed points is guaranteed in this context, if all process operators are contrac-

tion mappings. This is established by Banach’s fixed point theorem, consult [Sutherland,

1975, p. 130] for details. The fixed point approach of timed CSP is based on a complete

metric space structure, as discussed in Section A.2.

When combining a process algebra with a state-based technique, the advantage of the CMS

approach over the CPO approach is that the property of a process operator to be a contrac-

tion mapping does not depend on the finiteness of process alphabets; this is in contrast to

the property of a process operator to be continuous.9Consequently, the semantic model

of timed CSP, based on the CMS approach, is appropriate for being combined with a state-

based technique capable of introducing infinite data domains.

9Recursion in the failures–divergences model of CSP was defined by imposing a CPO structure on that model.

For the failures–divergences model to be complete, however, the introduction of unbounded nondeterminism

had to be forbidden. This restriction, in turn, ruled out some process operators, e.g., general nondeterministic

choice and the hiding of infinite event sets. However, infinite event sets arise naturally in the context of

state-based techniques, which are capable of introducing infinite data domains.

To cope with infinite process alphabets and certain forms of unbounded nondeterminism, Roscoe [1992] based

the fixed point theory of CSP on an alternative order, which is different from the usual refinement order.

Although this order is complete (CPO), the hiding operator fails to be continuous. Moreover, some forms of

unbounded nondeterminism still cannot be treated in the context of this alternative order.

For these reasons, Roscoe [1993] invented the infinite traces model, which adds a further component to process

denotations: the infinite traces that a process can exhibit. It covers all forms of unbounded nondeterminisms.

By proving the congruence of the denotational semantics defined for the infinite traces model with the op-

erational semantics of CSP, Roscoe and Barrett [1989] established the existence of fixed points for arbitrary

recursive process equations.

The above discussion should have illustrated the difficulties that were encountered when dealing with un-

bounded nondeterminism in the context of the CPO underlying the denotational semantics of untimed CSP.

9.5. Definedness of Recursive Process Equations 149

To ensure that recursive process equations in the CSP part of an RT-Z specification unit are

well-defined, we must consider two issues that might counteract the fixed point approach of

timed CSP:

•the additional “dimension” of nondeterminism introduced by the Z part and

•the dependency of the semantics of process terms in the extended timed failures model

from information induced by the Z part.

Concerning the first issue, the behaviour of a specification unit, which is defined by its CSP

part, is usually cyclic. The timed CSP process defining such a cyclic behaviour must be

defined recursively. Further, the CSP part controls the evolution of the Z data state, which

is usually infinite. Thus, the question arises if such recursively defined timed CSP process

equations have a unique solution (i.e., if they have a unique fixed point) in spite of the ad-

ditional “dimension” of unbounded nondeterminism constituted by the evolution of the Z

data state.

Fortunately, the unbounded nondeterminism that is potentially introduced by Z operations

working on an infinite data state on the one hand and the computation of the fixed point

of the timed CSP process equations controlling the execution of these Z operations on the

other hand can be completely separated. This ability to separate these two issues is due to

the semantic separation of the Z part and the CSP part, which are composed in parallel. The

definitions in the CSP part restrict only the order of operation executions and their timing.

The corresponding effect on the data state is encapsulated in the parallel process that is the

timed CSP interpretation of the Z part.

Note further that the timed failures semantics of the Z part is not defined by means of re-

cursive process equations, but it is a direct mapping from Z specifications to sets of timed

failures. The resulting sets of timed failures satisfy the properties of the timed failures model

as demonstrated in Appendix B, i.e., they are guaranteed to represent timed CSP processes.

Concerning the second issue, in the extended timed failures model, each timed CSP process

term is evaluated in the context of information induced by the corresponding Z part; it is

encoded by the parameters of the semantic function timed failuresETCSP. The question arises

if this context, in which process terms are evaluated, has any consequences on the existence

and uniqueness of fixed points of recursive process equations.

These parameters of the semantic function solely concern the evaluation of value, time and

index set expressions within process terms. Furthermore, this context information is identi-

cal for the evaluation of all instances of all process terms: whenever a process term is instan-

tiated recursively, it is evaluated in the same context. That is, if a value, time or index set

expression evaluates to a particular value, then this value is the result of all evaluations of

this expression for all recursive instantiations of the process term. Thus, the context param-

eters do not influence the computation of fixed points of recursive process equations.

To conclude, the fixed point approach underlying timed CSP can be adopted as the fixed

point approach of the integrated formalism RT-Z.

150 Chapter 9. Denotational Semantics

Chapter 10

Refinement

So far, we have introduced abstract and concrete specification units as a notation to define

requirements and designs at different levels of abstraction; and we have defined a denota-

tional semantics associating these specification units with a formal meaning.

According to Woodcock and Davies [1996], “writing a formal specification is a worthwhile

activity in its own right.” Among other things, this is justified by the facts that formal speci-

fication languages

•have the ability to precisely, unambiguously express requirements, constraints, archi-

tectures etc.,

•are the basis for detecting inconsistencies or incomplete definitions of requirements or

design flaws and

•force the specifier to think more rigorously about the considered artifact, which helps

gaining a deeper understanding of the artifact.

In addition to documenting the result of a single development step, however, one usually

wishes to develop a formal specification towards an implementation in a stepwise manner.

This process of development is called refinement. Refining a specification means improving

it, usually in the sense that it becomes closer to implementation structures. Improving a

specification may be achieved by removing nondeterminism. An abstract specification may

leave some design decisions open, which are resolved in a refinement step by eliminating

nondeterminism.

In the context of RT-Z, we must distinguish between different modes of refinement in sev-

eral respects. Our starting point is to define refinement relations between single specification

units; the refinement of compound specification units is defined on this basis. For both the

refinement of single and compound specification units, we must take into account whether

the refinement is to be conducted in the context of the open or closed system view, i.e., if the

refinement should encompass the evolution of the (internal) data state. Finally, with regard

to the refinement of single specification units, we must distinguish among the refinement

between two concrete specification units and the refinement between an abstract and a con-

crete specification unit.

This chapter is organised according to these distinctions.

151

152 Chapter 10. Refinement

10.1 Refining Single Specification Units

In this section, we define the conditions under which a single specification unit is refined by

another one in both the closed and the open system view; and we deal with techniques to

establish refinement between single specification units.

10.1.1 Retrieve Specification Units

Usually, the refinement of a specification unit is accompanied by a refinement of the un-

derlying data types—concerning the representation of the internal data states as well as the

representation of the information communicated at the external interfaces. A retrieve speci-

fication unit is used to formally record the relationships between a refined specification unit,

say SUA, and a refining specification unit, say SUC.

Figure 10.1 depicts the structure of a retrieve specification unit. It incorporates the retrieve

relations between corresponding data domains in the refined unit SUAand the refining unit

SUC, used there in order to define the domains of ports and channels, the data states and

the parameters of operations. By convention, each retrieve specification unit imports the Z

definitions of the specification units being related.

A retrieve specification unit is structured according to the following three tasks. First, it

defines a retrieve relation for each external port and local channel that is subject to a change

of representing the communicated information. Second, it records the relationship between

the data states of the refining unit and the data states of the refined unit. Third, it defines

a retrieve relation for each operation schema, recording a potential change of representing

the input and output parameters. The refinement of operation parameters is a concept intro-

duced by Derrick and Boiten [2001] using the term IO refinement; IO refinement extends the

conventional refinement techniques of Z, which take into account changes of only the data

state.

Note the potential redundancy between the retrieve relations in the LOCAL section and in

the OPS & PREDS section. Some of the channels declared in the LOCAL section are related to

operation applications; the retrieve relation for such a channel defines the change of repre-

senting the information communicated via this channel: the input and output parameters of

the corresponding operation. Because of this potential redundancy, the retrieve relations in

the LOCAL section that are associated with operation-related channels are not defined expli-

citly but are derived from the corresponding retrieve relations in the OPS & PREDS section.

Consider the structure of the Z schemas in the INTERFACE and the LOCAL section, in par-

ticular of the schema RetrChanport1. These schemas define retrieve relations by declaring two

components Aand C, which have a special meaning. Adenotes any value exchanged at the

considered port of the refined unit SUA, while Cdenotes a corresponding value exchanged

at the considered port of the refining unit SUC. The predicate part of the schema defines the

relationship between the abstract and concrete representation of the information exchanged

at that port in terms of a predicate containing Aand C. This predicate, however, cannot be

arbitrary. We require that the relation defined by the predicate is total in both directions:

each abstract representation must be related to some concrete representation, and vice versa.

The schemas defining the retrieve relations for the data state and the operation parameters,

on the other hand, need not introduce the special identifiers Aand C, because the entities

10.1. Refining Single Specification Units 153

RETR.SPEC.UNIT RSU :SUA SUC

INTERFACE

RetrChanport1

A:FT

C: seq T

A=ranC

...

LOCAL

RetrChanchan1

A:. . .

C:. . .

. . .

...

STATE

RetrState

SUA.State

SUC.State

. . .

OPS & PREDS [ ]

RetrInParOP == [ SUA.OPInPar;SUC.OPInPar |. . . ]

RetrOutParOP == [ SUA.OPOutPar;SUC.OPOutPar |. . . ]

. . .

Figure 10.1: Template of retrieve specification units.

to be related are already associated with identifiers in the refined and the refining unit: the

respective schemas are simply imported by the schema defining the retrieve relation. This

schema import, however, requires that there are no common identifiers used by both the

refined and the refining unit.1

1This can always be achieved by an appropriate renaming.

154 Chapter 10. Refinement

10.1.2 Relating Timed Observations of a Refined and a Refining Unit

The aim of this section is to lift the retrieve relations defined in a retrieve specification unit to

the level of timed observations of a specification unit: retrieve relations between timed fail-

ures and between timed states. Accordingly, the subsequent definitions relate a refined and

a refining specification unit, which are linked by a retrieve specification unit, with respect to

several, increasingly complex concepts: histories, events, traces, failures, timed failures and

timed states. These definitions are needed in order to specify the refinement relations in the

next section.

Throughout the definition of the following relations, concepts are related that are associated

with a refined (subscript a) and a refining specification unit (subscript c). The two specifi-

cation units are linked by a retrieve specification unit whose Z part is associated with a set

of models. MRis assumed to be a member of this set. Let Retrschema denote the function

mapping each identifier occurring in the refined and the refining unit to the identifier of the

corresponding schema in the retrieve specification unit, which defines the retrieve relation

between the concrete instance in the refining unit and the abstract instance in the refined

unit.

The set Retrhist defines a relation between two histories hcand haassociated with a refined

and a refining specification unit.

Retrhist == {ha,hc:History;MR:Model |

dom(events of hc) = dom(events of ha)∧

(∀i:dom(events of hc)•pop name((events of hc)i) = pop name((events of ha)i)∧

{A 7→ (pop params((events of ha)i)),C 7→ (pop params((events of hc)i))} ∈

MR(Retrschema(pop name((events of ha)i)))) ∧

dom(states of hc) = dom(states of ha)∧

(∀i:dom(states of hc)•((states of hc)i∪(states of ha)i)∈(MRRetrState))

•(MR,(ha,hc))}

The set Retrev relates two events evaand evcassociated with a refined and a refining speci-

fication unit. The events must be transmitted via the same channel, and the values being

transmitted with their occurrence must be related by the retrieve schema defined in the re-

trieve specification unit and belonging to that channel.

Retrev == {eva,evc:Event;MR:Model |

chan of eva=chan of evc∧

{A 7→ val of eva,C 7→ val of evc} ∈ MR(Retrschema(chan of eva))

•(MR,(eva,evc))}

The sets Retrtr,Retrfail and Retrtf define the corresponding relations between traces, failures

and timed failures associated with a refined and a refining specification unit. Their definition

is based on Retrev.

10.1. Refining Single Specification Units 155

Retrtr == {tra,trc:Trace;MR:Model |

domtra=domtrc∧(∀i:domtra•(trai,trci)∈Retrev(|{MR}|))

•(MR,(tra,trc))}

Retrfail == {tra,trc:Trace;Xa,Xc:Refusal;MR:Model |

(tra,trc)∈Retrtr(|{MR}|)∧Xc⊆Retrev(|{MR}|)(|Xa|)

•(MR,((tra,Xa),(trc,Xc)))}

Retrtf == {sa,sc:TimedTrace;ℵa,ℵc:TimedRefusal;MR:Model |

∀t:T•

((strip(sattr t),{e:Event |(t,e)∈ ℵa}),(strip(scttr t),{e:Event |(t,e)∈ ℵc}))

∈Retrfail(|{MR}|)

•(MR,((sa,ℵa),(sc,ℵc)))}

The set Retrtst relates two timed states tstaand tstcassociated with a refined and a refining

specification unit. The timed states must map states to the same time instants, and for each

such time instant the states being recorded must be related by the schema RetrState defined

in the retrieve specification unit.

Retrtst == {tsta,tstc:TimedState;MR:Model |

domtstc=domtsta∧(∀t:domtsta•tstct∪tstat∈(MRRetrState))

•(MR,(tsta,tstc))}

The set RetrInterface defines the retrieve relation between timed failures associated with a re-

fined and a refining unit that is induced by a retrieve specification unit RSU.2

RetrInterface == {sa,sc:TimedTrace;ℵa,ℵc:TimedRefusal;RSU :RSpecUnit |

∃ MR: [[ RSU.Zpart ]]ZRoot •((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)

•(RSU,((sa,ℵa),(sc,ℵc)))}

Analogously, the set RetrInterface/State defines the retrieve relation between timed failures and

timed states associated with a refined and a refining unit that is induced by a retrieve speci-

fication unit RSU.

2The identifier Root occurring in the definition denotes an “artificial” root section, which is part of each re-

trieve specification unit. This section inherits all other Z sections of a retrieve specification unit; each model

associated with it contains hence all variables declared in the entire unit.

156 Chapter 10. Refinement

RetrInterface/State == {sa,sc:TimedTrace;ℵa,ℵc:TimedRefusal;tsta,tstc:TimedState;

RSU :RSpecUnit |

∃ MR: [[ RSU.Zpart ]]ZRoot •

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)∧(tsta,tstc)∈Retrtst(|{MR}|)

•(RSU,(((sa,ℵa),tsta),((sc,ℵc),tstc)))}

The two previous relations are used to define the refinement relation between specification

units.

10.1.3 Closed System View

Considering a specification unit in the closed system view, if abstract or concrete, we are

interested in its behaviour at the external interface, ignoring its internal behaviour. For a

specification unit to refine another one, its associated set of timed failures must be a subset

of the set of timed failures associated with the refined unit. However, the timed failures of

the two units cannot be compared directly because of a potential change of representing the

data values that are recorded in the timed failures. The comparison is thus performed with

respect to the retrieve relations defined in the previous section.

Concrete to Concrete

Refining concrete specification units is all about converging models towards implementation

structures—with respect to data structures, algorithms as well as architectures.

Definition 10.1

A concrete specification unit CSUAis refined by a concrete specification unit CSUCwith

respect to a retrieve specification unit RSU if, and only if, all external interactions consistent

with CSUCare also consistent with CSUA—taking into account the potential change of data

representation as recorded in the INTERFACE section of RSU.

CSUAvRSU

TF CSUC

⇔

timed failuresC[[ CSUC]] ⊆RetrInterface(|{RSU}|)(|timed failuresC[[ CSUA]] |)

Abstract to Concrete

The transition between abstract and concrete specification units is not really a refinement

step. Rather, a concrete specification unit is constructed from scratch in order to define a

model that meets the requirements defined by an abstract specification unit; demonstrating

the satisfaction of these requirements is a verification task. Verification techniques for RT-Z

are part of future work, see Chapter 13. We nevertheless define the implementation relation

between abstract and concrete specification units in this section.

Definition 10.2

An abstract specification unit ASU is refined by a concrete specification unit CSU if, and only

if, all external interactions consistent with CSU are also consistent with ASU—taking into

10.1. Refining Single Specification Units 157

account the potential change of data representation as recorded in the INTERFACE section

of RSU.

ASU vRSU

TF CSU

⇔

timed failuresC[[ CSU ]] ⊆RetrInterface(|{RSU}|)(|timed failuresA[[ ASU ]] |)

Note that we have not defined a refinement relation between pairs of abstract specification

units. From our point of view, abstract specification units are not subject to refinement,

because they fix mere requirements, which should be already known when the part of the

development process starts that is supported by RT-Z.

10.1.4 Open System View

Considering a specification unit in the open system view, we are interested in both its inter-

action at the external interface and the evolution of its internal data state. To check if there is

a refinement relationship between two specification units, we must compare their associated

sets of timed failures and timed states. Again, the timed failures and timed states of the two

units cannot be compared directly because of a potential change of data representation. The

comparison is thus made with respect to the retrieve relations defined in Section 10.1.2.

The following definitions are analogous to that of the closed system view.

Concrete to Concrete

Definition 10.3

A concrete specification unit CSUAis refined by a concrete specification unit CSUCwith re-

spect to a retrieve specification unit RSU if, and only if, all external interactions and data

state evolutions consistent with CSUCare also consistent with CSUA—taking into account

the potential changes in data representation as recorded in the INTERFACE and STATE sec-

tions of RSU.

CSUAvRSU

TFTS CSUC

⇔

timed failures statesC[[ CSUC]] ⊆RetrInterface/State(|{RSU}|)(|timed failures statesC[[ CSUA]] |)

Abstract to Concrete

Definition 10.4

An abstract specification unit ASU is refined by a concrete specification unit CSU with re-

spect to a retrieve specification unit RSU if, and only if, all external interactions and data

state evolutions consistent with CSU are also consistent with ASU—taking into account the

potential changes in data representation as recorded in the INTERFACE and STATE sections

of RSU.

158 Chapter 10. Refinement

ASU vRSU

TFTS CSU

⇔

timed failures statesC[[ CSU ]] ⊆RetrInterface/State(|{RSU}|)(|timed failures statesA[[ ASU ]] |)

10.1.5 Techniques for Establishing Refinement

According to the discussion in the previous two sections, the task that remains to be dealt

with is the refinement of concrete specification units. In this context, our aim is to make

use of the existing refinement techniques of the base formalisms Z and timed CSP. Because

of the chosen approach to defining the meaning of concrete specification units—the parallel

composition of the Z and CSP part—their parts can be refined independently of each other.

This independence is ensured by the monotonicity of the parallel composition operator with

respect to refinement in the timed failures model.

Concerning the CSP part of concrete specification units this means that we can simply use

the refinement techniques provided by timed CSP.

Concerning the Z part, on the other hand, we must establish a link between the refinement

techniques provided by Z and refinement in the timed failures model. In other words, we

must establish that using state-based techniques to refine the Z part results in a refinement of

the timed CSP interpretation of the Z part according to our semantic definitions in Chapter 9.

This approach follows the work of Josephs [1988] who has demonstrated that state-based

refinement techniques are consistent with refinement in the failures–divergences model of

(untimed) CSP. We cannot, however, simply adopt his results in the context of RT-Z, because

•our approach to defining the timed CSP semantics of a Z specification differs from his

approach to defining the CSP semantics of a state-based system and

•two different semantic models are involved: the timed failures model and the failures–

divergences model.

We proceed as follows. We first introduce the definition of the notions of forward and back-

ward simulations. In Section 10.3 we prove that forward and backward simulations imply

refinement in the timed failures/states model of RT-Z.

Josephs [1988, Rules 2.2 and 2.3 on p. 12] has defined the notions of downward and upward

simulations in the context of state-transition systems.3We must translate his definitions into

the context of Z as used within RT-Z. The most essential aspect of this translation is the iden-

tification of the set next(σ), denoting the set of outgoing actions from the state σ, and the set

of operations whose preconditions are satisfied in the data state corresponding to σ. This

identification corresponds to the rˆ

ole we have assigned to operation preconditions in RT-Z:

an operation is blocked in a data state in which its precondition is not satisfied. The most

substantial difference between the following conditions characterising forward and back-

ward simulations in RT-Z and the corresponding conditions given in [Josephs, 1988] is that

we cannot (explicitly) quantify over the set of operation identifiers present in a specification

unit, whereas Josephs has used universal and existential quantifiers over the set of actions

3Instead of the terms upward and downward simulation, we use the terms forward and backward simulation,

because they are more intuitive and also used in [Woodcock and Davies, 1996].

10.1. Refining Single Specification Units 159

of a state-transition system. Another difference between the definitions of Josephs (and also

the definitions of forward and backward simulation in [Woodcock and Davies, 1996]) and

our definitions is that we have taken into account the refinement of data types associated

with the input and output parameters of operations. The conditions have been extended

accordingly.

Forward Simulations. Let CSUAand CSUCbe two concrete specification units. Let RSU be a

retrieve specification unit defining the various retrieve relations. The schema RSU.RetrState

is called a forward simulation between the data states of CSUAand CSUCif the following three

conditions hold for each operation schema OP. All conditions are implicitly universally

quantified over the set of operation identifiers defined in CSUAand CSUC. The conditions

are a translation of the Conditions 1–3 of Rule 2.2 of [Josephs, 1988].

1. Applicability

∀CSUA.State;CSUA.OPInPar;CSUC.State;CSUC.OPInPar |

RSU.RetrState ∧RSU.InRetrOP •

preCSUA.OP ⇔preCSUC.OP

Note that, in contrast to refinement in Z, the precondition of an operation must not be

changed during refinement. This is a consequence of the different rˆ

oles of the precon-

dition in Z and RT-Z (non-blocking vs. blocking).

2. Correctness

∀CSUA.State;CSUA.OPInPar;CSUC.State;CSUC.OPInPar;

CSUC.State0;CSUC.OPOutPar |

preCSUA.OP ∧RSU.RetrState ∧RSU.InRetrOP ∧CSUC.OP •

∃CSUA.State0;CSUA.OPOutPar •CSUA.OP ∧RSU.RetrState0∧RSU.OutRetrOP

3. Initialisation

∀CSUC.State |CSUC.Init • ∃ CSUA.State |CSUA.Init •RSU.RetrState

Backward Simulations. Let CSUAand CSUCbe two concrete specification units. Let RSU be

a retrieve specification unit defining the various retrieve relations. The schema RSU.RetrState

is called a backward simulation between the data states of CSUAand CSUCif the following

three conditions hold for each operation schema OP. Conditions 2 and 3 are direct trans-

lations of the Conditions 2 and 3 of Rule 2.3 of [Josephs, 1988]. Condition 1 is slightly

strengthened, because it is not possible to directly translate the subset relationship without

having the ability to quantify over the set of operation identifiers explicitly.

1. Applicability

∀CSUA.State;CSUA.OPInPar;CSUC.State;CSUC.OPInPar |

RSU.RetrState ∧RSU.InRetrOP •

preCSUA.OP ⇔preCSUC.OP

160 Chapter 10. Refinement

2. Correctness

∀CSUC.State;CSUC.OPInPar;CSUA.State0;CSUA.OPOutPar;

CSUC.State0;CSUC.OPOutPar |

CSUC.OP ∧RSU.RetrState0∧RSU.OutRetrOP •

∃CSUA.State;CSUA.OPInPar •RSU.RetrState ∧RSU.InRetrOP ∧CSUA.OP

3. Initialisation

∀CSUC.State;CSUA.State |CSUC.Init ∧RSU.RetrState •CSUA.Init

This completes the definition of the notions of forward and backward simulations. Note

that identifying and establishing simulations between specification units is a task that has

been reduced to proof obligations that are expressed in terms of the Z notation and that can

be completely discharged using Z techniques. Such techniques for establishing simulations

between abstract data types (ADT) in Z can be found in [Derrick and Boiten, 2001].

In Section 10.3, we prove that the existence of a forward or backward simulation between

two concrete specification units, as defined in this section, implies refinement in the semantic

model of RT-Z.

Discussion

As already indicated, Derrick and Boiten [2001] have introduced the concept of IO refine-

ment for Z abstract data types, which takes into account changes of representing operation

parameters. Their definition of the notions of forward simulation and backward simulation

and our definition of these notions in this section, however, differ in some aspects for the

following reasons.

First, and most important, the preconditions of operation schemas have different rˆ

oles in Z

and RT-Z, giving rise to different applicability and correctness conditions.

Moreover, it seemed most natural to us to treat input parameters analogously to pre states

and output parameters analogously to post states. This analogy/symmetry is directly re-

flected in the above conditions. Derrick and Boiten, by contrast, have used the schema

piping operator in order to relate the abstract and concrete instances of input and output

parameters. This operator allowed them to express the conditions in a more compact way,

however, it prevented a symmetric treatment.

As an analogy to our approach, Derrick and Boiten have not claimed that forward and

backward simulations together are sufficient to prove all valid IO refinement relationships

between abstract data types in Z.

10.2 Refining Compound Specification Units

In this section, we discuss how refinement relations between single specification units are

lifted to compound specification units.

10.2. Refining Compound Specification Units 161

10.2.1 Aggregation

Our aim is to establish—under particular assumptions—that the refinement of an aggre-

gated specification unit, while keeping the context unchanged into which it is embedded,

results in the refinement of the aggregating specification unit constituting its context. The

reasoning in the remainder of this section is carried out with respect to the open system view

but holds for the closed system view as well.

Let CSUAand CSUCbe two concrete specification units and let CompAand CompCbe two

compound specification units that aggregate CSUAand CSUC, respectively, within the same

context.

SPEC.UNIT CompA

...

SUBUNITS

subunit agg spec.unit CSUA

...

SPEC.UNIT CompC

...

SUBUNITS

subunit agg spec.unit CSUC

...

We need two assumptions in order to justify the satisfaction of the following theorem.

Assumption 10.1

The behaviour definition of CompAembeds CSUAwithin its context by means of a timed

CSP operator that is monotone with respect to refinement in the timed failures model, e.g.,

parallel composition or interleaving. By assumption, the same holds for CompCand CSUC.

Assumption 10.2

The compound unit CompAdoes not define any global invariants and global initialisation

constraints. By assumption, the same holds for CompCand CSUC.

Theorem 10.1

Let RSU be a retrieve specification unit defining retrieve relations for the ports and channels

of CSUAand CSUC, and let RSU∗extend RSU corresponding to the way CSUAand CSUC

are embedded within CompAand CompC: there might be additional ports and channels in

CompAand CompCwhose associated domains must also be related (in this case identified).

Ideally, the result to be obtained would be:

162 Chapter 10. Refinement

CSUAvRSU

TFTS CSUC⇒CompAvRSU∗

TFTS CompC.

However, since it has not been established that forward and backward simulations together

are sufficient to prove refinement, we must strengthen the premise of the implication by the

following conjunct: there exists a forward or backward simulation between the data states

of CSUAand CSUC.

So, informally speaking, if we are able to prove refinement between CSUAand CSUCusing

a simulation between their data states, we are also able to prove refinement between CompA

and CompC.

We do not prove the above theorem formally, but provide a systematic reasoning. This reas-

oning can be sketched as follows. Concerning the Z part, we construct a forward/back-

ward simulation between the data states of CompAand CompCbased on the existing for-

ward/backward simulation between CSUAand CSUC. This ensures that the Z parts of the

compound specification units are related by refinement. Concerning the CSP part, we ex-

ploit the assumed monotonicity of the used timed CSP operator to establish the necessary

refinement relationship between the CSP parts of CompAand CompC.

According to Assumption 10.2 and the reduction process defined in Section 8.1.4, the data

state and initialisation schemas of CompAand CompCare derived as follows.

CompA.State

agg :lift simple Z(agg,CSUA.State)

. . .

CompC.State

agg :lift simple Z(agg,CSUC.State)

. . .

CompA.Init

CompA.State

agg ∈lift simple Z(agg,CSUA.Init)

. . .

CompC.Init

CompC.State

agg ∈lift simple Z(agg,CSUC.Init)

. . .

By assumption, there is a forward/backward simulation between the data states of CSUA

and CSUC. This simulation can be easily lifted to a simulation between the data states of

CompAand CompCsuch that the following two conditions hold.

•The components agg of CompA.State and CompC.State are related by the original simu-

lation.

•The other components of CompA.State and CompC.State, which are identical by assump-

tion, are related by the identity relation.

Choosing this lifted simulation, the definition of the promotion of operations defined in

Section 8.1.4 guarantees that each pair of corresponding operations from CompAand CompC

satisfies Conditions 1 and 2 for forward/backward simulations.

•The execution of an operation defined by CSUAand CSUCdepends on and transforms

only the state component agg, because we have assumed that there are no global in-

variants.

10.3. Relationship between Simulation and Refinement 163

•Each operation not defined by CSUAand CSUCis defined equally in CompCand CompA

by assumption. Its execution leaves the state component agg unchanged.

Finally, Condition 3 for forward/backward simulations is satisfied, because there are no

global initialisation constraints and because the state components other than agg are related

by the identity relation.

The above reasoning implies the existence of a forward/backward simulation between the

data states of CompAand CompC, so the Z parts of these two units are related by refinement.

Concerning the CSP part, we have assumed that the behaviour definitions of CSUAand

CSUCare composed with the context by means of an operator that is monotone with re-

spect to refinement in the timed failures model. As a consequence of this monotonicity, the

behaviour definition of CompAis refined by the behaviour definition of CompC.

Altogether, we can conclude that CompAis refined by CompCbecause of the monotonicity of

the parallel operator composing the Z part and the CSP part. Given the transitivity of the re-

finement relation, we can reduce the obligation to prove refinement between two compound

specification units aggregating an arbitrary number of specification units within the same

context to showing that the refinement relation holds between the individual specification

units being aggregated.

The reasoning with regard to indexed aggregation is analogous. We omit it since it does not

provide further insight.

10.2.2 Extension

In contrast to aggregation, it is not reasonable to lift the refinement relation from the level of

single specification units to extension. This is the case because extension is not a means for

structuring large specifications like aggregation, but rather a means for achieving reuse.

If we consider a compound specification unit CompAthat extends the specification unit

CSUA, then the definitions of CSUAare extended by new entities and constraints. The ori-

ginal entities and constraints and the additional ones constitute a single “unit,” and it makes

absolutely no sense to retain this extension structure in the compound specification unit re-

fining CompA.

10.3 Relationship between Forward and Backward Simulations and

Refinement in the Timed Failures/States Model

The aim of this section is to prove that two concrete specification units, say CSUAand CSUC,

which are linked by a retrieve specification unit, say RSU, are related by refinement in the

timed failures/states model if

1. the CSP part of CSUCis a refinement of that of CSUAin the timed failures model and

2. the schema RetrState of RSU defines a forward or backward simulation between the

data states of CSUAand CSUCaccording to the definitions of Section 10.1.3.

164 Chapter 10. Refinement

In contrast to Smith and Derrick [2001] we are not able to directly adopt the results of

Josephs [1988], namely the link between upward and downward simulations that relate

state-transition systems and refinement in the failures–divergences model of CSP. The reason

is twofold. Firstly, we must prove the refinement relationship in a different, more elaborate

semantic model: the timed failures model of timed CSP. Secondly, it is not as obvious as

in the approach of Smith and Derrick [2001] that the mapping from Z specifications to the

timed failures semantics as defined in Chapter 9 directly corresponds to the mapping from

state-transition systems to the failures–divergences model as defined by Josephs.

Let CSUAand CSUCbe concrete specification units, and let RSU be a retrieve specification

unit, which defines retrieve relations between CSUAand CSUC. Let further RSU.RetrState

define a forward or backward simulation between the data states of CSUAand CSUC. We

assume that the Z parts of CSUAand CSUCdo not contain any contradictions (i.e., they are

consistent) and that they do not define any constraints on the symbols declared by the Z

section Reals discussed on p. 122.

Our goal is to prove that

timed failures statesC[[ CSUC]] ⊆RetrInterface/State(|{RSU}|)(|timed failures statesC[[ CSUA]] |)

or, informally speaking, that CSUCrefines CSUAwith respect to RSU in the context of the

open system view. The above condition is the subject of Theorem 10.9. All other theorems

and lemmata are intermediate steps towards this final result.

Within the Theorems 10.2–10.8 (and the lemmata in Appendix C needed to prove them), let

MC,MAand MRbe arbitrary models satisfying

MC∈[[ CSUC.Zpart ]]ZOpsPreds;MA∈[[ CSUA.Zpart ]]ZOpsPreds;

MR∈[[ RSU.Zpart ]]ZRoot.

That is, these theorems are implicitly universally quantified.

Moreover, we build our theorems and lemmata in this section on the following definitions

by equivalence.

HSC == Histories(|{(MC,CSUC.OPS)}|); HSA == Histories(|{(MA,CSUA.OPS)}|)

Theorem 10.2

Considered under the relation Retrhist, each history derived from CSUCis also a history that

can be derived from CSUA. Moreover, for all pairs of histories derived from CSUCand CSUA

being related by Retrhist, the sets of operation-related events constituting possible extensions

are equal.

HSC ⊆Retrhist(|{MR}|)(|HSA|)

∧

∀hc:HSC;ha:HSA |(ha,hc)∈Retrhist(|{MR}|)•

Retrev(|{MR}|)(|ev of op(|{op :POP APP | ∃ h∗

a:HSA |(ha,h∗

a)∈PreHist •

events of h∗

a= (events of ha)ahopi}|)|)

=ev of op(|{op :POP APP | ∃ h∗

c:HSC |(hc,h∗

c)∈PreHist •

events of h∗

c= (events of hc)ahopi}|)

10.3. Relationship between Simulation and Refinement 165

The conjuncts of the above theorem are immediate consequences of our definition of for-

ward and backward simulations in Section 10.1.3. First, the definitions of forward and back-

ward simulations ensure that the abstract description can “simulate” each behaviour of the

concrete description. This is expressed by the first conjunct. Second, Condition 1 of these

definitions imply that the sets of operations whose preconditions are satisfied with respect

to a corresponding pair of concrete and abstract data states are equal. This is expressed by

the second conjunct.

Theorem 10.3

Considered under the relation Retrtr, the trace derived from any history of CSUCis related

to the trace derived from any history of CSUA, if these histories are related by Retrhist.

∀hc:HSC;ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•tracesZhc∈Retrtr(|{MR}|)(|{tracesZha}|)

This is an immediate consequence of the definition of tracesZin Section 9.2.4.

Theorem 10.4

Considered under the relation Retrfail, the set of failures derived from any history of CSUCis

a subset of the set of failures derived from any history of CSUA, if these histories are related

by Retrhist.

∀hc:HSC;ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

failuresZ(|{(hc,HSC)}|)⊆Retrfail(|{MR}|)(|failuresZ(|{(ha,HSA)}|)|)

The theorem is proved in Appendix C.

Theorem 10.5

For each history hcderived from CSUCthere is a corresponding history haderived from

CSUAsuch that the timed failures associated with hcare a subset of the timed failures asso-

ciated with ha—when being considered under the relation Retrhist.

∀hc:HSC • ∃ ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

timed failuresZ(|{(hc,HSC)}|)⊆Retrtf (|{MR}|)(|timed failuresZ(|{(ha,HSA)}|)|)

The theorem is proved in Appendix C.

Having treated the timed failure component of the meaning associated with concrete speci-

fication units, we turn our attention to the timed state component.

Within Theorem 10.6 (and in the lemmata in Appendix C needed to prove it), let hc∈HSC

and ha∈HSA be arbitrary such that (ha,hc)∈Retrhist(|{MR}|). Furthermore, we build

our theorems and lemmata in the remainder of this section on the following definitions by

equivalence.

TFA == timed failuresZ(|{(ha,HSA)}|); TFC == timed failuresZ(|{(hc,HSC)}|)

Theorem 10.6

Considered under the relation Retrtst, the set of timed states that can be derived from any

timed failure of CSUCis a subset of the set of timed states that can be derived from any

timed failure of CSUA, if these timed failures are related by Retrtf .

166 Chapter 10. Refinement

∀sa,sc:TimedTrace;ℵa,ℵc:TimedRefusal |(sa,ℵa)∈TFA ∧(sc,ℵc)∈TFC ∧

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)•

timed statesZ(|{hc}|)(|{(sc,ℵc)}|)⊆Retrtst(|{MR}|)(|timed statesZ(|{ha}|)(|{(sa,ℵa)}|)|)

The theorem is proved in Appendix C.

Theorem 10.7

Considered under the relation RetrInterface/State, the set of timed failures and timed states as-

sociated with CSUCby tfs of modelINT, which is the auxiliary semantic relation defined on

p. 144, is a subset of the set of timed failures and timed states associated with CSUA.

tfs of modelINT(|{(CSUC,MC)}|)

⊆RetrInterface/State(|{RSU}|)(|tfs of modelINT(|{(CSUA,MA)}|)|)

The following two assumptions, which are needed to prove Theorem 10.7, concern the CSP

parts of CSUAand CSUC. They formalise the first condition expressed informally on p. 164.

Assumption 10.3

Firstly, we assume that the behaviour definition in CSUCis a timed failures refinement of

that in CSUA.

timed failuresETCSP [[ CSUC.Behav Behaviour ]](CSUC.Behav,(MC,MC),CSUC.I∪CSUC.L)

⊆

Retrtf (|{MR}|)(|timed failuresETCSP [[ CSUA.Behav Behaviour ]](CSUA.Behav,(MA,MA),CSUA.I∪CSUA.L)|)

Assumption 10.4

Secondly, we assume that the environmental assumption of CSUCis weaker than that of

CSUA.

Retrtf (|{MR}|)(|timed failuresETFM [[ CSUA.EA ]](MA,CSUA.I∪CSUA.L)|)

⊆timed failuresETFM [[ CSUC.EA ]](MC,CSUC.I∪CSUC.L)

Theorem 10.7 is proved in Appendix C.

Theorem 10.8

Considered under the relation RetrInterface/State, the set of timed failures and timed states as-

sociated with CSUCby tfs of modelEXT, which is the auxiliary semantic relation defined on

p. 145, is a subset of the set of timed failures and timed states associated with CSUA.

tfs of modelEXT(|{(CSUC,MC)}|)

⊆RetrInterface/State(|{RSU}|)(|tfs of modelEXT(|{(CSUA,MA)}|)|)

The theorem is proved in Appendix C.

10.3. Relationship between Simulation and Refinement 167

Theorem 10.9

The final theorem contains the refinement condition given in Definition 10.3.

timed failures statesC[[ CSUC]] ⊆RetrInterface/State(|{RSU}|)(|timed failures statesC[[ CSUA]] |)

Let Reals denote the conjuncts in the definition of timed failures statesC[[ ]] on p. 145 related

to the mapping of the symbols representing the real numbers to the corresponding entities

of the semantic universe.

((sc,ℵc),tstc)∈timed failures statesC[[ CSUC]]

`[def. timed failures statesC[[ ]] ]

∃ MC: [[ CSUC.Zpart ]]ZOpsPreds |Reals(MC)•

((sc,ℵc),tstc)∈tfs of modelEXT(|{(CSUC,MC)}|)

`[Theorem 10.8]

∀ MA: [[ CSUA.Zpart ]]ZOpsPreds •

((sc,ℵc),tstc)∈RetrInterface/State(|{RSU}|)(|tfs of modelEXT(|{(CSUA,MA)}|)|)

`[consistency of Z part of CSUA; symbols related to reals are not restricted by Z part]

∃ MA: [[ CSUA.Zpart ]]ZOpsPreds |Reals(MA)•

((sc,ℵc),tstc)∈RetrInterface/State(|{RSU}|)(|tfs of modelEXT(|{(CSUA,MA)}|)|)

`[def. timed failures statesC[[ ]] ]

((sc,ℵc),tstc)∈RetrInterface/State(|{RSU}|)(|timed failures statesC[[ CSUA]] |)



To conclude, we have demonstrated that any refinement of the Z part of a concrete specifi-

cation unit—characterised by a forward or backward simulation—results in a refinement of

the overall specification unit in the timed failures/states model of RT-Z. This allows us to

refine concrete specification units in the context of the open system view.

In the closed system view, by contrast, only the timed failures at the external interface of a

concrete specification unit are taken into consideration—ignoring the evolution of the data

state. Given our above reasoning in the context of the open system view, the corresponding

proof in the context of the closed system view is trivial.

168 Chapter 10. Refinement

Part IV

Discussion

169

Chapter 11

Comparison with Related Formalisms

In this chapter, we contrast RT-Z with those approaches introduced in Chapter 4 that are

related most closely to RT-Z and that have strongly influenced its design.

11.1 CSP-OZ

In this section, we contrast RT-Z and CSP-OZ and discuss their benefits and drawbacks. The

most relevant differences between CSP-OZ and RT-Z can be traced back to the following two

aspects: the choice of similar but different base formalisms and the membership in different

classes of integrated formalisms.

The most evident difference between CSP-OZ and RT-Z is the integration of similar but

distinct formalisms: Object-Z instead of Z and (untimed) CSP instead of timed CSP. This

entails two immediate consequences.

•Since (untimed) CSP is not built on a model of real-time, CSP-OZ is not directly able to

deal with real-time constraints.

•CSP-OZ is able to make use of Object-Z’s structuring mechanisms: classes and their

objects, inheritance and object instantiation.

As already indicated in Chapter 4, CSP-OZ is a monolithic integration according to our pro-

posed classification scheme. This classification is primarily due to the CSP part of CSP-OZ

classes, which is constituted by the intermediate language CSPZ. In CSPZ, the Z and CSP

notations are integrated very closely. The feature of the CSPZnotation that particularly rep-

resents the monolithic nature of CSP-OZ is the schema prefixing operator [Fischer, 2000,

p. 52]. This operator is similar to state guards of TCOZ: it allows an arbitrary schema ex-

pression to play the role of an event.

Thus, all advantages and disadvantages that are discussed in general with respect to the re-

lationship between monolithic and conserving integrations in Chapter 5 apply in particular

to CSP-OZ and RT-Z.

In the remainder of this section, we discuss specific differences between the two integrated

formalisms.

171

172 Chapter 11. Comparison with Related Formalisms

Supported Phases. CSP-OZ and RT-Z focus on different phases of the development pro-

cess.

CSP-OZ, on the one hand, is well-suited for the later development phases, where CSP-OZ

supports the design phase and where the translation from CSP-OZ to Java [Fischer, 2000,

Part 3] supports parts of the implementation phase. However, CSP-OZ does not offer ab-

stract language features for the early requirements phases: there is no counterpart in CSP-OZ

for RT-Z’s abstract specification units.

RT-Z, on the other hand, primarily focuses on the earlier phases, where abstract specification

units support the requirements phases and where concrete specification units support the

design phases. The derivation of code, however, is not covered.

System Model. CSP-OZ and RT-Z have different underlying system models. More spe-

cifically, the two formalisms have different pictures of how systems are decomposed into

components and how components interact with each other.

In CSP-OZ, channels of class interfaces are related to operations, i.e., the occurrence of an

event on a channel is associated with the application of an operation in the corresponding

objects. The identification of external channels and operations results in a strong coupling of

interacting objects: two objects connected by a channel must contain a pair of equally named

operations, and the parameters of these operations must also be equally named. This means

that the interface between objects is broad, i.e., many details concerning internal properties

of objects are globally visible. As Mahony and Dong [1998a] pointed out, this leads to the

problem that the configuration of objects within networks is largely fixed by internal aspects

of the objects (operation and parameter names) rather than by structural aspects.

Environmental Assumptions. CSP-OZ does not provide any notation to explicitly1specify

assumptions about the behaviour of the environment of a class with respect to the channels

of its interface.

Dynamic Creation of Objects. CSP-OZ allows the dynamic creation of objects during the

evolution of a system. While this undeniably increases the flexibility of specifying a dynamic

system, the fact that the collection of active objects and their configuration can change dy-

namically is an enormous complication with respect to verification (in the cases in which

dynamic creation is used).

Semantic Definition. Comparing the semantic definitions of CSP-OZ and RT-Z, we must

conclude that the semantics of CSP-OZ is defined on a higher level of abstraction and in a

less complex way. Both the higher level of abstraction and the lower complexity rest on the

notational power of the intermediate language CSPZof CSP-OZ, which is used to express

the semantics of CSP-OZ classes. In particular, they rest on the ability of CSPZto closely

integrate process and Z expressions and the ability to parametrise CSPZprocess expressions

1Of course, environmental assumptions can always be expressed by incorporating the description of the envir-

onment into the system specification and by using appropriate naming conventions. However, this approach

is not backed up semantically.

11.1. CSP-OZ 173

by arbitrary Z expressions. We argue in the following that these powerful notational abilities

are not backed up semantically in a sound manner and should thus, strictly speaking, not

have been used in the semantic definition of CSP-OZ.

We first deal with the parametrisation of process definitions. In CSPZ, process definitions

can be parametrised by arbitrary Z expressions, e.g.,

P(x:S)c

=a!x→Stop.

Fischer fixed the meaning of parametrised process definitions by giving syntactic translation

rules into Z. The above definition, e.g., is translated into the axiomatic definition

P:S→PROCESS

∀x:S•P(x) = a!x→Stop

Consider the right hand side of the above equation: syntactically, it is a Z expression con-

taining the terminals of the CSP process syntax →and Stop. To fix the semantics of the above

axiomatic definition, the application of the semantic function for Z expressions to the right

hand side of the equation

[[ a!x→Stop ]]M=?

needed to be defined. However, as elaborated in the following, the semantic function [[ ]]

is not defined for process expressions.

Let us address the close integration of process and Z expressions in CSPZ. In contrast to the

approach pursued by Fischer [2000, Section 3.1], we think that Z expressions and process ex-

pressions must be treated as separate syntactic units in the grammar of CSPZ. Otherwise, the

semantic function [[ ]]of the Z Standard for evaluating expressions had to be extended for

process expressions. This would amount to define [[ ]]for all productions of the extended

grammar involving process expressions, e.g.,

[[ PQ]]M=. . .

However, this extension of [[ ]]to process expressions is not defined in [Fischer, 2000]. It

would thus be necessary in CSP-OZ to separate process expressions and usual Z expressions.

But this would mean that the syntax of CSPZis essentially more restricted than suggested

by Fischer.2As a consequence, the conciseness and convenience of the semantic definition

of CSP-OZ [Fischer, 2000, Chapter 4] is based on features of the CSPZnotation that are not

backed up semantically.

Z vs. Object-Z. Object-Z provides powerful constructs such as inheritance and object in-

stantiation to structure large and complex specifications; this is a contrast to (plain) Z, which

does not support any elaborate structuring mechanisms. Since the integrated formalism we

aimed at must necessarily provide means for structuring specifications, it was tempting to

choose Object-Z rather than Z as the basis for our integration, and indeed this is the approach

2For instance, the term ∀x:T•P(x)with Pa process term is not defined semantically.

174 Chapter 11. Comparison with Related Formalisms

taken in the design of CSP-OZ (and also TCOZ). Let us explain our reasons in the design of

RT-Z for choosing Z nevertheless.

In the following, we argue that the semantic definition of Object-Z’s structuring mechan-

isms [Smith, 2000] cannot be reused for the definition of the meaning of the corresponding

structuring mechanisms of CSP-OZ. This particularly applies to object instantiation, so we

concentrate our discussion on that construct.

In Object-Z, object instantiation is a means for decomposing a complex object into a number

of smaller objects. The component objects are declared in the state schema of the compound

object. This allows the compound object (among other things) to define constraints on the

relationships between state components of several component objects (global state invari-

ants) and to define operations on the overall state space by referring to the operations of

the component objects. On the semantic level, the meaning of such a compound object is

defined as a function of the meaning values of its component objects; but this semantic func-

tion inherently depends on the semantic model of Object-Z. If, however, it is decided to

adopt classes (and their objects) as the basic structuring units of an integrated formalism (as

is the case in CSP-OZ and TCOZ), then the notation of Object-Z is mixed with the notations

of the other base formalisms within a class. The meaning (denotation) associated with a

class, then, must necessarily be different from the meaning of an Object-Z class because of

the additional information covered by the other base formalisms. But this means that object

instantiation in an integrated formalism (considered as a semantic function) operates on new

units: the semantic function of Object-Z cannot be used. From a semantical point of view,

object instantiation must be defined from scratch.

As a consequence, we decided to choose Z and to build the needed structuring mechanisms

on top of the integration of Z and timed CSP. To emphasise it again, the decision to use Z

and to build structuring mechanisms on top of the integration of Z and timed CSP does not

cause any additional work compared with a decision in favour of Object-Z: the structuring

mechanisms must be backed up semantically anyway.

Object Instantiation. According to the above discussion, CSP-OZ needed to redefine object

instantiation. Due to the difficulties of defining its meaning, CSP-OZ distinguishes between

two different kinds of classes: CSP-OZ classes and Object-Z classes. Object-Z classes en-

capsulate only Object-Z notation, and they are able to apply object instantiation in the full

generality of Object-Z. CSP-OZ classes, on the other hand, integrating Object-Z and CSP

notation, use a restricted form of object instantiation: CSP-OZ classes cannot instantiate ob-

jects of other CSP-OZ classes in their state schema. In CSP-OZ classes, object instantiation

takes place in the process expressions of the CSP part. But in this context, instantiating an

object means to aggregate a fully encapsulated entity, which can be accessed only via its ex-

ternal interface. In particular, it is not possible in CSP-OZ classes to specify global invariants

on the data states of different instantiated objects which is possible in Object-Z and also in

RT-Z.

The basic idea of defining the semantics of CSP-OZ classes was to use a layering approach.

The first layer is constituted by the language CSPZ, a language extending the Z syntax with

the language of CSP process expressions. CSPZspecifications, like Z specifications, have a

11.1. CSP-OZ 175

flat structure; they are the constituents of classes of CSP-OZ specifications, which add object-

oriented mechanisms such as inheritance and object instantiation to CSPZ. CSP-OZ forms

the second layer. The meaning of a CSP-OZ class is defined in terms of transition rules

mapping the syntax of CSP-OZ to CSPZsyntax.

At first glance, the definition of the restricted form of object instantiation for CSP-OZ classes

is very elegant: it involves only two additional inference rules for CSPZ. In RT-Z, by con-

trast, the effort to define the meaning of simple and indexed aggregation was enormous, see

Sections 8.1.4 and 8.1.5. However, we argue in the following that the approach chosen by

Fischer to define object instantiation is not sound.

To define the meaning of the restricted form of object instantiation for CSP-OZ classes, which

is expressed in the CSP part of a CSP-OZ class in terms of CSPZsyntax, Fischer [2000] defined

the following inference rule on p. 146 (Rule 4.6)

(c,M)τ

−→ (procM(c),M0⊕ {self 7→ c})

which is part of the definition of the hybrid semantics [[ ]]Oof CSPZ. Note that this inference

rule refers to the semantic function of CSP-OZ classes proc. This entails several consequences.

Firstly, the rule is problematic from a conceptual point of view. The circularity—the semantic

function of CSPZdepends on the semantic function of CSP-OZ and vice versa—counteracts

the layering approach. The semantic function proc and the concept of object instantiation

are not known on the level of single CSPZspecifications. Moreover, the semantic function

proc is defined in terms of syntactic transformation rules—on a completely different level of

formality than the definition of the hybrid semantics of CSPZ. In other words, the semantic

function of CSPZis based on a semantic function with an extremely lower level of formality

which is an arguable approach.

Secondly, and even more important, the above inference rule is incorrect, and there appears

to be no simple way to repair this incorrectness for the following reason.

The semantic function for CSPZprocess terms has the following signature.

[[ ]]O:ProcExpr →Model →LTS

That is, the meaning of a CSPZprocess expression is defined only in the context of a particu-

lar model M. Note that each CSPZprocess expression is embedded within an entire CSPZ

specification, which also contains usual Z definitions needed to interpret the process expres-

sion. Thus, although Fischer did not define it explicitly, the model Mused to interpret the

process expression must be a member of the meaning of the entire CSPZspecification.

Applied to the context of a particular CSP-OZ class, it follows that the meaning of its CSP

part—a CSPZprocess expression—must be evaluated in the context of a model Mthat is

a member of the meaning of its Z part.3Consider now Rule 4.6: the model M0used to

interpret the process term procM(c), which represents the meaning of the class M(c)of which

the instantiated object is an instance, is a model of the Z part of the class of the instantiating

object. However, a correct model to interpret the CSPZprocess term must be related to the Z

part of the class of the instantiated object. But there is no way to refer to the Z part of the class

3which defines, e.g., types that are used in the process expressions of the CSP part

176 Chapter 11. Comparison with Related Formalisms

M(c)of the instantiated object, because one can deal only with a single CSPZspecification

on the CSPZlayer, in which the considered inference rule is defined.

In conclusion, the inference rule for object instantiation is not only problematic from a con-

ceptual point of view but not even sound. The consequences are (alternatively)

•That object instantiation is not supported at all in CSP-OZ classes (even in the restricted

form).

•That object instantiation must be dealt with at the CSP-OZ level. That would mean

that object instantiation had to be syntactically separated from CSPZterms, because

otherwise the CSPZsemantic function would not be applicable; then, transformation

rules had to be defined in the style of the inheritance rules.

11.2 TCOZ

In this section, we contrast TCOZ and RT-Z. There are two main differences between TCOZ

and RT-Z that entail several relative merits and drawbacks.

•The choice of the language specifying the data-related characteristics: Object-Z versus

•The design decisions underlying the two integrations, leading to the classification of

TCOZ as a monolithic integration and of RT-Z as a conserving integration according to

the classification scheme discussed in Chapter 5.

These differences and their consequences are discussed in the sequel.

Object-Z [Smith, 2000] is an extension of Z with object-oriented structuring operators, allow-

ing a system specification to be structured into a collection of class specifications. On the one

hand, this increases the ability to cope with complex system specifications. TCOZ inherits

these structuring operators and consequently this ability. On the other hand, the current ver-

sion of the semantic model of TCOZ [Mahony and Dong, 1997, 1999a] abstracts from these

structuring operators of Object-Z, so the application of inheritance and object instantiation is

not backed up semantically. For RT-Z, in contrast, whose base formalism Z does not provide

any top-level structuring operators, we needed to define these structuring operators as a

part of the integration itself.

In TCOZ, as already indicated, the base formalisms Object-Z and timed CSP are closely

integrated, leading to a monolithic formalism rather than to a relatively independent coex-

istence of two complementary base formalisms (as is the case in RT-Z). The interdependence

between the elements of timed CSP and Object-Z is strong: the timed CSP syntax is exten-

sively changed by the introduction of new operators that allow the definition of the dynamic

behaviour to refer to the object state. This strong interdependence between the two notations

makes it more difficult to reuse the infrastructure of the base formalisms, e.g., tool support,

proof support, the semantic models, etc.

On the other hand, the close integration of the Object-Z and timed CSP notations in TCOZ

leads to a high notational flexibility and convenience compared with conserving integrations

11.2. TCOZ 177

such as RT-Z. For instance, the possibility to directly refer to state variables within value ex-

pressions in timed CSP processes allows in many circumstances a more succinct specification

than is possible in RT-Z. As another example, the ability to associate operation parameters

with external channels avoids the need to explicitly specify aspects of parameter communi-

cation in the process definition, in cases where the information of the exact order and time

instants of parameter communications is not relevant. As mentioned, from a mere notational

point of view the structuring operators provided by TCOZ are very elaborated, in any case

superior to the concepts of simple and indexed aggregation offered by RT-Z.

Semantic Models

We contrast the approaches to defining the semantic models of TCOZ and RT-Z. In the

following we emphasise the main differences between these approaches and the resulting

merits and drawbacks.

Invocation/Termination Events vs. Sequences of Update Events. TCOZ is a monolithic in-

tegration. Because of the chosen syntactic integration—each operation schema can be re-

ferred to as a process—operations and processes must be identified semantically. The imme-

diate consequence was to identify each operation schema with a set of sequences of so-called

update events, where an update event represents the update of a single state variable. We

contrast the TCOZ approach of associating each operation application with a sequence of

update events with the RT-Z approach of associating each operation application with an

invocation and termination event.

The abstraction of interpreting an operation application as a sequence of updates of state

variables is, from our point of view, on a fairly concrete level, not adequate for the needs of

the requirements and early design phases. There, one is in general not interested in making

statements or reasoning about the changes of individual state variables. Certainly, a real

implementation is not able to perform a complete state change instantaneously; therefore,

interpreting an operation application as a sequence of state variable updates is adequate for

the description of an implementation on a very concrete level. But even on a concrete level

it is not really adequate to consider updates of single state variables as atomic events: if

one considers a sequence of elements as a single state variable, it is certainly not possible to

update all elements of the sequence instantaneously; therefore, the advantage that the TCOZ

semantic model is closer to real implementations is only of a relative nature.

Moreover, not considering state changes as atomic events means that the concept of state in-

variants, which is central to Z, cannot be adopted in TCOZ, because a potential state invari-

ant would be valid only between different operation applications. Furthermore, the iden-

tification of operations with sequences of update events appears not to be consistent with

the notion of Z data refinement. An abstract state with nstate components can be refined

in Z by a concrete state with m(6=n) state components; but in the TCOZ model, an oper-

ation application in the abstract system is represented by a sequence of nevents, whereas

in the concrete system it is represented by a sequence of mevents, between which the CSP

refinement notion cannot hold.

178 Chapter 11. Comparison with Related Formalisms

Parallel Composition. The TCOZ semantics allows parallel processes (within a single ob-

ject) to apply operations in parallel.4The resulting effect on the object state is that the parallel

processes have to synchronise on the individual updates of the state variables that are in the

intersection of the delta lists of their operation schemas. In other words, only those value

changes of state variables in the delta lists of concurrently applied operations are allowed

by the whole process that are individually allowed by all operations. If the concurrently ap-

plied operations specify inconsistent constraints for at least one common variable, the whole

parallel process deadlocks. The resulting constraint on the state change is hence in effect a

conjunction of the constraints of the operations that are composed in parallel.

At first glance, the ability to arrange different operations of a single object in parallel pro-

cesses is a powerful feature of TCOZ, not provided by RT-Z. However, since operations in

parallel operations have to synchronise on all update events, the specified behaviour is not

really parallel.5

(P1; Op1; Q1) k(P2; Op2; Q2) = (P1kP2); (Op1∧Op2); (Q1kQ2)

Let us illustrate the shortcomings caused by this semantic definition by means of three ex-

amples.

The parallel composition of the operations Op1aand Op1bin the first example seems to be

unproblematic from the semantic point of view, because their delta lists are disjoint, so their

state changes do not interfere.

State == [ x,y:N]

Op1a== [ ∆(x)|x06=x]; Op1b== [ ∆(y)|y0=x]

MAIN b=Op1a;e→Skip ke→Op1b

According to the TCOZ semantics, the state changes caused by the operations refer to the

pre state that is present when the whole parallel process starts. Thus, the value of yafter the

termination of Op1bequals the value of xbefore the process starts. This seems to contradict

intuition, because Op1amust have completed its state change before Op1bis invoked (be-

cause of synchronisation e). It would thus seem more intuitive if Op1bwould assign ythe

value of xthat Op1ahas computed.

The operations in the second example have a common element in their delta list, namely x.

4This is a contrast to RT-Z, where parallel operations must be encapsulated in different specification units.

5For the TCOZ definition of parallel composition to work, it would in fact be necessary that each operation

schema is mapped semantically to the deterministic choice of the order and values of the update events al-

lowed by the operation schema. In contrast, the TCOZ semantics actually specifies a nondeterministic choice.

This means that a parallel composition of operations can arbitrarily deadlock which does not seem to be the

intended interpretation of the parallel application of operations. To define a deterministic choice with respect

to the order and the values of state variable updates, however, would make the semantic definition of TCOZ

extremely more difficult.

11.2. TCOZ 179

State == [ x:N]

Op2a== [ ∆(x)|x0>x]; Op2b== [ ∆(x)|x0<x]

MAIN b=Op2a;e→Skip ke→Op2b

The operations define an inconsistent state change for this variable so a deadlock results.

Intuition would suggest that Op2ais performed before Op2bsuch that two changes of xtake

place.

In the last example, the state change that is specified by the whole parallel composition is

that the value 4is assigned to x. The parallel composition degenerates to a conjunction of

the two operations.

State == [ x:N]

Op3a== [ ∆(x)|x0>3 ]; Op3b== [ ∆(x)|x0<5 ]

MAIN b=Op3a||| Op3b

Also this is counterintuitive because two seemingly independently applied operations have

to agree on the common state change. The realisation of such a specification is absolutely

unclear, because in order to agree on a common state change the parallel subprocesses must

somehow communicate (via a channel not recorded in the list of synchronisation channels).

To conclude, while it would be useful to permit the parallel application of operations within

a single object, the particular semantic definition of TCOZ does not achieve this goal.

Structuring Mechanisms. Object-Z extends Z with different concepts and operators beyond

the pure class construct, e.g., inheritance and object instantiation. The semantic definition of

TCOZ does not refer to the semantics of Object-Z at all, but it refers only to the Z semantics

of schemas and expressions. So, it is not clear how these additional constructs, which are

the very reason to prefer Object-Z over Z, are defined. According to the TCOZ language

description and case studies, these additional operators of Object-Z are part of TCOZ and

are the only means for decomposing a TCOZ specification.

Embedding of Z Semantics. When comparing the semantic definitions of TCOZ and RT-Z,

the embedding of the Z semantics into the overall semantic model appears to be more seam-

less in TCOZ, because the semantics of Z is referred to at only two points: when referring

to the meaning of an operation and when referring to the meaning of a state guard. The

process of deriving the timed failures semantics of the Z part of an RT-Z specification unit is

undeniably more complex; however, the TCOZ definition does not take into account that the

meaning of an operation schema cannot be derived in isolation, because it usually depends

on the state schema and other global constants. So, the meaning of an operation schema

can be defined only in the context of a complete Z specification, and if this was taken into

account in TCOZ, the embedding of the Z semantics would have a comparable complexity.

Finally, there are some features that have played an important rˆ

ole in the design of RT-Z, but

have no counterpart in TCOZ.

180 Chapter 11. Comparison with Related Formalisms

•TCOZ classes can be compared with concrete specification units of RT-Z. There are,

however, no counterparts of abstract specification units in TCOZ. This makes it diffi-

cult to use TCOZ in the early phases of a development process.

•In TCOZ, it is not possible to specify assumptions about the behaviour of the environ-

ment at the external interface (cf. ENVIRONMENTAL ASSUMPTIONS section in RT-Z).

•In TCOZ, channels are type-heterogeneous, i.e., not associated with a type. This is

a restriction of the interface specification whose reason is not clear to us. We think

that the type of values transmitted via a certain channel is a very relevant piece of

information.

11.3 Object-Z / CSP

In this section, we contrast RT-Z and the integration of Object-Z and CSP proposed by Smith

and Derrick [2001] and discuss their benefits and drawbacks.

As already indicated in Chapter 4, although both integrated formalisms are conserving in-

tegrations, the underlying principles of integrating the base notations are different. While

Object-Z/CSP separates its base notations in different layers of an overall system specifica-

tion, RT-Z separates the base notations in different parts of a single component specification.

This entails the following consequences.

The Object-Z/CSP integration is a conserving integration in the true sense of the word, be-

cause the base notations are strictly separated from each other. This means that the benefits

attributed to the class of conserving integrations in Chapter 5 apply maximally.

The drawback of the layering approach, however, is that CSP is used to specify only archi-

tectural aspects, i.e., the configuration of system components and their interaction. In other

words, the CSP notation is not used on the (fine-grained) component level, e.g., to fix the

temporal ordering of operation applications.

11.4 LOTOS

LOTOS, as introduced in Section 4.4, has several strengths that have strongly influenced the

design of RT-Z.

A major strength of LOTOS are its modularity concepts:

•LOTOS allows the hierarchical decomposition of a system specification into compon-

ent descriptions (process definitions).

•Process definitions are parametrised and can thus be instantiated differently in distinct

contexts, which supports the reuse of process definitions.

•The interface of a process is explicitly specified in terms of a list of formal gates.

11.4. LOTOS 181

process P1 (pre : State) :=

In1 ?input:T1 ; ...

choice post : State, output : T2 []

[Op1(pre, post, input, output)] --> ... ;

Out1 !output ; P2(post)

[]

In2 ?input:T1 ; ...

choice post : State, output : T2 []

[Op2(pre, post, input, output)] --> ... ;

Out2 !output ; P3(post)

[] ...

endproc

process P2 (pre : State) := ...

process P3 (pre : State) := ...

sorts: State, T1, T2

opns: Op1, Op2, Op3 : State, State, T1, T2 --> Boolean

eqns: ...

Figure 11.1: Modelling a component as an EFSM.

These modularity concepts have influenced the design of the structuring operators of RT-Z

and also the design of the internal structure of specification units.

A very important contribution of LOTOS is the integration of the concepts “synchronisation”

and “value transmission.” This is achieved by associating actions with data types and by

associating synchronisations with the agreement on concrete values. This approach has been

adopted in RT-Z.

LOTOS has, on the other hand, several shortcomings that make it, from our point of view,

less adequate for the application domain of real-time embedded systems than RT-Z.

One serious disadvantage of LOTOS is that it does not provide any concept for explicitly

modelling the data state of a component. In general, the behaviour of a component depends

on the data values that have been communicated with the environment. Therefore, it must

be possible in LOTOS to reflect this value dimension of the past interaction of a component.

Providing no concepts to directly model the data state of a component, LOTOS must sim-

ulate this data state by means of the model of extended finite state machines (EFSM). The

specification of a component as an EFSM is illustrated in Figure 11.1.

An EFSM comprises a finite set of control states, transitions between these control states and

a data state associated with each control state. Each control state of the EFSM is modelled by

a separate LOTOS process (P1,P2,P3), and the data state is represented by introducing ad-

ditional data parameters (pre:State) for all these processes. Each transition in the EFSM

coincides with a transformation of the underlying data state; it is guarded by an external in-

182 Chapter 11. Comparison with Related Formalisms

teraction and can depend on a certain condition on the data state. A transition in the EFSM

is modelled by instantiating the process representing the destination control state with the

transformed data state by the process representing the source control state. The transforma-

tion of the data state that coincides with a transition in the EFSM is described by a relation

between the pre state, post state, inputs affecting the transformation and outputs resulting

from the transformation. In the algebraic language of LOTOS, ACT ONE, such a relation is

modelled by a boolean-typed function (Op1, Op2, Op3). This modelling is achieved in the

data type part of the LOTOS specification by means of a set of conditional equations stating

the properties the relation must satisfy.6

The outlined approach to simulating a data state by additional parameters and mutually re-

cursive process instantiations might be adequate in relatively simple cases in which the dy-

namic behaviour is not complex. A complex dynamic behaviour of a data-state–dependent

component, however, results in a complex EFSM with a variety of control states and transi-

tions and therefore in a large amount of LOTOS processes. This would it make hard to un-

derstand the specification; the process algebra LOTOS was not designed to construct EFSM

models (like for example the ISO language ESTELLE [ISO, 1997]).

The meaning of basic and full LOTOS is defined by an operational semantics identifying

each process with a labelled transition system (LTS). As a consequence of the use of an oper-

ational semantics, properties of processes can itself be expressed only in terms of processes,

where a refinement relationship must be proved between the process denoting a specifica-

tion (model) and the process denoting a property. Compared with a process algebra whose

meaning is defined by means of a denotational semantics, such as CSP, this way of specify-

ing properties of processes is on a rather concrete level. Specifying properties in terms of

predicates like in CSP is more abstract and more comprehensible.

LOTOS does not aim to specify real-time behaviour and thus does not provide any constructs

to do so. There are several proposed enhancements of LOTOS with real-time concepts [Bo-

lognesi et al., 1994, Bryans et al., 1995], but none of them has established as the real-time

enhancement of LOTOS.

The language used by LOTOS for specifying data types, ACT ONE, is an algebraic specifica-

tion language. Its undeniable advantage is the high level of abstraction in specifying abstract

data types; only properties are specified without fixing design decisions. This is particularly

useful in the early phase of requirements specification. On the other hand, ACT ONE does

not provide language constructs that are concrete enough to fix design decisions in the later

design phase.

6We are not completely able to assess the adequacy of specifying a state transition by means of a set of con-

ditional equations. We assume, however, that this is less adequate than the operators provided by a model-

oriented approach such as Z.

Chapter 12

Case Studies

We present two case studies in order to illustrate RT-Z, as defined in the previous two parts,

more intuitively. Another aim of the case studies is to demonstrate the appropriateness of

RT-Z for the domain of real-time embedded systems.

The first case study focuses on the ability of RT-Z to cope with real-time and complexity, and

the second case study deals with a safety-critical application.

12.1 Multi-lift System

The first case study illustrating RT-Z is the formal specification of a multi-lift system,1which

we have chosen for the following reasons. Firstly, a lift system is something people are

familiar with, so we are able to concentrate on discussing the features of RT-Z. Secondly, the

multi-lift system has the appropriate level of complexity. On the one hand, it is complex

enough to demonstrate the decomposition concepts of RT-Z, it is an inherently concurrent

system, and there are several real-time requirements to be met. On the other hand, it allows

us to apply an appropriate abstraction that is not overwhelming. Last but not least, the multi-

lift system has served other formalisms as a case study, e.g., TCOZ introduced by Mahony

and Dong [1998a], Object-Z and CSP. The RT-Z case study has been strongly influenced by

the TCOZ case study. In Section 12.1.4, we contrast our case study with the TCOZ case study.

12.1.1 Problem Description and System Architecture

We first explain the architecture of the multi-lift system as far as it is needed to define the

interface between the part of the system that is to be implemented by software, depicted

in Figure 12.1 by the rectangle named SoftwareController, and the other system components.

This system architecture is the result of the system design and taken as the input to our

development process.

1Strictly speaking, we do not specify an entire multi-lift system but a distributed software controller of such a

system.

183

184 Chapter 12. Case Studies

The considered multi-lift system consists of several lifts moving between the floors of a build-

ing. Each floor is equipped with a panel of buttons that allow users to make a request to

move upward or downward by pressing the corresponding request button.2Analogously,

each lift is equipped with a panel of request buttons, one for each floor of the building.

There is a central external request handler that manages external requests that are currently

pending. External requests are caused by pressing a button at a floor panel; they are to be

served in a ‘first-in-first-out’ manner. As soon as a lift becomes idle, i.e., it has no pending

internal request, the external request handler delivers the next external request to this lift.

Internal requests are caused by pressing a button at a lift panel. According to the above

statements, internal requests have priority over external requests: when internal requests

are pending, a lift serves the closest internal request in the current move direction.

When a lift enters a floor in order to serve a request, the door of the lift is first opened, then

kept open for a constant time period and is closed afterwards. Closing the door might be

blocked by an object. The state of the lift door and potential objects blocking a closing door

are detected by a door sensor. A door motor serves to execute the commands given by the lift

controller. The movement of a lift is controlled by its shaft component. It is not the aim of this

case study to formalise aspects of this component, e.g., how the component detects that the

next floor is reached, etc. Therefore, this component is considered to be part of the software

environment, and we model only the interface to it as well as important assumptions about

its real-time behaviour.

The following data type definitions are global with respect to the whole specification and

serve, among other things, to specify the kind of information that is communicated with the

environment of the software controller and between its components.

MoveDir ::= Up |Down

DoorMsg ::= Opened |Closed |Blocked

DoorCmd ::= OpenCmd |CloseCmd

The global constants floor num and lift num are parameters of the specification, denoting the

number of floors and lifts in the considered building,

floor num,lift num :N1

floor num >1

and the subsequent sets are needed in order to identify the lifts and floors in the building.

LID == 1 . . lift num

FID == 0 . . floor num

MFloors == 1 . . (floor num −1)

The following time constants are described in Table 12.1. They reflect characteristics of the

real-time behaviour of the lifts and their doors.

tclose,topen,twait,tmove,tacc/brk,tpriority :T

2Of course, the ground and the top floor are equipped with only one button.

12.1. Multi-lift System 185

time constant meaning

tclose time needed to close lift doors provided process of closing is not

blocked

topen time needed to open lift doors

twait length of interval in which lift doors must be kept open before

they can be closed

tmove time needed by a lift to move from a floor to the next in either

direction

tacc/brk additional time needed to accelerate in the start floor and to

break in the destination floor, respectively

tpriority length of time interval in which internal requests have priority

over external requests

Table 12.1: Time constants.

The derived time constant

tmax int schedule == 2 ∗floor num ∗(topen +twait +tclose +tmove + 2 ∗tacc/brk)

defines the maximal amount of time needed by a lift to go from the ground floor to the top

floor and to return back to the ground floor when all intermediate floors are to be served in

both directions, provided the doors of the lift are not blocked.

12.1.2 Requirements Specification

Let us first express the requirements to the software controller informally. The following

requirements should be understood as a selection from a complete list of requirements.

Req1:Internal requests have priority over external requests.

Req2:Each internal request is served after at least tmax int schedule time units provided the

doors of the corresponding lift are not blocked.

Req3:When there are no pending internal request for at least one lift, the oldest external

request is served (FIFO).

Req4:After the doors of a lift are opened, they remain open for at least twait time units.

The interface between the distributed software controller and its environment is defined in a

separate specification unit because it is needed in the requirements and the design specifica-

tion. The specification units representing both the requirements and the design specification

are defined as extensions of the following specification unit.

186 Chapter 12. Case Studies

SoftwareController

ext_

request

int_request

door_cmd

door_status

lift_move

lift_arrived

Floor

Ctrl Lift

Ctrl

floor panel

lift panel

door motor

lift shaft

door sensor

External

Request

Handler

Figure 12.1: Software controller interface.

SPEC.UNIT SoftwareControllerInterface

INTERFACE

Figure 12.1 shows the interface between the software controller and its environment. Ex-

ternal requests from a floor are transmitted along the channel ext request, where each re-

quest incorporates the floor from which it originates and the desired direction of move-

ment. Pushing a floor button causes it to be activated until the request is served. Pushing

an already activated button has no consequence. Internal requests from a lift are trans-

mitted along the channel int request, where each request contains the lift from which it

originates and the target floor. The door of each lift is linked with its sensor via the chan-

nel door status, and it gives commands to its actuator along the channel door cmd. Fur-

ther, each lift gives its shaft component the command to move to a particular floor via

the the channel lift move, and it awaits the completion of such a command on the channel

lift arrived.

port ext request domain FID ×MoveDir;

port int request domain LID ×FID;

port door status domain LID ×DoorMsg;

port door cmd domain LID ×DoorCmd;

port lift move,lift arrived domain LID ×FID

The abstract specification unit SoftwareControllerReqs constitutes the requirements specifica-

tion of the distributed software controller of the multi-lift system.

12.1. Multi-lift System 187

SPEC.UNIT SoftwareControllerReqs EXTENDS SoftwareControllerInterface

ENVIRONMENTAL ASSUMPTIONS

Since the door sensors, the door motors and the shaft components of the lifts are part of

the environment, we can express only assumptions about their behaviour at the software

interface. If these assumptions are violated by these components, the software controller is

free to behave arbitrarily. These assumptions are formalised by the following predicates.

EA b=EA1∧EA2∧EA3∧EA4

First, the door motor of each lift is always supposed to accept each possible command on

the channel door cmd.

EA1b=∀t:T;cmd :DoorCmd;lift :LID •door cmd.(lift,cmd)open t

Second, the shaft component of a lift is assumed to accept the command to move to a floor

when not executing a prior moving command.

EA2b=∀t:T;lift :LID;floor :FID •

(sttr ({f:FID •lift arrived.(lift,f)}∪{f:FID •lift move.(lift,f)})|ttr t=hi ⇒

lift move.(lift,floor)open t)

∧

(last(sttr ({f:FID •lift arrived.(lift,f)}∪{f:FID •lift move.(lift,f)})|ttr t)∈

{f:FID •lift arrived.(lift,f)}

⇒

lift move.(lift,floor)open t)

∧

0≤#(sttr {f:FID •lift move.(lift,f)}ttr t)−

#(sttr {f:FID •lift arrived.(lift,f)}ttr t)≤1

There is a further assumption that is related to the real-time behaviour of the shaft com-

ponent. Whenever a lift controller transmits a command via the channel lift move to move

to a particular floor, the shaft component is supposed to accomplish this command within

a particular time interval that depends on the number of floors to be moved.

EA3b=∀t:T;lift :LID;floor :FID •

∃1last :FID |

(∃t1 : [0,t)•lift arrived.(lift,last)at t1∧

(∀t2 : (t1,t); f:FID • ¬ lift arrived.(lift,f)at t2))

∨

¬(∃t1 : [0,t); f:FID •lift arrived.(lift,f)at t1) ∧last = 0 •

lift move.(lift,floor)at t

⇒

lift arrived.(lift,floor)open from (t+Rabs(floor −last)∗Rtmove +R2∗Rtacc/brk)

Finally, the process of closing the door of a lift is supposed to be completed after tclose time

units, provided the door is not blocked by an object.

188 Chapter 12. Case Studies

EA4b=∀lift :LID;t1 : T•

door cmd.(lift,CloseCmd)at t1

∧

¬(∃t2 : [t1,t1 + tclose]•door status.(lift,Blocked)open t2)

⇒

door status.(lift,Closed)open from (t1 +Rtclose)

BEHAVIOURAL PROPERTIES

The following requirements Req1to Req4correspond to the four requirements described

informally.

Behaviour sat Req1∧Req2∧Req3∧Req4

We first introduce two parametrised process definitions in order to make the definition

of the requirements more intelligible. The predicate ExtPending expresses that an external

request (f,dir)made at time t1is still pending at t2, i.e., not served by any lift between t1

and t2. Similarly, the predicate IntPending states that an internal request fmade in lift lat

t1is still pending at t2, i.e., not served between t1and t2.

ExtPending(f,dir,t1,t2) b=

ext request.(f,dir)at t1

∧ ¬ (∃t: (t1,t2); l:LID •lift move.(l,f)at t)

IntPending(l,f,t1,t2) b=

int request.(l,f)at t1

∧ ¬ (∃t: (t1,t2) •lift move.(l,f)at t)

Internal requests have priority over external requests. In other words, when the controller

of a particular lift gives the command to go to a particular floor that is related to an external

request,athere must not be any pending internal request.

Req1b=∀t:T;l:LID;f:FID •

lift move.(l,f)at t

∧(∃t1 : [0,t); dir :MoveDir •ExtPending(f,dir,t1,t))

∧ ¬ (∃t1 : [0,t)•IntPending(l,f,t1,t))

⇒

¬(∃f2 : FID;t1 : [0,t)•IntPending(l,f2,t1,t))

Each internal request must be served after at least tmax int schedule time units provided the

doors of the corresponding lift are not blocked.

Req2b=∀l:LID;t:T;f:FID •

(∀t:T• ¬ door status.(l,Blocked)open t)

∧int request.(l,f)at t

⇒

(∃t2 : [t,t+Rtmax int schedule]•lift move.(l,f)live from t2)

abecause all prior internal requests for this floor are already served

12.1. Multi-lift System 189

When there are no pending internal request for at least one lift, the oldest external request

must be served.

Req3b=∀t,t1 : T;f:FID;dir :MoveDir •

(∃l:LID • ∀ t1 : [0,t); f:FID • ¬ IntPending(l,f,t1,t))

∧t1⩽Rt∧ExtPending(f,dir,t1,t)

∧ ¬ (∃f2 : FID;dir2 : MoveDir;t2 : T•t2<Rt1∧ExtPending(f2,dir2,t2,t))

⇒

(∃l:LID •lift move.(l,f)live from t)

After the doors of a lift are opened, they must remain open for at least twait time units.

Req4b=∀t:T;l:LID •

door status.(l,Opened)at t

⇒

¬(∃t1 : [t,t+twait]•door cmd.(l,CloseCmd)live t1)

This completes the requirements specification. By distributing predicates to the ENVIR-

ONMENTAL ASSUMPTIONS and BEHAVIOURAL PROPERTIES sections, we have unambigu-

ously stated which requirements are related to the software controller under consideration

and which requirements are related to its environment. The predicate language of RT-Z al-

lows us to express all requirements on an abstract level without fixing any implementation

aspects.

12.1.3 Design Specification

We now present the architectural design of the software controller of the multi-lift system,

see Figure 12.2. We discuss the specification units that constitute the design specification in a

top–down order for the high abstraction levels (top-level units) combined with a bottom–up

order for the lower abstraction levels. We think that a system is preferably explained by first

describing the coarse structures before delving into the details.

SPEC.UNIT SoftwareControllerDesign EXTENDS SoftwareControllerInterface

SUBUNITS

The components of the software controller are the controllers of the floor panels and of the

lifts and a component that handles the pending external requests.

subunit floors spec.unit FloorCtrls;

subunit lifts spec.unit LiftCtrls;

subunit erh spec.unit ExternalRequestHandler

190 Chapter 12. Case Studies

SoftwareController

ext_

request

int_request

door_cmd

door_status

lift_move

lift_arrived

ext_enter

interm_ext_req

interm_ext_succ

interm_ext_fail

next_ext_req

next_ext_resp

ext_served

External

Request

Handler

FloorCtrl LiftCtrl

Figure 12.2: Software controller architecture.

LOCAL

The channels that serve to connect the components of the software controller without be-

ing part of the external interface are declared in the LOCAL section. An external request is

passed on by the involved floor controller to the external request handler along the chan-

nel ext enter. A lift that has completed an external request reports this to the respective

floor controller along the channel ext served, which causes the deactivation of the respect-

ive button. Whenever a lift has no pending internal requests, it instructs the external re-

quest handler to provide the next external request in its queue via the channel next ext req,

which in turn is delivered by the external request handler via the channel next ext resp.

Whenever a lift schedules a new internal request, it sends a request along the channel

interm ext req whether the external request handler has an external request in its queue

between the current and the target floor in the current move direction. This request is

replied via the channels interm ext succ and interm ext fail, respectively.

channel ext enter domain FID ×MoveDir;

channel ext served domain FID ×MoveDir;

channel interm ext req domain LID ×FID ×FID;

channel interm ext succ domain LID ×FID;

channel interm ext fail,next ext req domain LID;

channel next ext resp domain LID ×FID ×MoveDir

ENVIRONMENTAL ASSUMPTIONS

The environmental assumptions made by the design are identical with that of the require-

ments specification. They are hence omitted. In general, the design specification is able to

weaken the environmental assumptions of the requirements specification.

BEHAVIOUR

The following abbreviation definition introduces ChannelSet to denote the set of events that

can be communicated along particular channels. It is referred to in the following behaviour

definition.

12.1. Multi-lift System 191

ChannelSet b={| next ext resp |} ∪ {| next ext req |} ∪ {| interm ext req |}

∪{| interm ext succ |} ∪ {| interm ext fail |}

The process term Behaviour defines the configuration of the components of the software

controller including their interaction along particular channels. Basically, the components

are composed in parallel, synchronising on the given set of internal channels.

Behaviour b=

floors.Behaviour

|[{| ext enter |} ∪ {| ext served |} ]|

(erh.Behaviour |[ChannelSet ]|lifts.Behaviour)

The previous specification unit defines the top-level structure of the software controller. We

now switch to the bottom–up order. That is, we first define the basic specification units of

which the components of the software controller are composed.

SPEC.UNIT Button

The current specification unit defines the behaviour of ‘raw’ buttons as they can be found

on the floors. They are raw in that their interface is not ready to be put into the floor context.

Lifting the button interface into this context is the aim of the following specification units.

INTERFACE

A button can be turned on and off represented by events occurring on the channels turn on

and turn off. Moreover its status can be requested via the channel status, and the current

status is reported either via the channel button on or button off.

port status,turn on,turn off,button on,button off domain SYNC

BEHAVIOUR

Behaviour b=Off

Off b=turn on →On

turn off →Off

status →button off →Off

On b=turn off →Off

turn on →On

status →button on →On

192 Chapter 12. Case Studies

SPEC.UNIT FloorButton[dir]

The previous unit serves to model the behaviour of a button independently of its particular

context. The current, parametrised unit serves to lift the Button unit into the context of a

floor panel, where it has to handle either upward or downward requests, depending on

the instantiation of the parameter dir.

TYPES & CONSTANTS

The formal parameter dir, recorded in the head of the specification unit, is declared form-

ally in the TYPES & CONSTANTS section.

dir :MoveDir

SUBUNITS

subunit button spec.unit Button

INTERFACE

The current unit lifts a raw button to a button accepting downward/upward requests at

a particular floor. Pressing the request button is modelled by an event on the channel

ext request. If it is deactivated when being pressed, then it sends an event to the external

request handler along the channel ext enter. The occurrence of an event on the channel

ext served indicates that the request is served.

port ext request,ext enter,ext served domain MoveDir

LOCAL

The interface of a raw button, which is encapsulated by the current unit, is introduced as a

list of internal channels.

channel status,turn on,turn off,button on,button off domain SYNC

BEHAVIOUR

External events occurring at the external interface are passed on to the interface of the raw

button, and the resulting reaction of the raw button is passed on to the external interface.

Downward as well as upward requests are transmitted along the channel ext request,

where the current unit reacts only to Down or Up requests, depending on the instantiation

of the parameter dir. The behaviour of the aggregated raw button is composed in parallel

with a process that is responsible for mapping the external to the corresponding internal

events.

12.1. Multi-lift System 193

Behaviour b=

FB |[{status,turn on,turn off,button on,button off}]|button.Behaviour

FB b= (Request Serviced); FB

Request b=ext request.dir →status →

(button off →turn on →ext enter.dir →Skip

button on →Skip)

Serviced b=ext served.dir →status →

(button on →turn off →Skip

button off →Skip)

SPEC.UNIT MiddleFloorCtrl

The current unit models the controller of a floor between the bottom and top floor. These

floors are equipped with a panel consisting of two buttons, handling downward and up-

ward requests, respectively. Accordingly, two button units are aggregated.

SUBUNITS

subunit up spec.unit FloorButton

instantiate dir with Up;

subunit down spec.unit FloorButton

instantiate dir with Down

INTERFACE

The interface of a middle floor controller is identical with the interface of an upward and

downward request button, where the two kinds of requests are accepted at the same time.

port ext request,ext enter,ext served domain MoveDir

BEHAVIOUR

The behaviour of a middle floor controller is simply the interleaving of the downward and

upward request buttons.

Behaviour b=up.Behaviour ||| down.Behaviour

The specification units TopFloorCtrl and BottomFloorCtrl, modelling the top and bottom floor

controllers, are defined in the obvious way and are hence omitted.

194 Chapter 12. Case Studies

SPEC.UNIT FloorCtrls

The controllers of the middle floors, the bottom floor and the top floor of the considered

building are aggregated by the current unit.

SUBUNITS

The controllers of the middle floors are composed by indexed aggregation, one for each

member of the set MFloors.

subunit mfloors(MFloors)spec.unit MiddleFloorCtrl;

subunit tfloor({floor num})spec.unit TopFloorCtrl;

subunit bfloor({0})spec.unit BottomFloorCtrl

Also the controllers of the top and the bottom floor are composed by means of indexed

(rather than simple) aggregation. At first glance, this might appear suspicious, because

there is only a single instance to be aggregated for each. However, indexed aggregation

with singleton sets is used instead of simple aggregation in order to lift the interfaces of

the top and bottom floor units automatically into the context.

The declaration introduces a collection of instances of the specification unit MiddleFloorCtrl,

one for each member of MFloors, a single instance of the unit TopFloor with the identifier

floor num and a single instance of the unit BottomFloor with the identifier 0. The interfaces

of all instances are obtained by enriching the type of each external channel, say T, with the

used index set, yielding FID×T. That is, each individual instance is addressed by using the

identifier of the respective instance as the first component of the value transmitted along

the considered external channel.

INTERFACE

In fact, the interface of the floor aggregation is identical with that of a single floor unit.

However, the domains of the channels are extended by the identifier of the floor that is the

source or destination.

port ext request,ext enter,ext served domain FID ×MoveDir

BEHAVIOUR

The behaviour of the overall floor aggregation is simply the interleaving of the controllers

of the middle floors, the bottom and the top floor, because they evolve independently of

each other.

Behaviour b= |||

id∈MFloors

mfloors.Behaviour(id)!

||| tfloor.Behaviour(floor num)||| bfloor.Behaviour(0)

12.1. Multi-lift System 195

SPEC.UNIT ExternalRequestHandler

The current unit is responsible for managing the external floor requests in a first-in-first-out

manner.

INTERFACE

Incoming external requests are transmitted by the floor panels along the channel ext enter.

There are two possibilities to assign an external request to a lift. First, when a lift be-

comes idle, it instructs the controller to provide a new external request via the channel

next ext req, and the controller assigns the first pending external request in its queue to

the lift via the channel next ext resp. Second, whenever a lift schedules a new internal re-

quest, it asks the external request handler for an appropriate external request between the

current floor and the target floor in the current move direction. This external request needs

not be the first in the queue, and it is transmitted along the channel interm ext succ in the

positive case.

port ext enter domain FID ×MoveDir;

port next ext req domain LID;

port next ext resp domain LID ×FID ×MoveDir;

port interm ext req domain LID ×FID ×FID;

port interm ext succ domain LID ×FID;

port interm ext fail domain LID

The above partitioning of the interface into ports carrying requests from other units and

ports carrying responses to these requests to the corresponding units is a general pattern.

Since the channels carrying operation-related events are internal in RT-Z, we cannot model

a ‘request–computation–response’ sequence by a single event; we must split it into at least

three events.

STATE

The data state of the external request handler consists of the queue of external requests

queue that are currently pending. The remaining state components are derived ones.

State

queue : seq(FID ×MoveDir)

up reqs,down reqs :FID ×FID →FFID

∀f1,f2 : FID |f1≤f2•

up reqs(f1,f2) = {f:FID |f7→ Up ∈ranqueue ∧f1<f<f2}

down reqs(f1,f2) = {f:FID |f7→ Down ∈ranqueue ∧f1<f<f2}

Initially, the queue is empty.

Init == [ State |queue =hi ]

196 Chapter 12. Case Studies

OPS & PREDS [ Join,FindSucc,FindFail,Dispatch,Empty,NonEmpty ]

The operation Join adds a new external request to the current queue.

Join == [ ∆State;req? : FID ×MoveDir |queue0=queue ahreq?i]

The aim of the next two operations is to determine a potential pending external request

in the queue that is situated between the current and the target floor in the current move

direction of a particular lift. They represent the successful case of finding an appropriate

external request and the corresponding failure case. Note that the preconditions of the two

operations partition the data state space.

FindSucc

∆State

curr fl?,curr dest?,new dest! : FID

curr fl?6=curr dest?

(∃1md == if curr fl?≤curr dest?then Up else Down •

(md =Up ∧up reqs(curr fl?,curr dest?) 6=∅∧

new dest! = min up reqs(curr fl?,curr dest?)

∨

md =Down ∧down reqs(curr dest?,curr fl?) 6=∅∧

new dest! = max down reqs(curr dest?,curr fl?)) ∧

queue0=squash(queue −

B{(new dest!,md)}))

FindFail

ΞState

curr fl?,curr dest? : FID

(∃1md == if curr fl?≤curr dest?then Up else Down •

md =Up ∧up reqs(curr fl?,curr dest?) = ∅

∨

md =Down ∧down reqs(curr dest?,curr fl?) = ∅)

The operation Dispatch removes the first external request from the queue.

Dispatch

∆State

req! : FID ×MoveDir

queue 6=hi

queue0=tail queue ∧req! = head queue

The schemas Empty and NonEmpty define predicates on the data state to which the specifi-

cation of the dynamic behaviour refers.

Empty == [ ΞState |queue =hi ]

NonEmpty == [ ΞState |queue 6=hi ]

12.1. Multi-lift System 197

BEHAVIOUR

The external request handler has to accomplish three main tasks. It has to insert new

external requests into its queue (process Join), it has to provide the first pending request

to an idle lift (process Dispatch) and it has to check whether there are appropriate pending

external requests on the itinerary of a lift (process Check).

The stimulus–response behaviour of the external request handler depends on its current

data state. When its queue is empty, it is able only to accept new external requests. Other-

wise it provides each of its three tasks to the environment. This dependence on the state is

modelled by the external choice whose branches are guarded by the state predicates Empty

and NonEmpty.

Behaviour b=ERH

ERH b=EmptyX→Join;ERH

NonEmptyX→(Join Dispatch Check); ERH

Join b=ext enter?req :FID ×MoveDir →JoinX!h| req? == req |i → Skip

Dispatch b=next ext req?lift :LID →DispatchX?par : [ req! : FID ×MoveDir ]→

next ext resp!(lift,par.req!) →Skip

Check b=interm ext req?req :LID ×FID ×FID →

(FindSuccX?par : [ curr fl?,curr dest?,new dest! : FID |

curr fl? = req.1∧curr dest? = req.2 ] →

interm ext succ!(req.0,par.new dest!) →Skip

FindFailX!h| curr fl? == req.1,curr dest? == req.2|i →

interm ext fail!(req.0) →Skip)

Let us illustrate the relationships between the Z operation schemas and the CSP events by

means of the process Check. The process first awaits a request from a lift on the channel

interm ext req. After such a request has been entered, the handler has to check whether it

has an appropriate external request in its queue. This is the task of the operations FindSucc

and FindFail whose execution events (with the postfix X) guard both branches of the ex-

ternal choice operator . In each data state of the handler, the precondition of exactly

one operation is satisfied, depending on whether an appropriate request is available. The

corresponding operation is executed which resolves the external choice.

Consider now the values that are communicated with the execution events of the opera-

tions.

On the one hand, the operation FindFail has only input parameters whose values are solely

fixed by the CSP process. Therefore, the value denotation of the CSP execution event is a

single binding that defines the mapping of input parameters to the values that have been

transmitted with the external event before.

198 Chapter 12. Case Studies

On the other hand, the operation FindSucc has input and output parameters. The values

of the input parameters are to be fixed by the invoking CSP process, whereas the values

of the output parameters are to be fixed by the invoked Z operation. Accordingly, a set of

values can be communicated with the execution event. The event denotation represents

a set of bindings mapping values to the input and output parameters in a way that the

values of the input parameters are uniquely determined and that the values of the output

parameters are arbitrary (constrained only by the operation schema). The set of bindings

is denoted by a schema expression.

SPEC.UNIT LiftCtrls

The controllers of the lifts of the considered building are aggregated by the current speci-

fication unit.

INTERFACE

port int request domain LID ×FID;

port ext served domain FID ×MoveDir;

port next ext req domain LID;

port next ext resp domain LID ×FID ×MoveDir;

port interm ext req domain LID ×FID ×FID;

port interm ext succ domain LID ×FID;

port interm ext fail domain LID;

port door status domain LID ×DoorMsg;

port door cmd domain LID ×DoorCmd;

port lift move,lift arrived domain LID ×FID

SUBUNITS

subunit lifts(LID)spec.unit LiftCtrl

TYPES & CONSTANTS

The set REN defines a mapping of the values transmitted along the channel ext served. It

is referred to in the BEHAVIOUR section.

REN == {l:LID;f:FID;md :MoveDir •ext served.(l,f,md)7→ ext served.(f,md)}

BEHAVIOUR

The lift controllers are composed by means of indexed aggregation using the interleaving

operator, which allows the different lift controllers to evolve independently of each other.

12.1. Multi-lift System 199

Internal

Queue

DoorCtrl

int_request lift_move

lift_arrived

next_ext_resp

next_ext_req

interm_ext_req

interm_ext_succ,

interm_ext_fail

ext_served

next_int_req

int_served

open_cmd

close_cmd

LiftCtrl

next_int_resp

door_cmd

door_status open_conf

close_conf

Supervisor

Figure 12.3: Lift controller architecture.

Technically speaking, the indexed aggregation has the consequence that the interaction of

individual lift controllers along particular channels is extended by the respective lift iden-

tifier. That is, all lift controllers communicate via the identical channels, but synchronise

on disjoint sets of transmitted values.

Behaviour b=REN |||

id∈LID

lifts.Behaviour(id)!

However, this extension of the domain is not appropriate for the external channel

ext served; because the floor controller that has made the request, whose completion is

to be reported, is not interested in the particular lift that has accomplished the request.

Therefore the renaming function REN is applied, which omits the lift identifier from each

communication on the channel ext served.

The architecture of a lift controller is illustrated in Figure 12.3. Each lift controller consists

of a component DoorCtrl controlling the opening and closing process of the lift door, a com-

ponent InternalQueue responsible for managing the set of current internal requests and a

component Supervisor responsible for supervising the other components. Since the ports of

the unit LiftCtrl have already been described, we outline only the internal channels.

The supervisor instructs the internal queue to provide the next internal request via the chan-

nel next int req, and the internal queue sends the respective internal request, if any, via the

channel next int resp. The supervisor informs the internal queue about the successful com-

pletion of an internal request via the channel int served.

The door controller is instructed to open and close via the channels open cmd and close cmd,

and it reports the successful completion of the opening and closing process via the channels

open conf and close conf, respectively.

200 Chapter 12. Case Studies

SPEC.UNIT LiftCtrl

SUBUNITS

A lift controller is the aggregation of a supervisor component, a door controller and an

internal queue of the activated panel buttons.

subunit queue spec.unit InternalQueue;

subunit supervisor spec.unit Supervisor;

subunit door spec.unit DoorCtrl

The ports and internal channels have already been discussed.

INTERFACE

The domains of the ports are obtained by omitting the set LID from the domains of the

corresponding ports of the specification unit LiftCtrls, which composes the current unit by

indexed aggregation.

port int request domain FID;

port ext served domain FID ×MoveDir;

port next ext req domain SYNC;

port next ext resp domain FID ×MoveDir;

port interm ext req domain FID ×FID;

port interm ext succ domain FID;

port interm ext fail domain SYNC;

port door status domain DoorMsg;

port door cmd domain DoorCmd;

port lift move,lift arrived domain FID

LOCAL

channel open cmd,close cmd,open conf,close conf domain SYNC;

channel next int req,next int resp domain FID ×MoveDir;

channel int served domain FID

BEHAVIOUR

The following abbreviation definition introduces ChannelSet to denote the set of events that

can be communicated along particular channels. It is referred to in the following behaviour

definition.

ChannelSet b={open cmd,close cmd,open conf,close conf} ∪ {| next int req |}∪

{| next int resp |} ∪ {| int served |}

The components of a lift controller are composed in parallel. The door controller and the

internal queue evolve completely independently, and they synchronise with the supervisor

through the events in ChannelSet.

12.1. Multi-lift System 201

Behaviour b=

supervisor.Behaviour

|[ChannelSet ]|

(door.Behaviour ||| queue.Behaviour)

SPEC.UNIT DoorCtrl

INTERFACE

The door controller is instructed by the supervisor component via the channels open cmd

and close cmd, it confirms the completion of these commands via the channels open conf

and close conf, it instructs the door motor via the channel door cmd and it asks the sensor

for the current state of the physical door via the channel door status.

port open cmd,close cmd,open conf,close conf domain SYNC;

port door status domain DoorMsg;

port door cmd domain DoorCmd

BEHAVIOUR

The behaviour of a lift door (and consequently of its controller) is simple. Whenever a lift

enters a target floor, the door goes through a cycle. The door is first opened, then remains

open for at least twait time units and is subsequently closed. The process of closing the door

may be interrupted, which is indicated by the door sensor. In this case, the door must be

re-opened before the next attempt to close the door can take place.

Behaviour b=OPEN

OPEN b=Wait twait;close cmd →CLOSING

CLOSING b=door cmd.CloseCmd →

(door status.Closed →close conf →CLOSED

4door status.Blocked →BLOCKED)

BLOCKED b=door cmd.OpenCmd →door status.Opened →Wait twait;CLOSING

CLOSED b=open cmd →OPENING

OPENING b=door cmd.OpenCmd →door status.Opened →open conf →OPEN

SPEC.UNIT InternalQueue

The internal queue of a lift is responsible for managing the pending internal requests.

There is no order on these internal requests.

202 Chapter 12. Case Studies

INTERFACE

New internal requests for a lift enter via the channel int request. The supervisor component

instructs the internal queue component via the channel next int req to provide the next

internal request on the lift’s itinerary, and this next internal request is delivered on the

channel next int resp. When an internal request is completed, it is reported on the channel

int served.

port next int req,next int resp domain FID ×MoveDir;

port int request,int served domain FID

STATE

The pending (unordered) internal requests are modelled by the set internal reqs. The re-

maining state components are derived ones used to specify the following operations more

conveniently. Initially, there is no pending internal request.

State

internal reqs :FFID

up reqs,down reqs :FID →FFID

up reqs =λfl:FID • {n:internal reqs |n≥fl}

down reqs =λfl:FID • {n:internal reqs |n≤fl}

Init

State

internal reqs =∅

OPS & PREDS [ Join,Dispatch,Next,Empty,NonEmpty ]

Join == [ ∆State;req? : FID |internal reqs0=internal reqs ∪ {req?}]

Dispatch == [ ∆State;req? : FID |internal reqs0=internal reqs \ {req?}]

The operation Next determines, for a given current floor and a current direction of move-

ment, the next pending internal request in the itinerary. The operation is divided into two

cases for each of the two move directions. The chosen requested floor is the closest floor in

the current move direction, where the move direction changes at the top and bottom floor.

NextUp

ΞState

fl?,dest! : FID

md?,md! : MoveDir

internal reqs 6=∅

md? = Up

(up reqs(fl?) 6=∅∧

dest! = min up reqs(fl?) ∧md! = Up)

∨

(up reqs(fl?) = ∅∧down reqs(fl?) 6=∅∧

dest! = max down reqs(fl?) ∧md! = Down)

NextDown

ΞState

fl?,dest! : FID

md?,md! : MoveDir

internal reqs 6=∅

md? = Down

(down reqs(fl?) 6=∅∧

dest! = max down reqs(fl?) ∧md! = Down)

∨

(down reqs(fl?) = ∅∧up reqs(fl?) 6=∅∧

dest! = min up reqs(fl?) ∧md! = Up)

12.1. Multi-lift System 203

Next == NextUp ∨NextDown

The following predicates are needed to express the dependence of the dynamic behaviour

on the current data state.

NonEmpty == [ ΞState |internal reqs 6=∅]

Empty == [ ΞState |internal reqs =∅]

BEHAVIOUR

The behaviour of the queue controller depends on the current data state. If there is no

pending internal request, the internal queue is not able to respond to a request to deliver

the next floor.

Behaviour b=IQ

IQ b= (NonEmptyX→(Request Serviced Select); IQ

EmptyX→(Request Serviced); IQ)

The queue controller must accomplish three main tasks. First, it has to react to new internal

requests by activating the corresponding button (process Request). Second, it has to react

to the completion of an internal request by deactivating the corresponding button (process

Serviced). Finally, it has to provide the lift controller with the next pending internal request

when being asked (process Select).

Request b=int request?fl:FID →JoinX!h| req? == fl|i → Skip

Serviced b=int served?fl:FID →DispatchX!h| req? == fl|i → Skip

Select b=next int req?req :FID ×MoveDir →

NextX?par : [ fl?,dest! : FID;md?,md! : MoveDir |fl? = req.0∧md? = req.1 ] →

next int resp!(par.dest!,par.md!) →Skip

SPEC.UNIT Supervisor

The current unit supervises the other components of the lift controller.

INTERFACE

port lift move,lift arrived domain FID;

port open cmd,close cmd,open conf,close conf domain SYNC;

port next int req,next int resp domain FID ×MoveDir;

port int served domain FID;

port next ext req domain SYNC;

port next ext resp,ext served domain FID ×MoveDir;

port interm ext req domain FID ×FID;

port interm ext succ domain FID;

port interm ext fail domain SYNC

204 Chapter 12. Case Studies

STATE

The data state consists of the current floor and move direction.

State == [ floor :FID;mdir :MoveDir ]

Init == [ State |floor = 0 ∧mdir =Up ]

BEHAVIOUR

The behaviour of the supervisor component is cyclic, expressed by a recursive equation. In

each cycle, it serves an internal or external request, defined by the processes InternalReq and

ExternalReq, respectively. Internal requests have priority over external requests. This is im-

plemented with the help of the timeout operator (.): during the first tpriority time units after

the last request has been accomplished, only internal requests are accepted; afterwards

internal and external requests are accepted equally, represented by the external choice.

Behaviour b=SV

SV b=σ(

InternalReq(floor,mdir)

.{tpriority}

(InternalReq(floor,mdir)ExternalReq)); SV

Note the use of the σoperator, which we have introduced in Section 7.1 as an abbreviation.

To obtain the next internal request on the itinerary, the supervisor needs to access its cur-

rent data state, incorporating the current floor (floor) and the current move direction (mdir).

As explained in Section 7.1, a dedicated operation Lookup is defined for each specification

unit, which provides the access to the current data state. The σ-notation is a shorthand for

the execution of this operation, represented by the event

LookupX?st : [ floor! : FID;mdir! : MoveDir ]

prefixing the process that is obtained from the process contained in the brackets of the

σ-operator by substituting st.floor!for floor and st.mdir!for mdir.

Whenever the lift controller schedules a new internal request it first checks whether there

is an external request between the current and the scheduled floor in the respective move

direction. If this is the case, the external request is first served; otherwise the internal

request is served.

InternalReq(fl,md)b=next int req!(fl,md)→next int resp?dest :FID ×MoveDir →

interm ext req!(fl,dest.0) →

(interm ext fail →HandleInternal(dest.0,dest.1)

interm ext succ?newdest :FID →HandleExternal(newdest,md))

ExternalReq b=next ext req →next ext resp?dest :FID ×MoveDir →

HandleExternal(dest.0,dest.1)

HandleInternal(fl,md)b=Move(fl,md); int served!fl→Skip

HandleExternal(fl,md)b=Move(fl,md); ext served!(fl,md)→Skip

12.1. Multi-lift System 205

Move(fl,md)b=close cmd →close conf →lift move!fl→lift arrived!fl→

open cmd →open conf →Updatefloor mdir(fl,md); Skip

The notation Updatefloor md(fl,md)is the counterpart of the σ-operator for updating the cur-

rent data state, also discussed in Section 7.1. It is a shorthand for the process that executes

the dedicated operation Updatefloor mdir and associates the operation parameters with the

provided values.

12.1.4 Discussion

The case study presented in this section demonstrates the ability of RT-Z to formally specify

a moderately complex, inherently concurrent and distributed system.

RT-Z has succeeded in modelling all relevant properties of the multi-lift controller, includ-

ing real-time constraints. It has coped with the complexity of the controller by applying

its decomposition concepts, i.e., simple and indexed aggregation and extension. The broad

spectrum of properties of the multi-lift controller has been addressed by the combined ex-

pressive power of Z and timed CSP as provided by RT-Z. Last but not least, we have covered

the (software) requirements specification and design phases, which involve different levels

of abstraction, by using abstract and concrete specification units.

However, we have not demonstrated that the design specification is a refinement of the re-

quirements specification, i.e., that it correctly implements the specified requirements. As dis-

cussed in Chapters 10 and 13, the verification techniques needed to bridge the gap between

abstract and concrete specification units are part of future work.

A more compact version of the multi-lift specification can also be found in [S¨

uhl, 2002].

Let us now discuss the differences between our case study and the TCOZ case study of the

multi-lift controller presented by Mahony and Dong [1998a].

The case study has revealed that the concept of object instantiation adopted in TCOZ is more

flexible than the concept of aggregation provided by RT-Z. Class objects in TCOZ can be

composed by the instantiating object by using arbitrary Z structures, e.g., sets and sequences.

In comparison, indexed aggregation is more restricted. However, the syntactical power of

object instantiation in TCOZ is impaired by its semantical undefinedness, as discussed in

detail in Chapter 11.

Disparate integration principles underlie RT-Z and TCOZ. In some cases, the RT-Z model,

which has no direct counterparts of state guards and of direct references from process ex-

pressions to state variables, gives rise to a larger and more complex specification than the

TCOZ model. An example of this is the need in the RT-Z specification to split the original

channel select of the TCOZ specification into the channels next ext req and next ext resp for

the discussed modelling reasons. On the one hand, this channel duplication makes the speci-

fication less succinct, always involving a pair of events rather than a single event. On the

other hand, modelling this communication relationship between the lift controllers and the

external request handler by means of two channels is closer to reality. No implementation

of the multi-lift specification is able to perform the state computation of the external request

206 Chapter 12. Case Studies

handler instantaneously; therefore, the events of demanding and providing an appropriate

external request have to be separated in time, i.e., modelled by two different events. To con-

clude, RT-Z forces the specifier to adopt a more concrete modelling style that is—concerning

the intervals of performing operations—closer to the real-time behaviour of the resulting

implementation.

A large part of the RT-Z specification is covered by the declaration of ports and channels. In

particular, the top-level specification units, which aggregate a number of other specification

units, have rather long declaration lists. The INTERFACE and LOCAL sections of compound

specification units are redundant, because they can be uniquely determined given the ex-

ternal ports and internal channels of the units being composed. In spite of this redundancy,

we have decided to make the interface of compound specification units explicit. This is a

contrast to TCOZ specifications, in which the interface of a compound object is not defined

explicitly. While this makes the TCOZ specification of the multi-lift controller more compact,

it is very hard to retain the overview: looking at the definition of a compound class, we have

no idea about its interface.

RT-Z’s ability to specify environmental assumptions enabled us to make a clearer separation

between the system to be implemented and its environment than in the TCOZ specification.

In the latter, the shaft component of a lift is part of the modelled system, because it is the only

possibility to express assumptions about its real-time behaviour. The RT-Z specification, on

the other hand, stipulated that the shaft component is outside the system to be implemented

by not incorporating a shaft specification unit but only recording the ports in the INTER-

FACE section that link the multi-lift controller to the shaft component. The ENVIRONMENTAL

ASSUMPTIONS section allowed us to express the assumptions about the real-time behaviour

formally that must be met for the multi-lift controller to operate reasonably.

Last, but not least, another difference between the RT-Z and the TCOZ specification, which

is not really caused by the different underlying models, is the order of presenting the speci-

fication units and classes, respectively. The TCOZ specification follows a strict bottom–up

order which is consistent with the ‘definition-before-use’ paradigm. In contrast, we have

deviated from this paradigm in the RT-Z specification, because in our opinion a system is

explained preferably by providing the coarse system structures (i.e., the top-level units) first

before giving the details (i.e., the bottom-level units).

12.2. Gas Burner 207

12.2 Gas Burner

To demonstrate the applicability of RT-Z to safety-critical systems, we discuss a case study

involving a gas burner, whose malfunctioning may cause accidents. The considered system

in terms of which safety constraints are to be formulated is a plant within which a gas burner

is to be operated.

Our case study was inspired by the case study presented by Ravn et al. [1993], which served

the authors to illustrate the duration calculus.

12.2.1 System Requirements

There are two safety constraints on the operation of the gas burner in the plant context.

1. The volume of unburned gas within the plant escaped from the gas burner must never

exceed a volume of max gas volume units.

2. Depending on specific objects in the surroundings of the gas burner within the plant,

the heat produced by the (activated or deactivated) gas burner must not exceed a par-

ticular temperature.

It is important to stress that the system that we specify by the following specification unit

is not the artifact we want to implement (gas burner). Rather, it is the system whose safety

is affected by the operation of the artifact to be implemented. That is, the general approach

taken is to take into account parts of the environment of the artifact to be implemented.

The following data types and constants are global with respect to the whole system specifica-

tion. The type definitions embody several abstractions we have carried out in modelling the

plant system. Temperature values, distances between objects and volumes are modelled by

natural numbers rather than by real numbers. Further, by introducing Object as a given set,

we express that we are not interested in the characteristics of the objects in the surroundings

of the gas burner.

[Object]

Temp == N;Dist == N;Vol == N

The following global variables represent static properties of the plant system, i.e., they are

parameters of the system specification.

max gas volume,min gas escape plant :Vol

max burner temp :Temp

max temp dist :Object 7→ (Dist →Temp)

∆ : T

∀o:Object;d1,d2 : Dist |o∈dommax temp dist ∧d1≤d2•

max temp dist o d1≤max temp dist o d2

In each time interval of length ∆,min gas escape plant volume units of gas are supposed to

escape from the plant. The function max temp dist assigns to each object a function mapping

208 Chapter 12. Case Studies

each distance of that object to the gas burner to the temperature that it can maximally sustain.

The constant max burner temp denotes the maximal temperature the gas burner can produce.

The first specification unit encapsulates the description of the interface between the plant

system and its environment. The encapsulation allows us to refer to these definitions several

times.

SPEC.UNIT PlantInterface

INTERFACE

Channels in a system specification do not necessarily carry the transmission of informa-

tion units, but they may carry the “flow of material units.” The escape of a particular

volume of gas from the plant to the environment is modelled by events on the channel

gas escape plant. Note that the model underlying RT-Z does not allow us to model a con-

tinuous escape of gas. The gas that escapes from the plant within an interval has to be

accumulated in a single event on the channel gas escape plant. Events occurring on the

channel object enter represent the entry of new objects into the plant, with a specific dis-

tance to the gas burner.

port gas escape plant domain Vol;

port object enter domain Object ×Dist

The specification unit Plant is defined to extend the previous one.

SPEC.UNIT Plant EXTENDS PlantInterface

ENVIRONMENTAL ASSUMPTIONS

Analogously to environmental assumptions of software components, which concern prop-

erties of information units, environmental assumptions of system components express

properties required of the material flows between system components.

EA b=EA1∧EA2

Regarding the plant system we assume that at least min gas escape plant volume units of

gas may escape from the plant in each interval of ∆time units.

EA1b=∀t:T|t⩾R∆•

Σ(strip(s↑ttr [t−R∆,t)ttr {| gas escape plant |})) ≥min gas escape plant

∨(∃vol :Vol |Σ(strip(s↑ttr [t−R∆,t)ttr {| gas escape plant |}))+vol

≥min gas escape plant •

gas escape plant.vol open t+ ∆)

Moreover, objects entering the plant must not be as close to the gas burner as to violate the

second safety constraint immediately.

12.2. Gas Burner 209

EA2b=∀t:T;o:Object;d:Dist •

object enter.(o,d)open t⇒(max temp dist o d)≥max burner temp

STATE PROPERTIES

The following state schema models the real state of the plant system. That is, each compon-

ent of the state schema represents a characteristic of the plant system that is really present

(observable).

State

gas volume :Vol

burner temp :Temp

object dist :Object 7→ Dist

gas volume ≤max gas volume

burner temp ≤max burner temp

domobject dist ⊆dommax temp dist

∀o:domobject dist •burner temp ≤max temp dist o (object dist o)

The predicate of the state schema mainly expresses the safety constraints on the operation

of the gas burner (first and last conjunct). The state schema is the natural place to formulate

safety constraints, because—by definition—safety is a property referring to the state of a

system, for a definition of safety consult [Leveson, 1995, pp. 181–183].

In conclusion, the above specification of the system requirements has indicated that RT-Z is

flexible enough to deal with general system components in addition to software components.

This is mainly due to the capabilities of the base language Z whose underlying concepts (set

theory and predicate logic) are general enough to enable the formulation of system and of

software properties.

We have also seen, however, that RT-Z is not able to model continuous behaviour. If the cor-

rectness of a system can be expressed only in terms of continuous functions and differential

equations, i.e., if the abstraction carried out with respect to the gas escape is not adequate,

RT-Z is not the appropriate choice. In this case, formalisms such as the duration calculus

[Chaochen et al., 1991] must be used.

12.2.2 System Design

To guarantee the safety constraints fixed in the system requirements phase, the plant sys-

tem is decomposed into the components depicted in Figure 12.4, which are associated with

specific responsibilities. The gas burner is equipped with a controller that monitors a ther-

mometer (sensor) and instructs a gas valve and an ignition source (actuators). The whole

gas burner is supervised by a human operator. The gas burner controller is responsible for

ensuring the first safety constraint, and the human operator is responsible for the second

safety constraint.

210 Chapter 12. Case Studies

gas valve

ignitor

gas burner

gas_out

human

operator

objects

plant

distance

controller

gas_escape_plant

object_enterignition

heat_on

heat_off

temperature thermometer

Figure 12.4: Plant design.

The volume of unburned gas in the plant escaped from the gas burner must not

exceed max gas volume units. According to the environmental assumptions, at least

min gas escape plant volume units are guaranteed to escape from the plant in each time in-

terval of length ∆. From the technical parameters of the gas burner one can derive how long

the gas burner may maximally leak unburned gas and how long the plant needs to reduce

the maximal amount of unburned gas to zero. Suppose that depending on these factors un-

burned gas is allowed to escape at most ∆2time units within any time interval of length ∆1.

It is decided in the system design that it is the task of the gas burner controller to guarantee

that constraint and that this controller is to be implemented by software.

The second safety constraint concerns the burner temperature that is maximally allowed,

which depends on the distance of objects to the gas burner. It is decided that it is primarily

the responsibility of the human operator to deactivate the gas burner early enough such that

the maximally admissible temperature is not exceeded for each approaching object. This,

however, requires that a command of the human operator to deactivate the gas burner is

executed by the controller timely. Two assumptions underlie the implementation of the

second safety constraint. First, it is supposed that the temperature in the surroundings of

the burner decreases with increasing distance according to a particular function. Second, it

is assumed that once the gas burner is switched off the flame will disappear and the tempera-

ture produced by the gas burner will decrease to the environmental temperature according

to a particular function.

The following specification unit aims to formally define the architecture of the plant sys-

tem as devised in the system design process discussed above. We fix only the structuring

into particular components and their interfaces here. We do not specify the requirements

associated with these system components; this is the subject of the following software re-

quirements phase.

SPEC.UNIT PlantDesign EXTENDS PlantInterface

SUBUNITS

subunit gas burner spec.unit GasBurner;

subunit human operator spec.unit . . .

subunit objects spec.unit . . .

12.2. Gas Burner 211

LOCAL

channel heat on,heat off domain SYNC;

channel distance domain . . .

BEHAVIOUR

Behaviour b= (gas burner.Behaviour |[{heat on,heat off}]|human operator.Behaviour)

|[{| distance |} ]|objects.Behaviour

In the remainder of this case study, we deal only with the gas burner, omitting the other

system components.

SPEC.UNIT GasBurner

INTERFACE

port heat on,heat off domain SYNC

SUBUNITS

subunit controller spec.unit GasBurnerControl;

subunit gas valve spec.unit . . .

subunit ignitor spec.unit . . .

subunit thermometer spec.unit . . .

LOCAL

channel temperature domain Temp;

channel gas out,ignition domain SYNC

BEHAVIOUR

Behaviour b=controller.Behaviour

|[{gas out,ignition} ∪ {| temperature |} ]|

(gas valve.Behaviour ||| ignitor.Behaviour ||| thermometer.Behaviour)

The sensor and actuator components of the gas burner would be designed in hardware de-

velopment processes. In the remainder of this case study, however, we address only the

development of the software controller.

212 Chapter 12. Case Studies

12.2.3 Software Requirements

The subject of the software requirements specification is the software controller identified

in the previous system design. More specifically, we are dealing with the requirements the

software controller must meet.

We first encapsulate the parameters and the interface of the software controller in separate

specification units, which allows us to refer to them several times.

SPEC.UNIT GBCConstants

TYPES & CONSTANTS

The time constants ∆1and ∆2have already been introduced informally in the previous

section, and ∆3models the length of the control cycles of the software component. The

existence of a control cycle is already fixed in the software requirements specification, be-

cause it has consequences on the expression of the software requirements. The constant

limit denotes the temperature above which the presence of a flame is assumed.

∆1,∆2,∆3:T

limit :Temp

0R<R∆3<R∆2<R∆1

SPEC.UNIT GBCInterface EXTENDS GBCConstants

INTERFACE

port temperature domain Temp;

port heat on,heat off domain SYNC;

port ignition,gas out domain SYNC

ENVIRONMENTAL ASSUMPTIONS

We assume that the software controller has the full and immediate control of the ignition

and the gas actuators. Moreover, the thermometer is supposed to deliver a unique tem-

perature at any time instant.

EA b=EA1∧EA2

EA1b=ignition active ∧gas out active

EA2b=∀t:T• ∃1meas :Temp •temperature.meas open t

The responsibility to ensure the safety constraints associated with the gas burner controller

12.2. Gas Burner 213

during the system design is expressed by the following specification unit.

SPEC.UNIT SafeGasBurnerControl EXTENDS GBCInterface

I/O RELATIONS

The following two Z schemas define the property of a temperature measurement to char-

acterise either the absence or the presence of a flame. They are referred to in the BEHAV-

IOURAL PROPERTIES section.

NotBurning == [ meas :Temp |meas <limit ]; Burning == [ meas :Temp |meas ≥limit ]

The subsequent specification of the safety constraints demonstrates one benefit of RT-Z,

namely the coherent integration of the property languages of Z and timed CSP.

BEHAVIOURAL PROPERTIES

The following auxiliary predicates characterise the states in which gas has escaped in the

current control cycle and where the last temperature measurement indicates the ignition

of gas or no ignition, respectively. The two predicates are used in the following predicates

defining the safety constraints.

UnignitedGas(t:T)b=NotBurning(meas b= last((sttr t)ttr {| temperature |})) ∧

∃t0: [t−R∆3,t)•gas out at t0

IgnitedGas(t:T)b=Burning(meas b= last((sttr t)ttr {| temperature |})) ∧

∃t0: [t−R∆3,t)•gas out at t0

Behaviour sat SC1∧SC2∧SC3

Firstly, there must not be any time interval longer than ∆2time units in which gas con-

stantly escapes and in which no flame is detected, i.e., in which gas constantly escapes

unignited.

SC1b=∀t1,t2 : T|t1⩽Rt2•

(∀t3 : [t1,t2) •UnignitedGas(t3)) ⇒t2−Rt1⩽R∆2

Secondly, two different attempts to ignite gas (two time instants at which gas escapes unig-

nited) between which there is a time instant at which a flame is detected have to be separ-

ated in time by at least ∆1time units.

214 Chapter 12. Case Studies

GasBurnerControl

flame_on,

flame_off gas_out,

ignition

heat_on, heat_off

temperature

function

flame

safety

Figure 12.5: Gas burner controller architecture.

SC2b=∀t1,t2 : T|t1⩽Rt2•

(UnignitedGas(t1) ∧UnignitedGas(t2) ∧ ∃ t3 : (t1,t2) •IgnitedGas(t3))

⇒t2−Rt1>R∆1

Finally, gas may escape and the ignition source may be activated only when the last com-

mand was a heat on command.

SC3b=∀t:T•

last(sttr tttr {heat on,heat off}) = heat off ⇒(¬gas out live t∧ ¬ ignition live t)

12.2.4 Software Design

In general, RT-Z is designed to formally specify real-time embedded systems and is thus not

specifically oriented towards safety-critical systems. However, it provides important means

for coping with safety-critical applications. In the following software design specification,

one means for enhancing the safety of the gas burner is the strict separation of functional and

safety aspects in different components (defined by specification units). The parallel compos-

ition operator of timed CSP is adequate to compose the functional and safety components,

because each communication with the environment (in particular commands to the actuat-

ors, which are subject to safety considerations) is possible only when the two components

agree on that communication.

12.2. Gas Burner 215

SPEC.UNIT GasBurnerControl EXTENDS GBCInterface

SUBUNITS

The current specification unit defines the decomposition of the software controller into

three components (see also Figure 12.5): one for ensuring the safety constraints, one for

accomplishing the function and one for detecting the transitions of the flame’s state.

subunit function spec.unit FuncComp;

subunit safety spec.unit SafetyComp;

subunit flame spec.unit FlameComp

LOCAL

channel flame on,flame off domain SYNC

BEHAVIOUR

The configuration of the three components is defined by the process term Behaviour. Most

important, the safety component and the functional component are composed in parallel;

and they synchronise on the commands to the actuators, which ensures that each command

is given only if the components agree on that command.

Behaviour b=

flame.Behaviour

|[{flame on,flame off}]|

(function.Behaviour

|[{gas out,ignition,flame on,flame off,heat on,heat off}]|

safety.Behaviour)

The safety component is responsible for guaranteeing that the outputs to the actuators are

given according to the safety constraints. In other words, it blocks the output of commands

that would violate these safety constraints. However, it does not take functional considera-

tions into account, i.e., it does not define when it is necessary to send particular commands.

SPEC.UNIT SafetyComp EXTENDS GBCConstants

INTERFACE

port flame on,flame off,heat on,heat off domain SYNC;

port gas out,ignition domain SYNC

LOCAL

channel flm on,flm off,first gas out domain SYNC;

channel enable1,disable1,enable2,disable2domain SYNC

216 Chapter 12. Case Studies

BEHAVIOUR

The following process terms defining the behaviour of the safety component are best un-

derstood by considering the state machine depicted in Figure 12.6, which is a direct trans-

lation of these process terms.

Behaviour b=BufferOff |[{flm on,flm off}]|

(GasIgnition |[{enable1,enable2,disable1,disable2}]|(SC1&2 ||| SC3))

The first two safety constraints are modelled by the process term SC1&2, and the last safety

constraint is modelled by SC3. The process terms express the corresponding safety con-

straints in terms of the events enable1,enable2,disable1and disable2. The two enable events

indicate that the corresponding safety constraint allows the escape of gas and the ignition.

The disable events have the analogous meaning.

The process term GasIgn models the safety component’s acceptance of the escape of gas and

of the ignition in terms of the enable and disable events. It is composed in parallel with the

two process terms modelling the safety constraints, where all three processes synchronise

on the enable and disable events. In brief, the escape of gas and the ignition is accepted if,

and only if, the parallel processes have lastly sent an enable event.

The task of the process term BufferOff, which in turn is composed in parallel with the

three process terms described above, is to buffer the external events flame on and flame off,

which are passed on by means of the internal events flm on and flm off. This decoupling

is necessary, because the safety component is always required to accept the two external

events.

BufferOff b=flame on →BufferOn flm off →BufferOff

BufferOn b=flame off →BufferOff flm on →BufferOn

GasIgnition b=GIDisabled

GIDisabled b=enable1→GIDisabled2enable2→GIDisabled1

GIDisabled1b=enable1→GIEnabled1disable2→GIDisabled ignition →GIDisabled1

GIDisabled2b=enable2→GIEnabled1disable1→GIDisabled

GIEnabled1b=ignition →GIEnabled1gas out →first gas out →GIEnabled2

disable1→GIDisabled1disable2→GIDisabled2

GIEnabled2b=ignition →GIEnabled2gas out →GIEnabled2

disable1→GIDisabled1disable2→GIDisabled2

SC1&2 b=enable1→SC1&2ENABLED

SC1&2ENABLED b=first gas out →SC1&2IGNITION

SC1&2IGNITION b=flm on →SC1&2BURNING

.{∆2}disable1→SC1&2DISABLED

SC1&2BURNING b= (flm off →disable1→Skip ||| Wait ∆1);

enable1→SC1&2ENABLED

SC1&2DISABLED b=Wait ∆1;enable1→SC1&2ENABLED

12.2. Gas Burner 217

disable1

enable1enable2

disable2

enable1 enable2

disable1 disable2

ignition

ignition gas_out

first_gas_out

flm_on

/enable1

heat_off

heat_on

heat_on/

enable2

heat_off/

disable2

ENABLED

gas_out/

first_gas_out

ignition

GasIgn

SC1&2 SC3

Disabled

ONE

Disabled2Disabled1

ENABLED

DISABLED

IGNITION

flm_off/

disable1

WAIT

DISABLED READY

BURNING

TWO

OFF

tm( )/enable1

∆1

tm( )/disable1

∆2

tm( )

∆1

Figure 12.6: State machine illustrating the behaviour of the safety component.

SC3b=SC3OFF

SC3OFF b=heat on →enable2→SC3ON heat off →SC3OFF

SC3ON b=heat off →disable2→SC3OFF heat on →SC3ON

The above process terms are a relatively direct translation of the safety constraints. They

are considerably simpler than a process description of the entire software controller, be-

cause they do not take into account functionality aspects.

Note that the safety component is always ready to engage in the events flame on,flame off,

heat on and heat off. This is necessary, because the flame component and the human op-

erator, respectively, must have the full control of these events. The safety component only

“consumes” these events. The same is true of the functionality component.

The functionality component is responsible for “pushing” the function of the software con-

troller. That is, it defines in a positive manner when it is necessary to send particular actuator

commands; it does so independently of safety concerns.

SPEC.UNIT FuncComp EXTENDS GBCConstants

INTERFACE

port heat on,heat off,flame on,flame off domain SYNC;

port ignition,gas out domain SYNC

218 Chapter 12. Case Studies

LOCAL

channel flm on,flm off domain SYNC

BEHAVIOUR

The following process terms defining the behaviour of the functional component are best

understood by considering the state machine depicted in Figure 12.7, which is a direct

translation of these process terms.

Behaviour b=Cycle |[{flm on,flm off}]|BufferOff

Cycle b=Idle 4(heat off →Cycle)

The process terms Idle,Ignition and Burning correspond to the states of the state machine.

Again, the task of the process term BufferOff is to buffer the external events flame on and

flame off, which are passed on by means of the internal events flm on and flm off.

BufferOff b=flame on →BufferOn flm off →BufferOff

BufferOn b=flame off →BufferOff flm on →BufferOn

The following three process terms define the recurring activities that are associated with

particular states of the state machine.

HeatOn b=heat on →HeatOn

GasIgn b=Wait ∆3;gas out →ignition →GasIgn

Gas b=Wait ∆3;gas out →Gas

Idle b=heat on →Ignition

Ignition b= (GasIgn ||| HeatOn)

4(flm on →Burning .{∆2}Idle)

Burning b= (Gas ||| HeatOn)

4(flm off →Idle)

The last component translates the measurements of the thermometer into events that indi-

cate that a flame appeared and disappeared, respectively. The other components have been

defined in terms of these produced events. The purpose of the flame component is thus to

define an abstraction for the safety and function component.

SPEC.UNIT FlameComp EXTENDS GBCConstants

INTERFACE

port temperature domain Temp;

port flame on,flame off domain SYNC

12.2. Gas Burner 219

BURNING

IGNITION

IDLE

heat_on

flm_onflm_off

heat_off

heat_on

tm( )

∆2

tm( )/

gas_out;

ignition

∆3

tm( )/

gas_out

∆3

Figure 12.7: State machine illustrating the behaviour of the functional component.

TYPES & CONSTANTS

Bool ::= Yes |No

STATE

The data state records the state of the flame at the last measurement. It is needed in order

to detect changes of the state of the flame. Initially, the flame is assumed to be off.

State == [ flame :Bool ]; Init == [ State |flame =No ]

OPS & PREDS [ NoChange,Appeared,Disappeared ]

The following operation schemas define all possible transitions of the flame’s state (includ-

ing the case that no transition takes place).

NoChange == [ ΞState;meas? : Temp |

flame =No ∧meas?<limit ∨flame =Yes ∧meas?≥limit ]

Appeared == [ ∆State;meas? : Temp |flame =No ∧meas?≥limit ∧flame0=Yes ]

Disappeared == [ ∆State;meas? : Temp |flame =Yes ∧meas?<limit ∧flame0=No ]

BEHAVIOUR

The behaviour of the flame component is cyclic. In a distance of ∆3time units, a meas-

urement of the thermometer is requested. The subsequent behaviour depends on the re-

lationship between the current data state and the received measurement val, determining

the unique operation whose precondition is satisfied and thereby resolving the choice. Ac-

cordingly, flame on,flame off or no event is performed.

220 Chapter 12. Case Studies

Behaviour b=Cycle

Cycle b=Wait ∆3;temperature?val :Temp →

(NoChangeX.h| meas? == val |i → Cycle

AppearedX.h| meas? == val |i → flame on →Cycle

DisappearedX.h| meas? == val |i → flame off →Cycle)

12.2.5 Discussion

To summarise, the gas burner case study has demonstrated the ability of RT-Z

•to cover different levels of abstraction, i.e., requirements and designs,

•to cover general system and software components and

•to cope with safety-critical applications.

The applicability of RT-Z to safety-critical systems is also demonstrated in [S¨

uhl, 2000],

where we have discussed the formal specification of a railway network.

We have, however, not established that our system and software designs really meet the

constraints expressed in the system and software requirements specifications, respectively.

As we discuss in the next chapter, the provision of verification techniques for RT-Z that

would allow us to prove that a given concrete specification unit refines an abstract one is

part of future work.

We have used a Statechart-like notation in order to discuss the behaviour of the safety and

the functional components, specified by timed CSP process terms. One might therefore be

tempted to conclude that Statecharts are a better candidate for being combined with Z. In-

deed this is the approach taken by the ESPRESS project, in which µSZ [B¨

ussow et al., 1997]—

a combination of Z and Statecharts—was developed. Statecharts are undoubtedly more

intuitive than CSP, because they are based on a graphical notation. However, they have

important drawbacks compared to CSP.

Firstly, the Statechart notation lacks a precise, complete and commonly accepted semantics.

There are several tools implementing Statecharts, and all have interpreted the notation in a

slightly different manner. Harel and Naamad [1996], e.g., have dealt with the meaning of the

Statechart notation as implemented in the STATEMATE tool. However, their semantic defi-

nition is on a rather low level of formality: it is basically an informal description of the step

algorithm implemented by STATEMATE in the context of illustrating examples. Further, the

described semantics does not have the useful characteristics of the denotational semantics

of CSP, e.g., compositionality. More recently, formal definitions of the Statechart semantics

have been proposed. Helke and Kamm¨

uller [2001], e.g., have formalised Statecharts based

on hierarchical automata using the HOL instance of the generic theorem prover Isabelle. So

far, however, only a subset of the language has been covered.

Secondly, in contrast to CSP, Statecharts are based on a model of asynchronous communi-

cation. From a theoretical point of view, asynchronous communication is less appropriate

12.2. Gas Burner 221

than synchronous communication when reasoning about the behaviour of compound sys-

tems. Moreover, (basic) Statecharts do not have any interface/encapsulation mechanism.

This makes it very difficult to model complex behaviour patterns, because a component

broadcasting a signal can give rise to reactions in all other components. The incorporation of

Statecharts into UML has alleviated this deficiency, because object-orientation provides the

necessary encapsulation mechanisms. However, the formal meaning of UML Statecharts is

even more a subject of current research.

In conclusion, while useful in illustrating the structural aspects of the behaviour of the safety

and functional components, Statecharts are not as appropriate as CSP to define this beha-

viour formally (and to reason about it).

222 Chapter 12. Case Studies

Chapter 13

Conclusions

We finally discuss the contributions of this thesis and some open issues remaining as subjects

for future work.

13.1 Contributions

The following points concern the contributions of RT-Z to the research field dealing with the

integration of formal specification languages.

Coherent Integration of Z and timed CSP. In this thesis, we have presented an integration

of Z and timed CSP that allows us to specify all relevant aspects of real-time embedded

systems in a coherent manner.

By developing the classification of approaches to integrating existing formalisms in

Chapter 5, we have given an overview of the different (and frequently mutually contra-

dictory) design rationales underlying different integrated formalisms. The classification has

established a basis for comparing RT-Z with the related work.

According to our classification, we have conceived RT-Z as a conserving integration. The

general benefits and drawbacks attributed to this class hence apply to the instance RT-Z.

Most important, by having encapsulated the notations of Z and timed CSP within two sep-

arate parts, we have pursued a separation of concerns. This has helped us in defining the

denotational semantics of RT-Z by reusing the semantic functions of the base formalisms and

in developing refinement techniques for RT-Z by reusing the refinement techniques of the

base formalisms. Moreover, the separation between the base formalisms enhances the intel-

ligibility of RT-Z specifications for those being familiar with Z and timed CSP and makes it

possible to use existing tools.

Coverage of Several Abstraction Levels. A distinguishing feature of RT-Z is that it cov-

ers several abstraction levels. All other approaches integrating (timed/untimed) CSP with

Z/Object-Z have integrated only the concrete language constructs of the respective base

223

224 Chapter 13. Conclusions

formalisms, resulting in integrated constructs that basically correspond to the concrete speci-

fication units of RT-Z. That is, they do not provide any counterparts of abstract specification

units.

To define the formal meaning of abstract specification units, we have formalised the use of

abstract data types in the predicate language of timed CSP. This use of abstract data types

within predicates is common in the literature on timed CSP [Schneider, 1999b, Chapter 12],

e.g., for quantifying over the time domain or over other data domains. However, this use

is not underpinned by the denotational (and operational) semantics of timed CSP. So, our

definitions can be regarded as a contribution to the formalisation of an aspect of the actual

use of timed CSP.

Further, the formalisation of timed CSP’s predicate language allowed us to include envir-

onmental assumptions in abstract and in concrete specification units. The ability to specify

environmental assumptions is essential; it assists in clearly separating concerns, because the

requirements to the system under consideration and the requirements to its environment

are specified in separate sections of a specification unit. Environmental assumptions are a

concept not provided by the other integrated formalisms explicitly.

Formal Foundation. We have formally defined the meaning of abstract and concrete speci-

fication units by means of a denotational semantics. Further, the meaning of the structuring

operators of RT-Z has been defined by adopting a transformational approach. This stepwise

semantic definition has been necessary, because a monolithic approach would have made it

impossible to reuse the semantic definitions of the base formalisms.

We have spent much effort in proving that the definition of the semantics of concrete speci-

fication units is consistent with the axioms of the timed failures model of timed CSP (Ap-

pendix B). The proof has been carried out in a mathematical way.1The consistency ensures

that the meaning that is associated with the Z part of a specification unit represents some

timed CSP process. Only this fact has entitled us to interpret a specification unit as the par-

allel composition of its two parts.

The formal definition of the semantics is the foundation for formal specification. Formal

specification is an activity that is useful in its own rights. This claim is supported by the

following points.

•Perhaps the most important advantage of a formal specification is its ability to clearly,

unambiguously express requirements, constraints and properties of a system. When

accompanied by appropriate informal explanations, a formal specification facilitates

the discussion between different stakeholders of the system development process.

•Formal specifications are in general, if a suitable abstraction has been identified, more

concise than corresponding informal descriptions.

1This certainly restricts the level of confidence as compared to a formal proof (e.g., by using a theorem prover).

However, the granularity of the proof is fine enough to convince us that the principles of the semantic defi-

nitions are sound.

13.1. Contributions 225

•Using a formal language, one is forced to think more rigorously about the considered

system, which helps gaining a deeper understanding of the system and its require-

ments. In fact, the early phases of the development process are extended due to a more

thorough analysis; but this investment is returned in the later phases.

•A formal requirements or design specification is a sound basis for the still indispens-

able task of black-box testing; on the basis of a formal specification one is able to derive

test cases to later exercise the implemented system as well as to decide on the correct-

ness of the system’s reactions.

However, the full potential of the mathematical basis of a formalism can only be exploited

by formal proof techniques that allow one to establish in a rigorous way that specifications

exhibit certain properties. As already stated, we have not yet defined a calculus for RT-Z

that would allow us to formally derive properties of RT-Z specification units. However, the

foundation for such a calculus has already been established. Its fundamental prerequisite is

the formal semantic definition, which we have accomplished. Moreover, we have designed

the integration of Z and timed CSP in such a way that proof obligations to a specification unit

can be reduced to separate proof obligations to its parts. These, in turn, can be discharged

by means of the proof techniques provided by the two base formalisms. This separation of

concerns, by the way, is the very essence of conserving integrations.

Formal Definition of Structuring Operators. We have chosen plain Z in favour of Object-Z,

fully aware of the fact that plain Z does not provide as elaborate structuring operators as

Object-Z. The reason for this choice has been our intention to use the combined express-

ive power of Z and timed CSP for the specification at both the component and the system

level. This is in contrast to the approach of Smith and Derrick [2001] who used Object-Z

to specify the behaviour of single components and CSP to specify the interactions between

components.

Having chosen plain Z, we needed to define our own structuring operators on top of the

integration. The structuring operators of RT-Z have been backed up by means of a trans-

formational approach, see Chapter 8. This separate definition is in contrast to TCOZ, for

which the authors claim that they can use for free the structuring operators of Object-Z as

containers for the integrated notation. However, as we have argued in detail in Chapter 11,

the semantics of these Object-Z operators is not defined for the integrated language.

Global Invariants. As discussed in Section 9.2.1, a major achievement of the semantic model

underlying RT-Z and at the same time a major source of complexity is its ability to cope with

the concurrent execution of operations that work on different subspaces of the overall data

state but which might nevertheless interact. This interaction is expressed in terms of global

invariants.

To the best of our knowledge, this concept is novel in the realm of integrated formalisms. It

is vital for our approach in the system-related phases in the context of safety-critical applica-

tions, because the safety of a system must be expressed in terms of its states: since the overall

state of a system may be distributed to several components, safety constraints may include

relationships between the states of different components. Expressing these relationships is

exactly the purpose of global invariants.

226 Chapter 13. Conclusions

Refinement. We have formally defined the notion of refinement between specification

units, and we have shown how to use the refinement techniques provided by Z and timed

CSP in order to establish the refinement relationship between specification units in RT-Z.

This connection has been underpinned by our proof in Appendix C that the existence of a

forward or backward simulation between the Z parts of two specification units implies the

refinement relationship between the corresponding timed CSP interpretations in the timed

failures model.

We have also demonstrated that refinement relationships between compound specification

units can be reduced to refinement relationships between pairs of corresponding component

specification units. This compositionality of the refinement relationship is a necessary pre-

condition for establishing refinement relationships between compound specification units in

a convenient manner.

13.2 Satisfaction of Objectives

Recall the objectives that we have formulated in Chapter 3. RT-Z, as presented in this thesis,

satisfies these objectives for the most part.

First, RT-Z is a formally defined specification language allowing one to clearly and precisely

express requirements, constraints and designs. It also allows the specifier to freely choose the

appropriate level of abstraction. Regarding rigour, we have already stated that we have not

yet provided verification techniques that would allow us to reason about RT-Z specifications

rigorously, but that we have established the foundation for such verification techniques, see

the discussion in the next section.

Second, the base formalisms of RT-Z have been intentionally chosen in order to cover the

relevant dimensions of the behaviour of real-time embedded systems. On the other hand,

we have deliberately dispensed with taking into account hybrid and stochastic behaviour,

which makes RT-Z tremendously simpler (however, with the drawback that some types of

embedded systems cannot be modelled adequately). So, to conclude, we think that we have

made a reasonable compromise between the expressiveness and the complexity of the model

underlying RT-Z.

Third, as demonstrated by the case studies in Chapter 12, the language constructs provided

by RT-Z allow us to cover the phases of the development process referred to in the objectives.

Last, but not least, the structuring operators of RT-Z, in particular aggregation and extension,

ensure the scalability of RT-Z. This is witnessed by the multi-lift case study in Section 12.1,

which concerns a moderately complex system.

13.3 Future Work

The following points concern the features that—in spite of being worthwhile—are not ac-

complished so far. Accomplishing these points would lift RT-Z from the level of formal

specification languages to the level of formal methods.

13.3. Future Work 227

Calculus. A prominent part of future work is the development of a calculus for RT-Z. It will

consist of a collection of axioms and inference rules allowing us to derive properties from an

RT-Z specification that are related to both behavioural and state-oriented aspects.

As stated in Chapter 6, an essential design rationale behind our integration of Z and timed

CSP has been the possibility to reuse the infrastructure of the base formalisms as far as pos-

sible. This applies particularly to the existing proof techniques of Z and timed CSP. The reuse

is facilitated by the separation of the base formalisms, as generally motivated in Chapter 5

for the class of conserving integrations.

In RT-Z, the notation used to express properties is the notation integrated in abstract specifi-

cation units. So, to be more precise, the purpose of the calculus we are striving for is to derive

properties, as expressed by abstract specification units, from models, as expressed by con-

crete specification units. A particular purpose of these rules will be the proof of refinement

relationships between abstract and concrete specification units.

The rules of the calculus we are aiming at will be related to two different tasks: first deriving

properties from a single specification unit; and second deriving properties from a compound

specification unit, given the properties of its components.

Considering the first task, the aim is to derive those properties of a concrete specification

unit that depend on both the Z part and the CSP part. These can be either properties that can

be expressed only by referring to the two parts, or it can be properties that can be proved only

by employing properties of the two parts. The axioms and inference rules will express the

mutual relationships between the base formalisms in a concrete specification unit as defined

by the semantic model in Chapter 9; they will reduce properties depending on the two parts

to properties depending on only one part, which can be discharged by applying the proof

techniques of the respective base formalisms. The rules will reflect the relationships (among

others)

•between a termination event and the post state resulting from executing the operation,

•between an invocation event and the pre state to which the operation is applied,

•between the value transmitted with a termination event (binding that associates each

output parameter with a value) and the output parameters of the corresponding oper-

ation, and

•between the value transmitted with an invocation event and the input parameters of

the corresponding operation

as defined by the semantics.

The second task deals with deriving properties of compound specification units from prop-

erties of their component specification units. The corresponding inference rules will reflect

the reduction processes defined for aggregation and extension in Chapter 8.

For both Z and timed CSP, there are techniques for formally deriving properties from speci-

fications. The sound and complete calculus of timed CSP is outlined in Section A.2.6. Z, by

contrast, is not equipped with such a complete calculus. However, since the Z notation is

based on predicate logic and set theory, the well-established mathematical techniques de-

veloped for these concepts can be used. Of particular interest are the proof tools developed

228 Chapter 13. Conclusions

for Z, e.g., HOL-Z [Kolyang et al., 1996] and Z/EVES [Saaltink, 1997], automating various

kinds of proof tasks.

Finally, the axioms and inference rules we are aiming at must be proved sound with respect

to the denotational semantics of RT-Z defined in Chapter 9. Completeness of these rules—

although being desirable—is not realistic.

Examples. In the following, we attempt to give an idea of the nature of the inference rules

we are striving for by means of some examples. All examples deal with deriving properties

from single specification units.

The first inference rule reflects the relationship between the precondition of an operation

schema, a data state in which the corresponding operation is invoked and the input par-

ameters transmitted with a corresponding invocation event. The two antecedents of the

inference rule are related only to the Z part of the concrete specification unit under analysis.

They can be discharged using the proof techniques of Z. The conclusion is related to the CSP

part: it makes a statement about the liveness of an invocation event.

Consider an operation schema Op with input parameters in1?, . . . , inN?. Suppose the data

state present at time tfulfils property Prop. Suppose further that Prop implies the precondi-

tion of Op, with the input parameters fixed to the values val1, . . . , valN.

(Precondition)

Prop at t

Prop ⇒pre[Op |in1? = val1∧. . . ∧inN? = valN ]

OpI.h| in1? == val1, . . . , inN? == valN |i live t

Then we can deduce that the invocation event related to this operation and associating the

input parameters with the given values is offered at time t.

The next rule concerns the relationship between the input parameters of an invocation event

and the output parameters of the corresponding termination event.

The first three antecedents refer only to the CSP part of the concrete specification unit under

analysis, namely to the occurrence of invocation and termination events. The last antecedent,

which assumes that the operation schema Op establishes a relationship between the input

and output parameters of each operation application, is related only to the Z part and can be

discharged using the proof techniques of Z.

(InOutputRel)

OpI.h| in1? == valI1, . . . , inN? == valIN |i at t1

OpT.h| out1! == valO1, . . . , outM! == valOM |i at t2

∀t3 : [t1,t2) • ¬ OpTat t3

Op `PropInOut[in1?/x1, . . . , inN?/xN,out1!/y1, . . . , outM!/yM]

PropInOut[valI1/x1, . . . , valIN/xN,valO1/y1, . . . , valOM/yM]

The conclusion transfers the established relationship to the particular values transmitted

with a pair consisting of an invocation and a termination event.

13.3. Future Work 229

The last rule deals with additional state invariants valid during certain time intervals. As-

sume we consider a certain subset of operations OpSet that preserve an implicit invariant Inv

in addition to the explicit state invariant State. This means that each operation of this subset

has to terminate in a post state satisfying this implicit invariant, provided it is applied to a

pre state satisfying it. Moreover, suppose we are able to show that within the interval (t,t0)

only termination and execution events belonging to this subset occur. Finally, if we know

that the last data state recorded before this interval fulfils the implicit invariant mentioned

above,

(PartialInvariant)

∀Op :OpSet •(Inv ⇒ ¬ (preOp)) ∨((Op ∧Inv)⇒Inv0)

Inv at t

sttr ({op :OPS \OpSet •TermOf op} ∪

{op :OPS \OpSet •ExecOf op})↑ttr (t,t0) = hi [OpSet ⊆OPS ]

∀t00 : (t,t0)•Inv at t00

then we can deduce that all data states during this interval fulfil this implicit invariant, too.

To conclude, the above examples should have made clear the principle that properties de-

pending on the two parts of a specification unit are reduced to properties depending only

on a single part.

Methodological Support. According to Grieskamp et al. [2001], “a major drawback of for-

mal techniques is that they are not easy to apply for the average software engineer. Besides

the facts that users of formal techniques need an appropriate education and have to deal

with lots of details, they are often left alone with a mere formalism without any guidance on

how to use it. Hence, methodological support is a key issue to bring formal techniques into

practice.” We acknowledge that this also applies to RT-Z. As mentioned above, a future goal

is to lift RT-Z to the level of formal methods.

Initial results towards this goal have already been achieved. In particular, in [Heisel and

S¨

uhl, 1997] we have presented methodological support for a predecessor of RT-Z. Heisel

[1997] has dealt with the methodological and machine support of formal techniques in the

context of software engineering more generally and more comprehensively.

Operational Semantics. There are several approaches to defining the semantics of specifi-

cation languages. In this thesis, we have used the denotational approach. The advantage

of the denotational approach has been the possibility to uniformly cover the concrete (e.g.,

process terms) and abstract language constructs (e.g., predicates).

There are, however, tasks for which an operational semantics is more appropriate. For in-

stance, if RT-Z is to be supported by a model checker (analogously to the support of CSP

by FDR [Formal Systems (Europe) Ltd, 2000]), an operational semantics is closer to the im-

plementation of a model checker than the denotational semantics. The definition of an op-

erational semantics must be accompanied by the demonstration of its congruence to the

denotational semantics.

230 Chapter 13. Conclusions

Formalisation in Isabelle/HOL. The formalisation of the semantic model of RT-Z in a the-

orem prover, e.g., the HOL instance of the generic theorem prover Isabelle [Paulson, 1996],

is a promising task. It would allow us to implement the calculus discussed above in that

theorem prover and thus to automate the process of discharging proof obligations. This

automation would also increase the level of confidence in the validity of proofs.

Formalising RT-Z in Isabelle/HOL need not begin from scratch. There are formalisations of

Z [Kolyang et al., 1996] and (plain) CSP [Tej and Wolff, 1997] in HOL/Isabelle, which could

be taken as a basis.

Other Tool Support. For RT-Z to be able to cope with more complex systems than those case

studies presented in the previous chapter, tool support is indispensable. We can distinguish

between two types of tool support for RT-Z specifications.

•Existing tools for Z that can be applied to the Z part of RT-Z specification units.

•Tools that are specific to RT-Z.

The latter ones would be applied to specification units as a whole, e.g., in order to check

dependencies between the parts. This would involve consistency checks and plausibility

checks, e.g.,

•the consistency of data domains associated with corresponding ports of two specifica-

tion units that are connected by aggregation;

•the presence of an operation schema in the Z part for each operation-related event

referred to in the CSP part;

•the reference of each (non-auxiliary) operation schema in the Z part by the CSP part.

Proof support for RT-Z, e.g., for checking refinement between specification units, would go

beyond mere consistency and plausibility checks. It would be based on a formalisation of

the denotational semantics (or a congruent operational semantics) of concrete and abstract

specification units and the transformation rules for aggregation and extension in a theorem

prover or model checker, or both.

To conclude, in developing RT-Z we have made substantial contributions to the research

field dealing with the integration of formalisms. Once the goals outlined in this section are

achieved, RT-Z can be regarded as a full-fledged formal method.

Part V

Appendices

231

Appendix A

Base Formalisms

In this appendix, we give a brief overview of the two specification languages that constitute

the integrated formalism RT-Z. The Z notation is dealt with in Section A.1, and timed CSP is

the subject of Section A.2. In Section A.2.8, we refer to some real-time approaches related to

timed CSP.

A.1 Z Notation

The Z notation is a formal specification language, which is in widespread use in academia

and—to a restricted extent—also in industry. It is a strongly typed language based on first-

order predicate logic and set theory.

We assume some familiarity with the Z notation throughout this thesis, for a detailed ac-

count of Z consult [Woodcock and Davies, 1996]. One of the merits of the Z notation is the

emerging international standard, which will certainly promote the production of tool sup-

port for Z and its further dissemination. In the remainder of this section, we briefly discuss

the definitions of the standard that we use in this thesis.

A.1.1 Standardisation

The ISO standard for Z is now near completion. The version of the standard to which we

refer throughout this thesis is the Draft International Standard [ISO, 2002]. We term this

document ‘Z Standard.’ In this section, we discuss the definitions of the Z Standard that we

need in this thesis, in particular for the definition of the semantics of the integrated formal-

ism RT-Z in Part III.

The scope of the Z Standard is the definition of the syntax, the type system and the semantics

of the Z notation. No method of using the Z notation is prescribed.

Concerning the syntax, the Z Standard introduces one main novelty compared with the ver-

sion of the Z notation defined in [Spivey, 1992]: Z specifications are structured into sections.

More precisely, a Z specification consists of a sequence of sections. Each section in a Z speci-

fication can inherit from other sections that precede it. Inheritance means that all definitions

233

234 Appendix A. Base Formalisms

in the inherited section are available in the inheriting section. There is a dedicated section

prelude, which is implicitly inherited by all sections of a Z specification; it contains general-

purpose definitions, e.g., the natural numbers.

The Z Standard defines the formal meaning of Z specifications by means of a denotational

semantics. Roughly speaking, the meaning of a Z specification is given “in terms of the

semantic values that its global variables may take consistent with the constraints imposed

on them by the specification” [ISO, 2002, p. 71].

The mathematical metalanguage used to define the denotational semantics is based on clas-

sical first-order logic and Zermelo–Fraenkel (ZF) set theory. It is similar in appearance to the

notation of Z itself. In ZF set theory, there are only sets. Members of sets can only be other

sets. Structures like tuples and natural numbers are not primitive in ZF set theory, but there

are well established ways of representing them, see [Hamilton, 1982] for details.

The Z Standard introduces the symbol Uto denote “the universe—a world of sets—provid-

ing semantic values for all Z expressions (including generic expressions)” [ISO, 2002]. Uis

assumed to be big enough to contain the set NAME, from which Z names are drawn, and

an infinite set. Further, Uis supposed to be closed under the formation of power sets and

products. According to the Z Standard [ISO, 2002], “the formation of a suitable Ucomprising

models of sets and tuples, as needed to model Z, is well-known in ZF set theory.” On this

basis, the symbol Wis introduced by the Z Standard to denote the world of semantic values

for Z expressions that are not generic, i.e., W⊂U.

The Z Standard proceeds with defining the structure of the denotations of Z specifications.

To this end, the symbol Model is introduced to denote the set of models, which associate

the names of global variables declared by a Z specification with semantic values (Model ==

NAME 7 7→ U), and SectionModels is introduced to denote the set of section models, which are

functions from section names to their sets of models (SectionModels == NAME 7 7→ PModel).

The semantics of the different syntactic categories of the Z notation—specifications, sections,

paragraphs, expressions, predicates and types—is defined by corresponding semantic rela-

tions from the Z syntax to the semantic universe in terms of operations of ZF set theory. We

deal only with the semantic relations to which we refer in this thesis.

•[[ spec ]]Zdenotes the meaning of the specification spec. The meaning of a Z specifica-

tion is a function mapping its section names to sets of models. For each section name of

a Z specification, each model related to that section name maps the global variables de-

clared in that section to a semantic value that is consistent with all constraints imposed

on the variable in that section.

•[[ pred ]]Pdenotes the meaning of the predicate pred. The meaning of a predicate is the

set of models in which the predicate is true.

•[[ expr ]]denotes the meaning of the expression expr. The meaning of an expression is

a function that maps each model to the semantic value that is the result of evaluating

the expression with respect to the given model.

Although the Z Standard does not prescribe any method of using the Z notation, the pre-

valent conventions of using the Z notation in a state-oriented way (i.e., as a model-based

A.2. Timed CSP 235

specification language) are described in an annex. Following these conventions, a system is

specified in terms of its states and the operations on these states.

We refer to these conventions in this thesis, because they reflect the way in which the Z

notation is used in the context of concrete specification units.

A.1.2 Discussion

Z is a powerful notation for describing and analysing a system in terms of its states and

operations. It is particularly adequate for systems whose primary nature is that of a data-

processing system, i.e., for systems that have a non-reactive nature.

The schema calculus is a characteristic feature of the Z notation, which makes it superior to

an unstructured use of mathematical logic and set theory. It provides means for structur-

ing Z specifications: “mathematical objects and their properties can be collected together in

schemas: patterns of declarations and constraints” [Woodcock and Davies, 1996].

Moreover, the Z notation is based on well-established and well comprehensible concepts,

namely set theory and predicate logic. This makes it relatively simple to learn using Z.

Another merit of Z is that it is strictly typed. Every entity in a Z specification has a unique

type. This allows one to type-check Z specifications which helps detect certain classes of

errors and improve the consistency of Z specifications.

In spite of these strengths, several drawbacks are attributed to the Z notation.

First, and most important, the Z notation is not designed to deal with behavioural aspects,

e.g., the temporal order in which operations are to be performed or the distinction between

operations that are to be available at the interface of a system and operations that have only

auxiliary purposes.

Second, it is not adequate to fix architectural aspects using the Z notation, because it is not

designed to define aspects of a system architecture such as concurrency, distribution or com-

munication.

Finally, the Z notation provides only rudimentary means for structuring specifications. Sche-

mas are the main facility of the Z notation to structure definitions, but they are not adequate

to decompose the specification of a complex system into encapsulated components.

These drawbacks have been our main motivation—and also the motivation of others—to

seek for a complementary formalism that has its strengths where the Z notation has its weak-

nesses. The next section deals with such a formalism.

A.2 Timed CSP

In this section, we introduce the real-time process algebra timed CSP. Since most people are

not familiar with timed CSP, we treat it in greater depth.

236 Appendix A. Base Formalisms

Timed CSP is a real-time extension of the more widespread process algebra CSP, originally

introduced by Hoare [1985] and further developed by Roscoe [1998]. We assume some fa-

miliarity with process algebras in general and with CSP in particular.1

Earlier versions of timed CSP (sometimes also termed real-time CSP) were described by

Schneider and Davies [Schneider, 1990, Davies, 1993, Davies and Schneider, 1995]. The ver-

sion of timed CSP that we use in this thesis is that treated by Schneider [1999b]. Our descrip-

tion of timed CSP in this section is closely based on the last reference.

Let us first outline the basic concepts underlying CSP. The language of Communicating Se-

quential Processes (CSP) was designed for the description and analysis of systems that con-

sist of interacting components. Components are described in CSP by processes. Processes are

thought of as being independent, self-contained entities with particular interfaces through

which they interact with their environment. Processes can be combined with other processes

to form larger processes, i.e., the way of describing processes is compositional.

Since processes interact with other processes only through their interface, the relevant in-

formation derived from a process description is its behaviour at the interface: the internal

structure of processes is not relevant when describing and analysing the behaviour of the

system that is constituted by these processes. The interface of a process consists of a set of

events. An event represents a particular kind of atomic action that can be performed with

the participation of the process. In describing a process, the first issue to be decided is the

set of events which it can perform. The interface of a process can be considered as its static

specification. Its dynamic specification describes how it will actually behave at the interface,

i.e., it describes the patterns of events in which it can participate.

The universe of events is denoted by Σ. Events are thought of as occurring on particular

channels, which link processes with each other. A channel can be associated with an alphabet,

containing the values that can be carried by events occurring on that channel. An event

occurring on a channel with an associated alphabet consists of two components: the channel

con which it occurs and the value vthat is carried by the event.2

The language of (untimed) CSP and its associated semantic models, e.g., the traces model

or the infinite failures–divergences model, are appropriate for specifying and analysing sys-

tems in terms of the order in which they can perform events. These models have deliberately

abstracted from timing aspects such as the precise times at which events occur or the delays

before events become enabled. For systems whose correct operation depends only on the

order in which events are performed, these semantic models provide the appropriate level

of abstraction, containing no unnecessary details.

Systems, by contrast, whose correct operation depends on the precise real-time behaviour

can be analysed only in the context of a semantic model that introduces an explicit notion of

time. Examples of relevant aspects of the real-time behaviour are maximal response times

or scheduling conditions. The language of timed CSP and its associated semantic model ex-

tend CSP in two ways in order to introduce a notion of time. First, the process operators of

1Fidge [1994] provides an overview of several process algebras and their underlying concepts.

2In the remainder of this section, we abstract from the “internal structure” of events by denoting them by

atomic identifiers.

A.2. Timed CSP 237

CSP are adopted and re-interpreted on a more concrete, timed level. Second, additional con-

structs are introduced that allow the precise description of time-sensitive behaviour. These

additional constructs are delay, timeout and timed interrupt.

This section is organised as follows. We introduce the language of timed CSP along with an

outline of its operational semantics in Section A.2.2. The properties of the timed transition

system that is induced by the operational semantics are discussed in Section A.2.3. The

structure of timed observations that can be made of processes and the denotational semantics

of timed CSP are treated in detail in Section A.2.4. Of particular interest when discussing the

denotational semantics is the treatment of recursion. Then, in Section A.2.5, the predicate

language of timed CSP is introduced, which allows one to specify properties that processes

are required to satisfy. Finally, we outline the calculus provided by timed CSP in order to

verify that processes satisfy specified properties.

A.2.1 Computational Model

We first discuss the assumptions that underlie the interpretation of timed CSP processes in

the context of real-time.

Instantaneous events: Timed CSP considers processes as concurrent, synchronising com-

ponents. Events represent synchronisations between concurrent processes. It is hence

natural to consider events as instantaneous, occurring at a single instant of time and

associated with no duration.

To model actions that need time, several events must be used in order to mark the

corresponding intervals.

Newtonian time: It is assumed that there is a single conceptual global clock. Time progresses

at a constant rate in all processes of a system with reference to this global clock. In this

way, the simultaneity of events occurring in concurrent processes can be judged. The

processes do not really read the global clock; rather it is a concept used to define the

meaning of processes.

Real-time: The time domain of timed CSP are the positive real numbers. There is hence no

minimal delay between events occurring at different time instants.

Maximal parallelism: Concurrent processes are supposed not to compete for resources, i.e.,

they are supposed to run on dedicated processors having sufficient processor time and

memory. This maximal parallelism assumption means that concurrent processes need

to synchronise only when this is explicitly specified. In particular, there are no implicit

scheduling assumptions. When scheduling is to be taken into account, it needs to be

modelled explicitly.

Maximal progress: An event occurs precisely when all participating processes are ready to

engage in it. An internal event, which does not require the participation of the process

environment, occurs as soon as the process is ready to perform it. An external event,

by contrast, requires the participation of the process and its environment: it occurs as

soon as both participants are ready to engage in it.

238 Appendix A. Base Formalisms

The computational model incorporates the most basic design decisions underlying the lan-

guage of timed CSP. It embodies the decisions which aspects of the system behaviour are

considered relevant (and can thus be modelled directly) and, conversely, from which other

aspects can be abstracted.

A.2.2 Process Term Language and Operational Semantics

In this section, we introduce the language of timed CSP processes, and its operational se-

mantics is defined in terms of the transitions that processes can undergo. The operational se-

mantics induces a timed labelled transition system, which contains all executions that timed

CSP processes can perform.

The possible executions of processes are described in terms of transitions. Due to the de-

cision to treat events as instantaneous, taking no time, transitions that represent the occur-

rence of events are not associated with the passage of time. Therefore, additional evolu-

tion transitions are introduced representing the progress of time. This separation of event

and evolution transitions has the advantage that the process operators already present in

(untimed) CSP can be defined consistently with their meaning in (untimed) CSP: the event

transitions can be adopted, and additional evolution transitions are defined.

In the timed context, the event transition Pµ

→P0means that process Pis immediately able to

perform event µ, and it will result in process P0when doing so. The transition from process

Pto process P0will take no time, i.e., the global clock will not change during the transition.

The evolution transition Pd

P0means that process Pis able to evolve for dtime units, and

will result in P0when doing so. After this transition, the state of the global clock will have

advanced by dtime units. During an evolution transition, no event transition can occur. If

Pis able to evolve through a sequence of states {Pi}over all time without performing any

events, then the abbreviation P∞

is used to denote this. Formally,

P∞

=∃{Pi}i∈N,{di}i∈N•(

∞

i=0

di=∞ ∧ P=P0∧ ∀ i•Pi

Pi+1).

In the following, we introduce all operators of the process term language of timed CSP. For

selected operators, we also provide their associated transition rules.

Performing Events

Deadlock. The timed CSP process Stop represents deadlock. Since this process is unable

to perform any event, no event transition rule is associated with it. On the other hand, the

process Stop allows time to progress, which results in the following evolution transition rule.

Stop d

Stop

A.2. Timed CSP 239

Event Prefix. The process a→Pis immediately ready to engage in the event a. It remains

in its initial state, continually offering a, until aoccurs. The subsequent behaviour is due to

P. Since events are instantaneous, control passes instantly to process Pwhen aoccurs. The

above is formalised by the following rules.

(a→P)a

→P(a→P)d

(a→P)

Timed Event Prefix. The process a@u →Pis a more general form of event prefix. It allows

us to record the time elapsed between the initial offer of the event a(the time the process

starts executing) and the occurrence of a. The time variable ucan have free occurrences in P;

it is bound at the instant of time at which aoccurs.

The process is immediately ready to engage in a, and offers acontinually until it occurs. The

subsequent behaviour is that of Pwith the time variable usubstituted by the time value at

which ahas occurred (the time elapsed between the process has started and ahas occurred).

Prefix Choice. The behaviour of the prefix choice x:A→P(x)is similar to that of the event

prefix. It is immediately ready to engage in each of the events in A. It remains in its initial

state, continually offering all events in A, until an event in A, say a, occurs. In this case, the

variable xis bound to a, and the subsequent behaviour is determined by P(a).

Successful Termination. The process Skip represents the process that is immediately ready

to terminate (modelled by the dedicated event X), remaining in this state until termination

occurs, and that deadlocks afterwards.

Note that the termination event is treated like a usual external event, i.e., the termination of

a process requires the participation of the environment.

Choice

Timeout. The timeout construction P.{d}Qprovides a time-sensitive choice between the

processes Pand Q. When the process starts execution, Phas control. If Pperforms an

external event within the first dtime units, then the choice is resolved in favour of P. It

may also perform internal events, but this does not resolve the choice. When, on the other

hand, dtime units have elapsed without Phaving performed an external event, a timeout

occurs and the choice is resolved in favour of Q, i.e., Pis discarded and control is passed to

Q, which starts executing at the instant of time at which the timeout occurs.

The transition rules for the timeout operator implement the mechanism that ensures that

internal events are urgent: the timeout is modelled by the internal event, which is denoted

by τ. It must occur exactly at the time instant when the timeout duration has elapsed. This is

achieved by ensuring that all evolution transitions cannot lead beyond the timeout duration:

when dtime units have elapsed, the only transition that is enabled is the event transition

related to the timeout. This forces the timeout event to occur precisely when the timeout

duration has elapsed.

240 Appendix A. Base Formalisms

Before the timeout occurs, the transitions of the whole timeout process are that of P.

Pµ

→P0µ∈ΣX

P.{d}Qµ

→P0

Pτ

→P0

P.{d}Qτ

→P0.{d}Q

Pd0

[d0≤d]

P.{d}Qd0

P0.{d−d0}QP.{0}Qτ

→Q

Delay. The process Wait d represents a delayed termination. It delays for exactly dtime

units, unable to perform any event, and is ready to terminate afterwards. This process is a

derived process defined as Stop .{d}Skip.

External Choice. The process PQprovides a choice between its component processes,

which is resolved in favour of the process that performs the first external event. The external

choice operator allows its component processes to evolve independently, enabling and with-

drawing events as time progresses. The occurrence of internal events does not resolve the

choice.

Note that the environment has control over the resolution of the choice by offering an initial

external event of either component process at a particular time instant.

Internal Choice. The process PuQbehaves either like Por like Q. Its environment, how-

ever, has no control over the resolution of this choice. It is not fixed when this choice is re-

solved. The resolution of this nondeterministic choice may be resolved by the implementor,

or it may be resolved only at run-time. Even at run-time, it can be delayed until the point

at which an event is performed that could be offered only by one of the two component

processes.

The internal choice operator must be considered as a specification construct. It defines a

process in terms of the alternative behaviours it can exhibit, but it gives the environment no

control over which alternative is chosen.

Indexed Internal Choice. The indexed internal choice ui∈IPigeneralises the binary internal

choice. The choice is resolved in favour of an arbitrary Piwith i∈I.

Concurrency

The assumptions underlying the computational model—in particular the maximal paral-

lelism, the maximal progress and the Newtonian time assumptions—have a direct impact

on the behaviour of concurrent processes. First, maximal parallelism in connection with

Newtonian time means that concurrent processes must always perform evolution transi-

tions together: they are not scheduled sequentially and time must progress at the same rate

A.2. Timed CSP 241

in all of them. Second, maximal progress forces events that are in the synchronisation set3

of concurrent processes to occur exactly when all participants are ready to engage in these

events.

Alphabetised Parallel. In the parallel composition P|[A|B]|Q, each of the component pro-

cesses is associated with an alphabet. Within the intersection of the alphabets, the com-

ponent processes must synchronise, and outside this intersection they can perform events

independently. Moreover, they must synchronise on termination. As mentioned, time must

progress at the same rate in all component processes.

Pµ

→P0

Qµ

→Q0µ∈(A∩B)X

P|[A|B]|Qµ

→P0|[A|B]|Q0

Pµ

→P0

[µ∈(A∪ {τ})\B]

P|[A|B]|Qµ

→P0|[A|B]|Q

Qµ

→Q0

[µ∈(B∪ {τ})\A]

P|[A|B]|Qµ

→P|[A|B]|Q0

P|[A|B]|Qd

P0|[A|B]|Q0

Interleaving. In the process P||| Q, the component processes can execute independently of

each other. Each external and internal event is performed by precisely one of the compon-

ents. The only exception is the termination event X: its occurrence requires the participation

of the component processes. Time must progress in the parallel processes at the same rate.

There is also an indexed form of interleaving |||i∈IPi, in which a collection of processes Pi

are interleaved, one process for each member of the index set I. The index set must be finite.

Since the binary interleaving operator is commutative and associative, indexed interleaving

can be traced back to the binary operator.

Interface Parallel. Interface parallel composition P|[A]|Qis a hybrid form, i.e., it combines

the features of the alphabetised parallel composition and interleaving. Pand Qmust syn-

chronise on all events in the interface set AX, and they interleave on all other events. Again,

time must progress in the parallel processes at the same rate.

3The synchronisation set is the set of events on which the parallel processes must synchronise.

242 Appendix A. Base Formalisms

There is also an indexed form of interface parallel composition ki∈I[A]Pi, in which a collec-

tion of processes Piare composed in parallel, one process for each member of the index set

I. All processes Pimust synchronise on events in the set AX, and they can perform events

outside this set independently. The index set must be finite. Since the binary interface par-

allel operator is commutative and associative, the indexed interface parallel operator can be

traced back to the binary one.

The interface parallel operator can be considered as the basic form of parallel composition

from which the alphabetised composition and the interleaving composition can be derived

as special cases.

Abstraction

Hiding. In the process P\A, all events in Aare hidden from the environment. Hiding

an event means to remove it from the process interface, so the environment is no longer

required to participate in its occurrence. The encapsulation achieved by the hiding operator

consists in identifying all processes that participate in an event.

The maximal progress assumption requires an event to occur when all participating pro-

cesses are ready to engage in it. This forces an internal event to become urgent. Urgency

is captured in the following transition rule by ensuring that evolution transitions are inhib-

ited when transition rules for internal events are enabled. That is, time is prevented from

progressing beyond points at which internal events are enabled. Accordingly, the evolution

transition rule has a negative premiss.

Pµ

→P0

[µ /∈A]

P\Aµ

→P0\A

→P0

[a∈A]

P\Aτ

→P0\A

∀a:A• ¬ ∃ P0•Pa

→P0

P\Ad

P0\A

As discussed in the next section, the set of events that are offered by a process does not

change during an evolution transition. This means with respect to the above evolution rule

that if no event in Ais possible for P, then no event in Awill be possible for P0. This ensures

that the maximal progress assumption is not violated, because no internal event can become

enabled during the evolution transition.

Renaming. The renaming operators allow the synchronisation events of a process to be

renamed. The renaming is achieved by means of a function f: Σ →Σsatisfying f(X) = X,

i.e., the termination event must not be renamed.

The forwardly renamed process f(P)is able to perform event f(a)whenever Pis able to

perform a. The timing behaviour is not affected. Note that the renaming function need not

A.2. Timed CSP 243

be injective. If it is not injective, then several events can be mapped to a single event. This

can lead to additional nondeterminisms in the renamed process.4

The backwardly renamed process f−1(P)is able to perform event awhenever Pis able to

perform f(a). Backward renaming does not introduce any additional nondeterminism, be-

cause different events performed by Pare always mapped to different events performed by

f−1(P). Again, the timing behaviour is not affected.

Flow of Control

Sequential Composition. The sequential composition (P;Q)starts with executing P. When

Pterminates successfully, which is indicated by the occurrence of the event X, then control

passes immediately from Pto Q. Urgency of Xin the context of sequential composition

means that it occurs precisely when the first process is ready to terminate.

Interrupt. The interrupt construction P4Qallows Pto execute, which can be interrupted

at any time by Qperforming an external event. In effect, Qis executed concurrently with P

until either Pterminates or Qperforms an interrupt event.

Unlike sequential composition, in the interrupt construction both Pand Qmust evolve to-

gether. The process Qis also able to perform internal events without triggering the interrupt;

this allows Qto offer and retract external events as time progresses.

Timed Interrupt. The timed interrupt construction P4dQallows Pto execute for exactly d

time units, after which the interrupt is triggered and control is passed to Q, unless Phas ter-

minated before the interrupt occurred. In contrast to the event-driven interrupt construction

discussed above, process Qis not performed concurrently with P, because its state does not

have any impact on triggering the interrupt.

Pµ

→P0

[µ6=X]

P4dQµ

→P04dQ

→P0

P4dQX

→P0

Pd0

[d0≤d]

P4dQd0

P04d−d0QP40Qτ

→Q

Recursion

Recursive process definitions N=Qconsist of a process variable Nand a timed CSP process

term Q, which may contain instances of N. The recursive invocation of a process takes no

time. Any delay required for recursive invocations must therefore be explicitly included. In

4Consider the function fb={a7→ c,b7→ c}and the process Pb= (a→P1)(b→P2), which is deterministic.

The process f(P) = (c→f(P1)) (c→f(P2)), however, is not deterministic, because it is equivalent to

c→(f(P1)uf(P2)).

244 Appendix A. Base Formalisms

this way the treatment of recursion is separated from timing considerations. The recursive

definition N=Qdoes really equate Nand Q.

In the mutual recursion construction N=Q, a collection of process variables Nare col-

lectively bound to a collection of process definitions Q, which may refer to those process

variables. Any process variable appearing in a process definition must be bound.

A.2.3 Timed Transition Systems

The transition rules of the operational semantics, which define the meaning of the process

constructors, induce a timed labelled transition system describing all possible executions of

timed CSP processes.

In this section, we deal with the properties of this transition system, which concern the re-

lationships between different transitions that might appear. These properties ensure that

processes behave in a natural and reasonable way. Some properties are concerned with the

way processes evolve through time, and others are concerned with the relationship between

evolution and event transitions. They allow us to gain a better understanding of the nature

of process executions.

Evolution Transitions

The following properties concern the relationships between evolution transitions.

Time determinism: Evolution transitions are deterministic, i.e., if a process evolves through

time, the result is unique. Alternative behaviours arise only because of event transi-

tions.

P0∧Pd

P00 ⇒P0≡P00

Time additivity: If process Pis able to evolve for dtime units resulting in process P0and if

process P0is able to evolve for d0time units resulting in process P00, then Pmust be

able to evolve for d+d0time units resulting in P00. In other words, the presence of an

intermediate process state P0does not influence the process state that is finally reached.

P0∧P0d0

P00 ⇒Pd+d0

P00

Time interpolation: Conversely, if process Pis able to evolve for d+d0time units resulting in

process P00, then it must have an intermediate process state P0at time d.

Pd+d0

P00 ⇒ ∃ P0•Pd

P0∧P0d0

P00

Time closure: If process Pis able to evolve for all durations less than d, it must also be able

to evolve for dtime units.

(∀d0:R+

0|d0<d• ∃ P0•Pd0

P0)⇒(∃P0•Pd

P0)

A.2. Timed CSP 245

An infinite sequence of evolution transitions can be described by an infinite sequence

of processes {Pi}i∈Nand durations {di}i∈N. Such a sequence is called Zeno sequence, if

the sum of all durations diis finite:

∞

i=0

di=d<∞.

Such a sequence indicates that process Pis able to evolve for all durations less than d

time units. The time closure property allows us to deduce that Pis also able to evolve

for dtime units. That is, all Zeno sequences have a limit process.

Together, the properties of time determinism and time interpolation ensure that each evolu-

tion transition passes through a unique continuum of process states.

Executions

An execution of a process is described in terms of an alternating sequence of process states

and transitions, where a transition may be an event transition or an evolution transition.

Each transition in an execution relates the two process states that are adjacent.

The properties of evolution transitions discussed above allow one to record evolution tran-

sitions more economically. First, time additivity allows one to collapse any adjacent pair of

evolution transitions Pd

P0and P0d0

P00 to a single evolution transition Pd+d0

P00. Second,

an infinite sequence of evolution transitions with initial process Pcan be collapsed in a sim-

ilar way by exploiting the time closure property. If the sum of the associated durations is

finite, then the infinite sequence can be collapsed into a single evolution transition Pd

P0;

otherwise, if the sum is infinite, it can be collapsed into the evolution transition P∞

Altogether, the properties of time additivity and time closure allow one to represent each

process execution as an alternating sequence of process states and transition labels that meets

the condition that an evolution transition must not be followed by another evolution transi-

tion.

An execution may be finite or infinite. It is called maximal, if it cannot be extended by further

transitions. An infinite execution must contain an infinite number of event transitions inter-

spersed with evolution transitions. A finite maximal execution either ends with a process

that cannot undergo an event or evolution transition; or it ends with the evolution transition

∞

Process executions have further useful properties, which concern the relationships between

event transitions the process can perform and the evolution transitions it can undergo.

Urgency of internal events: As a consequence of the maximal progress assumption, internal

events occur as soon as they are enabled. So, if a process can perform an internal event

it is not able to evolve for any duration.

Pτ

→ ⇒ (∀d:R+

0• ¬ Pd

)

246 Appendix A. Base Formalisms

This represents the mechanism of the operational semantics to treat internal events as

urgent.

Constancy of offers: The set of external event transitions that are enabled does not change

when time progresses, i.e., when a process undergoes an evolution transition. In other

words, when Pevolves to P0, then all events that Pcan perform must also be possible

for P0, and conversely, all events that P0can perform must have been possible for P.

P0⇒(∀a: ΣX•Pa

→ ⇔ P0a

→)

Any change of the set of events offered by a process must be accompanied by an event

transition.

Unrealistic behaviours: In the world of implementations, Newtonian time progresses at a

constant rate and cannot be blocked. The blockage of time is only a mechanism used by

the operational semantics in order to express the urgency of internal events. However,

it does not represent a reasonable behaviour in its own right, because it contradicts the

unstoppable nature of time.

For this reason, any maximal execution, which is to represent the behaviour of a real

process, must have an infinite duration, i.e., it must be possible to observe the process

forever. A maximal execution of a process that does not progress beyond a particu-

lar point of time is not consistent with Newtonian time. There are different kinds of

maximal executions with finite duration.

Timestop: A maximal execution can end with a process that is neither able to perform

an internal or external event neither to undergo an evolution. Such a process is

termed timestop, because it blocks time from progressing.

Spin: A maximal execution can have infinitely many transitions but only finitely many

evolution transitions. In such a sequence, all evolution transitions must appear

within an initial segment; the remaining segment contains only event transitions.

These event transitions occur at the same instant of time. Such an execution is

called spin execution.

Zeno: A maximal execution can consist of infinitely many evolution transitions; but

these could sum only to a finite duration. Such an execution is termed Zeno exe-

cution, because it approaches a time without reaching it.

All of these kinds of unrealistic behaviours can arise within the timed transition system

induced by the operational semantics; however, only in the context of recursive process

equations that are not time-guarded, see the next section.

Well-timed Processes

All of the finite duration maximal executions arise in the context of recursive process equa-

tions N=Qin which there is no sufficient delay between the time a process starts executing

and the time it is invoked recursively. When such a recursive invocation occurs immedi-

ately, timestops and spin executions may be caused; recursive invocations with ever redu-

cing delays may give rise to Zeno executions. These unrealistic behaviours are all prevented

by introducing a minimum positive delay before the time it is invoked recursively.

A.2. Timed CSP 247

A process term is t-guarded if any execution of that process term cannot reach a recursive

invocation in less than ttime units. A process term is time-guarded if there exists a t>0such

that it is t-guarded.

A timed CSP process is well-timed if all associated single and mutual recursive definitions are

time-guarded. Well-timed processes can never exhibit timestops, spin executions and Zeno

executions. This means that if a process is well-timed then all of its maximal executions have

infinite duration.

Finally, the executions of well-timed processes satisfy the property of finite variability. It

states that any finite time interval of an execution should contain only finitely many events.

Expressed the other way around: infinitely many events take infinitely long to occur.

A.2.4 Denotational Semantics

Processes in timed CSP are considered as interacting system components. That is, processes

are judged only in terms of their behaviour at the external interface; their internal imple-

mentation is not relevant. Thus, two processes that cannot be distinguished by any context,

into which they could be placed, are considered equal. In a timed setting, the context into

which a process is placed can be time-sensitive: it can make the offer of events dependent

on the progress of time.

The timed failures model is a semantic model for well-timed processes: it associates each process

with a set of timed failures. A timed failure is a record of a process execution, consisting of a

timed trace and a timed refusal.

The timed failures model is a compositional model; it formalises those aspects of the beha-

viour of a process that can be observed when interacting with it, and it abstracts from the

other aspects.

Timed Observations

When a process executes, it performs events at its external interface. A timed trace is a record

of performed events together with the times at which they were performed relative to the

starting point of the process execution. Internal events are not recorded in a timed trace,

because they are not visible to the environment.

Atimed event is drawn from the set R+

0×Σ, consisting of a time and an event. A timed trace

is a sequence of timed events in which the times are non-decreasing: the events are recorded

in temporal order.5

5Note that even events that occur at the same time instant are arranged in sequence, i.e., a temporal order

between such events is fixed in a timed trace.

On the one hand, this might appear counter-intuitive, because a causal relationship between simultaneous

events is suggested. On the other hand, there is an issue of compatibility between (untimed) CSP and timed

CSP: process expressions are used in both in order to define the temporal ordering of events. The processes

Pb=a→b→Stop

Qb=b→a→Stop

e.g., define two temporal orderings of the events aand b, which are contradictory. Thus, if the two are com-

248 Appendix A. Base Formalisms

A timed trace may be a record of a finite or infinite duration execution. If it corresponds to

a finite duration execution, then its length must be finite; this is dictated by finite variability.

Otherwise, it may be finite, if the execution contains only finitely many external events, or it

may be infinite. In the latter case, the times in the timed trace are not bounded.

Schneider [1999a] defined several functions on timed traces. They are treated in Appendix E.

The timed traces associated with a process can be determined from its executions. An exe-

cution, as introduced in Section A.2.3, is an alternating sequence of process states and transi-

tions, so it contains information about events that are performed and their associated times.

The timed traces associated with a process are those that are associated with its executions.

Processes interact with each other by synchronising on events at particular times. When

a process is offered the opportunity to perform an event, it can make one of two possible

responses. It can either perform the event, or else it can refuse to perform it. The timed trace

is a record of the timed events performed during an execution, whereas the timed refusal is

a record of which timed events were refused.

In the timed setting of timed CSP, event refusals must be considered at particular times

and not only at the end of the execution: refusal information is available throughout an

execution.6The refusal of an event aat time treflects the fact that ais not possible in the

process state reached at t. If the execution records the performance of several events at time

t, passing through several states, then the refusal information is associated with the last

of these states; the refusal information is subsequent to all events performed at that time

instant. Accordingly, the states of an execution associated with refusal information are those

states that are followed by an evolution.7

A timed refusal ℵis a set of timed events. Since refusals accompany evolutions, and event

offers are constant over evolutions, the same set of events will be refused throughout an

evolution. Refusal sets can therefore be structured such that the set of refused events is

finitely variable with respect to time. This means that a refusal set will record intervals over

which sets of events are refused. The appropriate intervals are half-open, corresponding to

the stable states along evolutions.

Schneider [1999a] defined several functions on timed refusals. They are described in Ap-

pendix E.

posed in parallel, the result should be deadlock.

PkQ≡Stop

If, however, the process PkQis considered in the timed setting of timed CSP and if there would be no tem-

poral order between events occurring at the same time, then the above equation would not be true, because

Pand Qare both able to perform aand bsimultaneously, so their parallel composition would also have this

ability.

This trade-off between intuition and the need to be compatible with CSP was resolved in timed CSP in favour

of compatibility.

6This is a contrast to the failures–divergences model of CSP, in which refusal information is available only for

the end of an execution.

7Note that an environment can offer a process several instances of a single event at a single time instant. It is

thus possible that an event is recorded for a particular time instant in the timed trace and in the timed refusal.

This means that the process performed as many instances of the event as recorded in the timed trace, but

refused to perform any further instance as witnessed by the membership of this event in the timed refusal.

A.2. Timed CSP 249

A timed refusal ℵis said to be consistent with an execution if every timed event (t,a)in

the timed refusal can be refused during the execution. This means that an atransition is not

possible for the particular process state reached at time tduring the execution. Several timed

refusals will be consistent with any particular execution. In particular, the empty set will

vacuously be consistent with any execution. Every execution will have a unique maximal

timed refusal consistent with it, containing all possible refused events for the duration of the

execution. A set ℵwill be consistent with an execution if, and only if, it is a subset of the

maximal timed refusal.

Processes are considered in terms of the possible observations that can be made of their

executions. These will be described in terms of timed traces and timed refusals. On the one

hand, every execution is associated with exactly one timed trace. On the other hand, the

events observed to be refused during the execution are not explicit in the transition. Possible

timed refusals are those that are consistent with the execution, but the observation of a timed

refusal depends on what was offered to the process during the execution: if nothing was

offered, then no events will be observed to be refused.

An observation of an execution is a timed failure (s,ℵ)consisting of a timed trace sand a

timed refusal ℵ. The timed trace sis the sequence of events occurring in the execution, and

the timed refusal ℵis some consistent set of timed events which could be refused during the

execution. A natural way to understand the pair (s,ℵ)as an observation of the process is as

evidence that it is able to perform the sequence of events s, and to refuse all events in the set

ℵif offered them while performing s. In general, it is a partial record of an execution.

A dual way to consider the pair (s,ℵ)is from the point of view of the environment. The

environment offers events at particular time instants: these offers are either accepted and

appear in s, or else they are refused and appear in ℵ. The timed failure thus provides a record

of all events that were offered to the process during the observation, indicating whether

they were accepted or refused. It may be considered as an experiment conducted by the

environment, offering particular events and eliciting responses.

Timed Failures Model

On the one hand, any timed CSP process is associated with a set of timed failures. On the

other hand, not every arbitrary set of timed failures represents a timed CSP process: there

are three properties (TF1–TF3) that must hold for any set of timed failures corresponding to

some timed CSP process. The timed failures model consists of all sets Sof timed failures that

meet these properties.

Firstly, the empty timed failure (hi,∅)must be a possible observation of any process (prop-

erty TF1).

Secondly, any set of timed failures corresponding to a timed CSP process must be down-

wards closed with respect to the information order8(property TF2). That is, for each timed

failure contained in S, the set must also contain all timed failures that capture its trace and

refusal information only partially, i.e., up to a particular time instant.

8Schneider defined the information order on timed failures as follows:

(s0,ℵ0)(s,ℵ)⇔ ∃ s00 •s=s0as00 ∧ ℵ0⊆ ℵ |tref beginttr(s00).

250 Appendix A. Base Formalisms

Finally, any timed failure (s,ℵ)is associated with a complete timed refusal: the timed refusal

ℵobserved can be augmented with further refusal information to obtain a complete timed

refusal ℵ0⊇ ℵ (property TF3). Completeness of ℵ0means that for any time t, any event a

not appearing in ℵ0must be possible for the process at that time. This manifests itself in two

ways:

C1: Any timed event (t,a)that does not appear in the timed refusal ℵ0must provide a pos-

sible alternative continuation to the timed trace. Refusal information at tis subsequent

to the timed trace up to and including that time, so the timed event (t,a)follows the

timed trace up to and including t.

C2: If an event ais not refused as time tis approached, then it is possible throughout the

evolution leading up to time t, so amust also be possible at time t. This is a consequence

of the constancy of event offers and the time closure for evolutions.9

These considerations are formalised as follows:

(hi,∅)∈S(TF1)

(∀s,s0:TimedTrace;ℵ,ℵ0:TimedRefusal •

(s,ℵ)∈S∧(s0,ℵ0)(s,ℵ)⇒(s0,ℵ0)∈S)(TF2)

(∀s:TimedTrace;ℵ:TimedRefusal |(s,ℵ)∈S•(TF3)

(∃ ℵ0:TimedRefusal | ℵ ⊆ ℵ0∧(s,ℵ0)∈S•

(∀t:R+

0;a:Event •

((t,a)/∈ ℵ0⇒((sttr t)ah(t,a)i,ℵ0|tref t)∈S)(C1)

∧

t>0∧ ¬ (∃:R\ {0} • [t−, t)× {a} ⊆ ℵ0)

⇒((s|ttr t)ah(t,a)i,ℵ0|tref t)∈S)))}(C2)

There is a further property TF4, which holds only for those sets of timed failures representing

timed CSP processes that do not introduce infinite nondeterminism. It states that the infinite

duration timed failures of such a process are exactly those that can be deduced from its finite

duration timed failures. In other words, the time closure of a set of timed failures associated

with such a process must be equal to itself.

Sb={(s,ℵ)| ∀ t:R+

0•(s|ttr t,ℵ |tref t)∈S}=S(TF4)

9Case C2 is necessary because case C1 does not cover so-called point nondeterminisms. Consider the process

(a→Stop).{d}Stop.

At time d, and only at time d, its behaviour is nondeterministic. If the environment offers the event aat time

dafter not having offered it in the interval [0,d), then the process may perform aor it may refuse to perform

it, depending on whether control has already switched to Stop. Therefore, (d,a)is a member of the maximal

timed refusal, and it is impossible to use C1 in order to deduce that ais a possible continuation to the timed

trace.

However, since we know that acannot be refused during the interval [0,d), we can use C2 in order to make

this deduction.

A.2. Timed CSP 251

Timed Failures Semantics

The denotational semantics of timed CSP is compositional: the timed failures associated with

a compound process are completely determined by the timed failures associated with its

component processes and the operator composing the component processes. Accordingly,

there is a single clause for each operator of the syntax of timed CSP.

Deadlock. The process Stop never engages in any event, i.e., it can always refuse any set of

events offered.

timed failures [[Stop]] = {(hi,ℵ)| ℵ ∈ TimedRefusal}

Event Prefix. The timed failures associated with the process a→Pfall into two classes. On

the one hand, the environment might never offer a, so it will never occur. In this case, awill

never appear in ℵ. On the other hand, amay be offered by the environment at time tand

will appear at the beginning of the timed trace. In this case, acould not have been offered

before t. The behaviour subsequent to the occurrence of ais that of P. These two cases are

reflected by the two sets in the following definition.

timed failures [[a→P]] = {(hi,ℵ)|a/∈σtref (ℵ)}

∪

{(h(t,a)ia(s+ttr t),ℵ)|t∈R+

∧a/∈σtref (ℵ |tref t)

∧(s,ℵ˙

−tref t)∈timed failures [[P]]}

Timed Event Prefix. The semantic clause of the timed event prefix operator is similar to

that of the previous operator. The only difference is the case in which event aoccurs at time

t. Then, the subsequent behaviour is that of P, in which the time variable uis substituted by

t(P[t/u]).

timed failures [[a@u →P]] = {(hi,ℵ)|a/∈σtref (ℵ)}

∪

{(h(t,a)ia(s+ttr t),ℵ)|t∈R+

∧a/∈σtref (ℵ |tref t)

∧(s,ℵ˙

−ttr t)∈timed failures [[P[t/u]]]}

Prefix Choice. Again, the timed failures associated with the process x:A→P(x)fall into

two categories. Either the environment will never offer an event in A, or an event a∈A

occurs at time t. In the latter case, the subsequent behaviour is due to process P(a)shifted

through ttime units.10

10 In [Schneider, 1999a], this operator seems not to be defined correctly.

252 Appendix A. Base Formalisms

timed failures [[x:A→P(x)]] = {(hi,ℵ)|A∩σtref (ℵ) = ∅}

∪

{(h(t,a)ia(s+ttr t),ℵ)|t∈R+

0∧a∈A

∧A∩σtref (ℵ |tref t) = ∅

∧(s,ℵ˙

−tref t)∈timed failures [[P(a)]]}

Successful Termination. The process Skip is immediately ready to accept the termination

event Xbefore it deadlocks. Its semantic clause is analogous to that of the event prefix

operator with process Psubstituted by Stop.

timed failures [[Skip]] = {(hi,ℵ)|X/∈σtref (ℵ)}

∪

{(h(t,X)i,ℵ)|t∈R+

0∧X/∈σtref (ℵ |tref t)}

Timeout. The time-sensitive choice P.{d}Qis resolved in favour of Pif the first event occurs

before time t; otherwise it is resolved in favour of Q. Any behaviour of Pthat records an

event occurrence before time dis also a behaviour of P.{d}Q. The other behaviours are

those in which the timeout occurs. In this case, the timed refusal ℵrestricted to the first d

units must be consistent with P, and the behaviour after dis due to Q, shifted through dtime

units.

timed failures [[P.{d}Q]] = {(s,ℵ)|beginttr(s)⩽Rd∧(s,ℵ)∈timed failures [[P]]}

∪

{(s,ℵ)|beginttr(s)⩾Rd∧(hi,ℵ |tref d)∈timed failures [[P]]

∧(s,ℵ)˙

−tfail d∈timed failures [[Q]]}

The fact that beginttr(s)⩽Rdand beginttr(s)⩾Rdare true if beginttr(s) = dembodies the

point nondeterminism at time d.

Delay. The process Wait d is a derived construct defined as Stop .{d}Skip, so its semantics

can be deduced from these three operators.

External Choice. The timed failures associated with the external choice PQfall into

three classes. The choice may have been resolved in favour of P, it may have been resolved

in favour of Qor it may not have been resolved yet. In the last case, the timed trace is empty

and the timed refusal is the joint responsibility of Pand Q. In the first two cases, the two

processes must have participated in the timed refusal up to the occurrence of the first event,

resolving the choice.

timed failures [[PQ]] = {(s,ℵ)|(s,ℵ)∈timed failures [[P]] ∪timed failures [[Q]]

∧

(hi,ℵ |tref beginttr(s)) ∈timed failures [[P]]

∩timed failures [[Q]]}

A.2. Timed CSP 253

Internal Choice. The timed observations associated with an internal choice are those that

are associated with either of its constituent processes.

timed failures [[PuQ]] = timed failures [[P]] ∪timed failures [[Q]]

Indexed Internal Choice. The indexed internal choice ui∈JPican behave as any of its con-

stituent processes. Its timed failures are hence all of those timed failures associated with any

of its constituents.

timed failures [[ ui∈JPi]] = Si∈Jtimed failures [[Pi]]

Alphabetised Parallel. In the parallel composition P|[A|B]|Q, the events in AXcan occur

only with the participation of P, and the events in BXcan occur only with the participation

of Q. Thus, the constituent processes must agree on the events in (A∩B)X, or, conversely, if

either of them refuses an event in this set, then the whole process refuses it. The combined

process can engage only in events in (A∪B)X, so the timed refusal outside (A∪B)Xis

arbitrary.

timed failures [[P|[A|B]|Q]] = {(s,ℵ)| ∃ ℵ1,ℵ2•

ℵtref (A∪B)X= (ℵ1tref AX)∪(ℵ2tref BX)

∧s=sttr (A∪B)X

∧(sttr AX,ℵ1)∈timed failures [[P]]

∧(sttr BX,ℵ2)∈timed failures [[Q]]}

Interleaving. The interleaving P||| Qcan engage in any event (except X) precisely when

one of the component processes can engage in that event. Only termination requires the

synchronisation of Pand Q. Therefore, a timed refusal of the combined process must be a

timed refusal of both components, and the timed trace sis an interleaving of the component

timed traces.

timed failures [[P||| Q]] = {(s,ℵ1∪ ℵ2)| ∃ s1,s2•sinterleaves (s1,s2)

∧(s1,ℵ1)∈timed failures [[P]]

∧(s2,ℵ2)∈timed failures [[Q]]

∧ ℵ1tref Σ = ℵ2tref Σ}

Interface Parallel. The interface parallel operator P|[A]|Qcombines the features of the al-

phabetised parallel and the interleaving operator. It requires the synchronisation on events

of the interface set Aand allows its component processes to interleave on events outside this

interface set. That is, events within Acan be refused by either process, but events outside A

can be refused only if both component processes do so.

timed failures [[P|[A]|Q]] = {(s,ℵ1∪ ℵ2)| ∃ s1,s2•ssynchA(s1,s2)

∧ ℵ1\tref AX=ℵ2\tref AX

∧(s1,ℵ1)∈timed failures [[P]]

∧(s2,ℵ2)∈timed failures [[Q]]}

254 Appendix A. Base Formalisms

Hiding. When hiding a set of events from the interface of a process, the process is given

the full control over the occurrence of these events. Maximal progress dictates that such an

event occurs as soon as the process is ready to accept it.

The timed failures of the process P\Aare determined by considering those timed failures

of Pin which the events in Aare continually refused, meaning that the environment of the

process is always ready to offer more instances of events in Athan Pis able to accept. In

other words, these timed failures represent observations in which events in Aoccur as soon

as they are accepted by P. The hiding makes the events in Ainternal, so they do not appear

in the resulting timed trace.

timed failures [[P\A]] = {(s\ttr A,ℵ)|(s,ℵ ∪ ([0,∞)×A)) ∈timed failures [[P]]}

Renaming. The forward renamed process f(P)maps each performed event ato f(a). It is

able to refuse an event aif Pis able to refuse all events that are mapped to a(fneed not be

injective).

timed failures [[f(P)]] = {(f(s),ℵ)|(s,f−1(ℵ)) ∈timed failures [[P]]}

In the above equation, f(s)denotes the timed trace obtained by applying fto all elements of

sindividually. Moreover,

f−1(ℵ) = {(t,a)|(t,f(a)) ∈ ℵ}

f(ℵ) = {(t,f(a)) |(t,a)∈ ℵ}.

The backward renamed process f−1(P)can perform the event awhen Pcan perform f(a),

and it can refuse awhenever Pcan refuse f(a).

timed failures [[f−1(P)]] = {(s,ℵ)|(f(s),f(ℵ)) ∈timed failures [[P]]}

SequentialComposition. In the sequential composition (P;Q),Pis executed until it termin-

ates at which point control is immediately passed to Q. The termination of Pis completely

under the control of the sequential composition, i.e., Pterminates as soon as it is ready to do

so. This is reflected in the following definition by considering only particular timed failures

associated with P, analogous to the definition of the hiding operator.

A timed failure of (P;Q)either corresponds to a non-terminating behaviour of P, or it cor-

responds to a terminating behaviour of Pimmediately followed by a behaviour of Q. The

termination of P, if any, does not appear in the resulting timed trace, because it does not

represent the termination of the sequential composition.

timed failures [[P;Q]] = {(s,ℵ)|X/∈σttr(s)∧(s,ℵ ∪ [0,∞)× {X})∈timed failures [[P]]}

∪

{(s1as2,ℵ)| ∃ t•X/∈σttr(s1)

∧(s2,ℵ)˙

−tfail t∈timed failures [[Q]]

∧(s1ah(t,X)i,ℵ |tref t∪([0,t)× {X})) ∈timed failures [[P]]}

A.2. Timed CSP 255

Interrupt. The process P4Qstarts by executing P. Simultaneously, initial events of Qare

enabled; and as soon as one of these occurs, Pis interrupted and control is passed to Q.

A timed failure associated with P4Qeither corresponds to an uninterrupted behaviour of

P, or it corresponds to an interrupted behaviour of Pfollowed by a behaviour Q. The fact

that Qis enabled while Pis executing means that the timed refusal up to an interrupt must

be a joint refusal of Pand Q. After an interrupt, the timed failure is due to Q.

timed failures [[P4Q]] = {(s1as2,ℵ)|(s1,ℵ |tref beginttr(s2)) ∈timed failures [[P]]

∧(s2,ℵ |tref beginttr(s1ttr {X})) ∈timed failures [[Q]]}

Note that the notation s1as2implies that the catenation is a valid timed trace. This has

two consequences. First, the times recorded in s2must be greater than or equal to all times

recorded in s1, ensuring that Pstops performing events as soon as Qhas started. Second,

unless s2is empty, s1must not contain the termination event, because in a timed trace it can

appear only as the last event. This ensures that the whole process stops when Pterminates.

Timed Interrupt. The timed interrupt P4dQfirst executes Pfor dtime units, and then

passes control to Qunless Phas already terminated.

The timed failures associated with P4dQconsist of two parts: the initial part corresponding

to the execution of Pfor dtime units, and the remaining part corresponding to the execution

of Qbeginning at time d.

timed failures [[P4dQ]] = {(s1a(s2+ttr d),ℵ)|

endttr(s1)≤d

∧(s1,ℵ |tref d)∈timed failures [[P]]

∧(X/∈σttr(s1)⇒(s2,ℵ˙

−tref d)∈timed failures [[Q]])}

Again, the fact that s1a(s2+ttr d)must be a valid timed trace implies that s2must be empty

if X∈σttr(s1).

Recursion. In the dialect of timed CSP [Schneider, 1999a] that we use in RT-Z, there is no

explicit process operator for defining recursion.11 Processes with recurring behaviour are

defined by recursive equations

N=Q.

The above equation identifies the process variable Nand the process term Q, which can

contain references to N. In this case, Nis defined in terms of itself.

To solve recursive process equations, a structure is imposed on the timed failures model

based on the refinement order and the theory of metric spaces.

The refinement order relates processes in terms of the behaviours they can exhibit. The

more behaviours a process can exhibit, the more nondeterministic it is. Process Pis less

11 This is in contrast to the older dialect described in [Davies, 1993], which introduces the fixed point operator

µ.

256 Appendix A. Base Formalisms

deterministic than process Q(Pis refined by Q), written PvQ, if the set of behaviours

associated with Qis a subset of that associated with P.

PvQ⇔timed failures [[Q]] ⊆timed failures [[P]]

In the timed failures model, the most nondeterministic process corresponds to the set of

all timed failures, and the most deterministic processes are the maximal processes under

the nondeterminism partial order (i.e., processes whose nondeterminism cannot be further

reduced).

Any well-timed CSP equation N=Qhas a least solution (fixed point) under the non-

determinism order. It is considered as the natural solution, because all other solutions (fixed

points) refine it: the least solution contains less restrictions (design decisions) than all other

solutions. Schneider [1999a] has claimed that the least fixed point computed in the timed

failures model coincides with the failure information that can be extracted from the opera-

tional semantics.

The partial order imposed by the nondeterminism order is combined with a metric space

structure in order to ensure the existence and uniqueness of fixed points for well-timed CSP

processes. The metric space structure is based on a distance between processes, which has

the property that the longer it takes to tell two processes apart, the closer together they are.

To define the distance function, the projection of a process S(more precisely, its associated

set of timed failures) to the time interval ending at time tis introduced as follows.

S|tcsp t={(s,ℵ)|(s,ℵ)∈S∧s|ttr t=s∧ ℵ |tref t=ℵ}

This projection extracts all timed failures that contain trace or refusal information beyond

time t. The case t=∞is treated separately.

S|tcsp ∞={(s,ℵ)|(s,ℵ)∈S∧ ∃ t:R+

0•endtfail(s,ℵ) = t}

On this basis, the distance function on processes is defined as follows.

d(S,T) = inf{2−t|t∈R+

0∧S|tcsp t=T|tcsp t}

If S|tcsp t=T|tcsp t, then Sand Tare indistinguishable up to time t. Any observer who

wishes to tell Sand Tapart must wait at least ttime units. The distance between two pro-

cesses can be at most 1. If the distance between two processes is 0, then they must have the

same set of finite duration timed failures. In this case, if the processes are not identical, then

they must be associated with different sets of infinite duration timed failures.

Schneider [1999a] introduced the finite timed failures model (FTF) in order to make available

the theory of metric spaces, which provides powerful results concerning the existence and

uniqueness of fixed points. The FTF model identifies each process with the set of finite dur-

ation timed failures associated with it. It is the projection of the timed failures model onto

finite duration behaviours. Any two processes Pand Qsatisfying d(P,Q)=0correspond to

the same element in the FTF model, and any two distinct elements will have some strictly

positive distance. As Schneider pointed out, the finite timed failures model together with

the distance function dforms a complete metric space.12

12 The (general) timed failures model together with the distance function does not form a metric space. The

A.2. Timed CSP 257

The following definitions and theorem are drawn from [Sutherland, 1975].

Definition A.1

Ametric space M= (A,d)consists of a non-empty set Atogether with a map d:A×A→R

satisfying

•d(x,y)≥0∧(d(x,y) = 0 ⇔x=y)

•d(x,y) = d(y,x)

•d(x,y) + d(y,z)≥d(x,z)

for all x,y,zin A.

Definition A.2

A metric space Mis complete if every Cauchy sequence in Aconverges to a point in A.

Definition A.3

A map f:A→Aof a metric space Mwith metric dis a contraction if there exists a constant

K<1such that d(f(x),f(y)) ≤K∗d(x,y)for all x,yin A.

The key result is the following theorem, which states that any contraction in a complete

metric space must have a unique fixed point.

Theorem A.1 (Banach Fixed Point Theorem)

If f:A→Ais a contraction of a complete metric space M= (A,d), then fhas a unique fixed

point in A.

Assuming that a contraction fhas different fixed points

f(x) = x6=x0=f(x0)

leads to a contradiction, because the distance between f(x)and f0(x)must be less than the

distance between xand x0. Thus, the application of fto xand x0must change at least one of

them; this, however, is in contrast to the property of a fixed point.

Furthermore, the unique fixed point can be determined by choosing an arbitrary member of

A, say x, and by considering the sequence

hx,f(x),f2(x),f3(x), . . .i.

distance between the processes

Pb=u

t∈R+

Wait t;a→Stop and Qb=Stop uP

e.g., is 0, because they are associated with the same set of finite duration timed failures. However, they are

not identical, because Qis able to refuse aforever, whereas Pis not able to do this; the infinite duration timed

failures associated with them are different.

timed failures [[Q]] \timed failures [[P]] = {(hi,[0,∞)× {a}}

258 Appendix A. Base Formalisms

Successive elements become closer and closer; the sequence is a Cauchy sequence, which

must have a limit—the fixed point of f—because of the completeness of the metric space. All

such sequences, whatever the starting point, have the same limit. Consequently,

fix(f) = limn→∞ fn(x)

for all xin A.

Having introduced the theoretical background, we now demonstrate that each t-guarded

process term corresponds to a contraction mapping. According to Section A.2.3, a process

term is t-guarded, if any execution of this term cannot reach a recursive call in less than t

time units. Assume that the process term Qin the equation

N=Q

is t-guarded for t>0. Let FQbe the function on the finite timed failures model corresponding

to Q. If N1|tcsp u=N2|tcsp uthen FQ(N1)|tcsp (u+t) = FQ(N2)|tcsp (u+t)and it follows

that

d(FQ(N1),FQ(N2)) ≤2−t∗d(N1,N2)

where 2−t<1.

FQis hence a contraction mapping on the complete metric space constituted by the FTF

model and the distance d. Thus, Banach’s fixed point theorem applies, assuring the existence

and uniqueness of a fixed point of FQ.

In conclusion, any well-timed CSP term has a unique fixed point in the finite timed failures

model, which is the model underlying RT-Z.13 The unique fixed point can be computed by

using the following equation

timed failures [[N]] |tcsp ∞=Sn∈N(timed failures [[Qn]] |tcsp n∗t)

where Qnis defined inductively

Qn+1 =Q[Qn/N]

and Q0can be chosen arbitrarily.

We have dealt only with simple recursion. The application of the above discussion to mutual

recursion, i.e., to collections of recursively defined processes, is straightforward. We have

hence omitted the discussion of mutual recursion.

A.2.5 Predicate Language

A timed specification is a predicate S(s,ℵ)on timed failures. It describes the behaviour

required of a process in terms of constraints on its timed traces and timed refusals. A process

13 According to Schneider [1999a], the situation is different in the (general) timed failures model. In this model,

for a well-timed CSP term to have a unique fixed point, it must not contain any infinite nondeterminism, i.e.,

it must not contain any operator introducing unbounded nondeterminism.

A.2. Timed CSP 259

Pmeets a specification S(s,ℵ)if, and only if, all timed failures that are associated with P

satisfy S. Formally,

Psat S(s,ℵ)⇔ ∀(s,ℵ)∈timed failures [[P]] •S(s,ℵ).

Timed specifications are usually expressed in terms of functions on timed traces, refusals

and failures, which are dealt with in Appendix E.

A timed specification S(s,ℵ)is admissible if the fact that all finite approximations of a timed

failure of infinite length meet Simplies that Sholds of this infinite timed failure as well.

(∀t:R+

0•S(s|ttr t,ℵ |tref t)) ⇒S(s,ℵ)

Admissible specifications have the merit that to check a process for satisfaction it suffices to

check all finite duration timed failures for satisfaction.

If the failure of a predicate to hold of a timed behaviour can always be realised within finite

time, then that predicate corresponds to an admissible specification. Inadmissible predicates

are those that may hold of all finite approximations of a timed failure (s,ℵ)but not of (s,ℵ)

itself. An example of a specification that is not admissible is #s<∞.

Specification macros

Building timed specifications directly as predicates on timed traces sand timed refusals ℵ

becomes cumbersome and error-prone as problems exceed a certain level of complexity. Fur-

thermore, there are frequently occurring specification patterns with regard to safety and

liveness requirements as well as to assumptions about the process environment. Specification

macros are abbreviations of predicates; they can be used as the building blocks of frequently

occurring specification patterns. Specification macros are useful not only for specifying re-

quirements, but they also allow us to reason about specifications on a higher level of ab-

straction. Relationships between macros can be established, which allow us to reason about

specifications at the level of macros rather than directly at the level of timed traces and re-

fusals. Specification macros are given in terms of the free variables sand ℵ.

In this section, we introduce only some important specification macros that we need in the

remainder of this thesis.

The specification macro at simply expresses that a particular event is recorded in the timed

trace as having occurred at a particular time.

aat t≡ h(t,a)iin s

The liveness of a process at time twith respect to a particular event acan have two con-

sequences: either the event is performed and hence appears in the timed trace, or else it does

not appear in the timed refusal.

alive t≡aat t∨(t,a)/∈ ℵ

An equivalent definition is (t,a)∈ ℵ ⇒ aat t, which states that if ais offered by the environ-

ment, then it must occur.

260 Appendix A. Base Formalisms

The following specification macro abbreviates a more intricate aspect of liveness. A process

might enable an event aat some time t, and continue to offer it at least until some event in A

occurs.

alive from tuntil A≡([t,beginttr((sttr t)ttr A)) × {a})∩ ℵ =∅

The definition states that between tand the first occurrence of a subsequent event from A,

the event acannot be refused.

The following specification macro is used in order to express assumptions about the envir-

onment of a process. An event ais open at time tif the environment of the process will not

block the occurrence of the timed event (t,a). Thus, if the event does not occur, it is due to

the refusal of the process to perform it, so (t,a)∈ ℵ.

aopen t≡aat t∨(t,a)∈ ℵ

Either ais actually performed at t, which clearly reveals that the environment was open to

the occurrence of a, or it appears in the timed refusal.

Another form of environmental assumption is that the environment always allows all occur-

rences of events from Athat the process wishes to perform. Such an environment will make

a process active on the set A, because it will perform all occurrences of Aurgently.

Aactive ≡[0,∞)×A⊆ ℵ

Several relationships between specification macros have been established by appealing to

their definitions. These relationships allow one to reason about specifications on a higher

level of abstraction.

A straightforward relationship between the macros at,live and open is the following:

aat t⇔alive t∧aopen t.

If ahas occurred at time t, then the process and the environment must have offered this event

at this time. Conversely, if the process and the environment are known to enable event aat

time t, then it must occur at this time in accordance with the maximal progress assumption.

A.2.6 Verification

Schneider [1999b] has developed a complete calculus for proving timed CSP processes cor-

rect with respect to timed specifications.

In theory, it is possible to prove a timed CSP process correct with respect to a timed speci-

fication by checking that each timed failure that is associated with the process meets the

specifying predicate. In practice, however, a more structured approach to verification is ne-

cessary.

In Section A.2.4, we presented the denotational semantics of timed CSP, which is composi-

tional. Compositionality means that the denotations of compound processes are defined in

terms of the denotations of their component processes. Analogously, it is possible to provide

A.2. Timed CSP 261

a compositional proof system, which reflects the structure of the semantic equations. Each

proof rule allows the deduction of a timed specification satisfied by a compound process

from the timed specifications that are met by its component specifications. There is a single

inference rule or axiom for each operator of the timed CSP syntax.

In the remainder of this section, we present the proof rules only for selected operators.

Event Prefix. Provided the process Pmeets the specification S, the behaviour of the process

a→Psubsequent to an occurrence of awill satisfy S. The behaviour up to the occurrence of

ais the continual offer of a.

Psat S(s,ℵ)

a→Psat alive from 0until {a}

∧s6=hi ⇒ first(s) = a∧S((tail(s),ℵ)−beginttr(s))

The timed specifications satisfied by a→Pare determined in terms of the timed specifica-

tions satisfied by P.

Note the correspondence between the structure of the previous inference rule and the struc-

ture of the semantic equation of the event prefix operator. The correctness of the inference

rule is backed up by the semantic equation.

Timeout. The following inference rule provides an example of reasoning about time-sensi-

tive behaviour. A behaviour of P.{d}Qis either a timed failure associated with P, whose

first event is recorded before time d, or else a timed failure of Qdelayed by dtime units. In

the latter case, the refusal information up to the timeout must be consistent with P.

Psat S(s,ℵ)

Qsat T(s,ℵ)

P.{d}Qsat (beginttr(s)⩽Rd∧S(s,ℵ)

∨beginttr(s)⩾Rd∧S(hi,ℵ |tref d)∧T((s,ℵ)˙

−tfail d))

Again, the structure of the inference rule is analogous to the structure of the corresponding

semantic equation.

Recursion Induction. To prove that a recursively defined process meets some specification,

we need a corresponding induction principle.

As discussed in Section A.2.4, the finite duration timed failures of a well-timed recursive

definition N=Pare uniquely determined. Let F(X) = P[X/N]be the function on timed

failures corresponding to the body Pof the recursive definition. If Sis an admissible specifi-

cation, which is satisfiable (for which there is at least one process P0satisfying it), and if Sis

preserved by applications of F, then the recursively defined process Nmeets S. Formally,

∀X•Xsat S(s,ℵ)⇒F(X)sat S(s,ℵ)"∃P0•P0sat S(s,ℵ)

S(s,ℵ)is admissible

N=F(N)#

Nsat S(s,ℵ)

262 Appendix A. Base Formalisms

This induction rule is correct for the following reason.

There is a process P0satisfying Sby assumption. The antecedent of the rule ensures that also

Fn(P0)meets Sfor all n∈N. According to Section A.2.4, each finite duration behaviour of N

is contained in Fn(P0)for some n∈N, because

timed failures [[N]] |tcsp ∞=Sn∈N(timed failures [[Fn(P0)]] |tcsp n∗t).

This means that all finite duration timed failures associated with Nsatisfy S.

Furthermore, for each infinite duration timed failure (s,ℵ)of N, all of its finite approxima-

tions must also be associated with N, because14

timed failures [[N]] ⊆Sn∈N(timed failures [[Fn(P0)]] |tcsp n∗t).

Since Sholds of all these finite duration behaviours and since Sis an admissible specification,

also the infinite duration timed failures of Nmust satisfy S. Thus, all timed failures (finite or

infinite) associated with Nmeet S, hence Nsat S.

A.2.7 Discussion

Timed CSP, as introduced in this section, has several strengths.

It provides a powerful notation, its formal foundation and also verification techniques for

defining and analysing the external behaviour of a system in terms of the temporal ordering

and the timing of its interactions with the environment. It is particularly useful for specifying

systems that are reactive in nature.

Furthermore, timed CSP, as an extension of CSP, is able to define certain aspects of system

and software architectures, e.g., concurrency, distribution and communication. This was

demonstrated by Allen and Garlan, who designed the architectural description language

(ADL) Wright [Allen, 1997], which is closely based on CSP.

On the other hand, there are also relevant shortcomings attributed to timed CSP.

Timed CSP is not designed to specify the structure and content of the information that

is communicated between processes. Channels between processes can be associated with

alphabets—sets of values carried by events—but the notation of timed CSP for defining al-

phabets and its values is only ad-hoc; and, more important, it is not covered by the semantic

model of timed CSP. In brief, timed CSP lacks an integrated notation for defining abstract

data types.

Moreover, processes are the only mechanism for structuring system specifications. The

weakness of process descriptions, which makes them inadequate as a high-level structur-

ing mechanism, is the fact that process interfaces are not defined explicitly, i.e., they must

be derived which is hard for complex processes, consisting of several sub-processes. We

think that the availability of the interface is a major prerequisite when describing system

components and their interdependencies.

14 We have not dealt with the computation of fixed points in the (general) timed failures model. The following

subset relationship is motivated by [Schneider, 1999b, p. 361].

A.2. Timed CSP 263

To conclude, the merits and drawbacks of timed CSP and the ones of Z discussed in the

previous section seem to complement each other, making their integration a worthwhile

task.

A.2.8 Other Approaches to Modelling and Reasoning about Real-Time

Nicollin and Sifakis [1991] gave an introduction to timed process algebras by comparing

several instances, including (a previous version of) timed CSP. They presented fundamental

assumptions about timed systems and the nature of time (cf. Section A.2.1) and introduced

the concept of timed transition systems, on which the operational semantics of timed CSP is

based. They also proposed some general principles for the real-time extension of untimed

process algebras, which concern the compatibility of the interpretations associated with a

process in the untimed and the timed setting.

Let us outline four important instances of timed process algebras.

Baeten and Bergstra [1991] introduced the real-time process algebra ACPρ, which is an ex-

tension of ACP (Algebra of Communicating Processes). As a characteristic feature of ACPρ

(and also ACP), its formal meaning is defined by an axiomatic semantics, in contrast to the

operational and denotational approaches taken by the other timed process algebras. In fact,

ACP and ACPρare collections of axioms that are defined with respect to a simple process

algebra syntax.

ET-LOTOS, developed by L´

eonard and Leduc [1997], is a real-time extension of LOTOS [Bo-

lognesi et al., 1995]. The time domain underlying ET-LOTOS is not fixed; it is modelled by

a sort, which must be instantiated by any ET-LOTOS specification by using the algebraic

specification language ACT ONE [Ehrig and Mahr, 1985] (which is a base language of LO-

TOS). Syntactically, ET-LOTOS basically extends LOTOS by two constructs: the life reducer

and the delay operator. The life reducer allows the specifier to restrict the interval in which

an action is offered (which roughly corresponds to the timeout operator of timed CSP), and

the delay operator prefixes a behaviour expression by a delay. The authors demonstrated

that all relevant patterns of time-sensitive behaviour can be modelled by combining these

two basic concepts. The operational semantics of ET-LOTOS was defined by strictly separ-

ating event and time transitions, analogously to the definition of the operational semantics

of timed CSP presented in Section A.2.2. ET-LOTOS and timed CSP are very close in spirit,

being based on the same computational model; this is witnessed by Bryans et al. [1995] who

defined a denotational semantics for ET-LOTOS similar to that of timed CSP.

Moller and Tofts [1990] developed a real-time extension of Milner’s Calculus of Communic-

ating Systems [Milner, 1989], called TCCS. It is based on a discrete model of time. Its syntax

extends that of CCS by delay operators and a so-called weak choice operator (as opposed to

the strong choice operator adopted from CCS), which allows the passage of time to resolve

a choice and therefore to express timeouts. The operational semantics of TCCS is defined

analogously to the approach taken by timed CSP and also ET-LOTOS: the inference rules

characterising the possible action transitions of processes (already defined by CCS) are ex-

tended by additional rules characterising the time transitions of processes. The definition of

a bisimulation equivalence relation on TCCS processes and the derivation of an equational

theory, which is sound with respect to bisimulation, is a prerequisite for reasoning about

TCCS processes.

264 Appendix A. Base Formalisms

Hennessy and Regan [1995] proposed a (deliberately) minor extension to the process algebra

CCS, called Timed Process Language (TPL), with a mathematically simple notion of time.

The extension basically consists in introducing a special action σ, which denotes idling until

the next clock cycle (the passage of time). In other words, the approach is based on a discrete

model of time. The semantic theory of TPL is based on testing; it is an extension of the theory

of testing from de Nicola and Hennessy [1984] to the timed setting.

TPL was not designed to be universally applicable, but focuses on application areas in which

time plays a restricted rˆ

ole such as protocol verification. For these applications, TPL is ad-

equate because it does not introduce unnecessary complexity. TPL is considered by the

authors “to provide a sound basis on which to develop more extensive theories of timed

systems.”

In addition to timed process algebras, there are other approaches to modelling and reasoning

about time-sensitive systems. Surveys of the most important approaches can be found in

[Heitmeyer and Mandrioli, 1996] and [de Bakker et al., 1991]. In the remainder, we outline

three representative examples of these approaches.

The formalism TTM/RTTL [Ostroff, 1991] comprises two notations. An automaton model

(Timed Transition Model), mainly extended by assigning lower and upper time bounds to

state transitions, is used to construct models of real-time systems; and a real-time temporal

logic (RTTL) serves to abstractly express properties that such models are required to satisfy.

This notational separation between a system model and the properties that it is required to

satisfy is a crucial language feature, which is also shared by timed CSP.

The formalism Modechart/RTL [Jahanian and Mok, 1994] also consists of a pair of specifi-

cation languages. Modechart is a graphical language for constructing models of real-time

systems. It is basically a restriction of Statecharts [Harel, 1987] to those language constructs

that allow a concise and succinct specification of real-time systems while avoiding the se-

mantic problems associated with the more powerful constructs of Statecharts. Properties

that a Modechart must satisfy are specified in terms of the Real Time Logic (RTL), which is

also the logic used to define the semantics of Modecharts. One benefit of this approach is the

provision of tool support for checking a Modechart for consistency and completeness and

for verifying the satisfaction of properties expressed as RTL assertions.

Both TTM/RTTL and Modechart/RTL are based on a discrete time model, whereas the un-

derlying time domain of timed CSP is dense.

The Duration Calculus [Chaochen et al., 1991] is a real-time interval logic based on state dur-

ations. A system is modelled in terms of a collection of state variables that are functions of

time, which is modelled by real numbers. System requirements are specified by means of

duration formulas that are predicates containing integrals over state assertions (predicates

on state variables). That is, the Duration Calculus has a completely different underlying

model than timed CSP. This underlying model is ideal for specifying requirements concern-

ing the duration of intervals in which particular conditions are satisfied, but it is less appro-

priate for specifying other aspects of the dynamic behaviour, e.g., the temporal ordering of

interactions. Which underlying model is more appropriate depends on the specific real-time

system to be developed.

Appendix B

Satisfaction of the Properties of the

Timed Failures Model

The aim of this appendix is to prove that our semantic definitions in Section 9.2.4 are con-

sistent with the properties of the timed failures model formalised on p. 126 and explained

on pp. 249 ff. More precisely, we aim to establish that each Z specification (constituting the

Z part of a concrete specification unit) is mapped to a set of timed failures satisfying these

properties.

B.1 Lemmata

We first state some lemmata we need throughout the main proof. We do not prove these

lemmata but provide informal arguments why they are true.

The first two lemmata are immediate consequences of the definition of the function tracesZ

and the relation PreHist in Sections 9.2.3 and 9.2.4.

Lemma B.1

Given a trace tr that is related to the history h. Then, each prefix tr0of tr is related to some

history h0that is a pre-history of h.

tr =tracesZh

tr0prefix tr

∃h0:HS |(h0,h)∈PreHist •tr0=tracesZh0

Lemma B.2

Given a trace tr and one of its prefixes tr0such that the two are related to the histories hand

h0, respectively. If there is a history h∗of which both hand h0are pre-histories, then either h

must be a pre-history of h0or vice versa. Since we have assumed that h0is related to a trace

265

266 Appendix B. Satisfaction of TFM Properties

that is a prefix of a trace that is related to h, we can conclude that h0is a pre-history of h.

tr =tracesZh

tr0=tracesZh0

tr0prefix tr

∃h∗:HS •(h,h∗)∈PreHist ∧(h0,h∗)∈PreHist

(h0,h)∈PreHist

Lemma B.3

Given a timed trace s. Let h,pref1and pref2be histories that are related to the entire timed

trace s, to the projection of sonto the interval [0,t1] and to the projection of sonto the interval

[0,t2], respectively, and suppose that both pref1and pref2are pre-histories of h. If t2⩾Rt1,

then pref1must be a pre-history of pref2.

strip s=tracesZh

strip(sttr t1) = tracesZpref1∧(pref1,h)∈PreHist

strip(sttr t2) = tracesZpref2∧(pref2,h)∈PreHist

t2⩾Rt1

(pref1,pref2) ∈PreHist

The lemma is an immediate consequence of Lemma B.2, because strip(sttr t1) is a prefix of

strip(sttr t2) for all t2⩾Rt1.

Lemma B.4

Let sand s0be two timed traces such that s0is a prefix of s. Let further the traces correspond-

ing to sand s0be related to the histories hand h0, respectively, and let h0be a pre-history

of h. If the time values recorded in the timed trace sare consistent with the simultaneity

information recorded in the component simultan of of the history h, then we can conclude

that also the time values recorded in the timed trace s0are consistent with the simultaneity

information recorded in the history h0.

s0prefix s

strip s=tracesZh

strip s0=tracesZh0

(h0,h)∈PreHist

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j))

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j))

According to the definition of PreHist, the component simultan of of h0must be a subset

of that of h. Furthermore, the time values recorded in s0are identical with those recorded

in the corresponding timed events of s. The consistency of the time values of swith the

simultaneity information fixed by hthus guarantees the consistency of the time values of s0

with the simultaneity information fixed by h0.

Lemma B.5

Given a timed trace s. Let hand pref be histories that are related to the entire timed trace s

and to the projection of sonto the interval [0,t2], respectively, and let pref be a pre-history of

B.2. Properties of the Timed Failures Model 267

h. Finally let ext be a history of which pref is a pre-history. Then, the component simultan of

of hand ext projected onto the interval [0,t2] are equal.

strip s=tracesZh

strip(sttr t2) = tracesZpref

(pref,h)∈PreHist

(pref,ext)∈PreHist

simultan of ext ∩ {i,j:N|time of(s i)⩽Rt2∧time of(s j)⩽Rt2}=

simultan of h ∩ {i,j:N|time of(s i)⩽Rt2∧time of(s j)⩽Rt2}

The projection of sonto the interval [0,t2] is entirely covered by the history pref. Since pref

is a pre-history of both hand ext, their components simultan of restricted to the part covered

by pref must be equal. This is a consequence of the definition of PreHist.

B.2 Properties of the Timed Failures Model

Theorem B.1

Let CSU be a concrete specification unit and Mbe a model associated with its Z part. Let

HS == Histories(|{(M,CSU.OPS)}|).

Then

S{h:HS •timed failuresZ(|{(h,HS)}|)} ∈ TimedFailuresModel.

That is, each set of timed failures that is associated with the Z part of a concrete specification

unit satisfies the properties of the timed failures model defined on p. 126 and explained on

pp. 249 ff.

Proof.

The proof is organised according to the decomposition into the conditions TF1, TF2, TF3/C1

and TF3/C2, see the explanation on pp. 249 ff. Throughout the following proof, we mark

those parts of the formulae that are manipulated in the current step by a rectangle.

TF 1

We assume that the Init schema of the Z part of CSU is satisfiable. Each consistent specifica-

tion unit must meet this condition.

∃InitSt :InitModel(|{M}|)∩StateModel(|{M}|)

(hi,∅)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

∃InitSt :InitModel(|{M}|)∩StateModel(|{M}|)

`[def. HS,Histories]

((hi,∅),hInitSti,hi)∈HS

268 Appendix B. Satisfaction of TFM Properties

`[def. tracesZ]

hi ∈ {h:HS •tracesZh}

`[def. failuresZ]

(hi,∅)∈S{h:HS •failuresZ(|{(h,HS)}|)}

`[def. timed failuresZ]

(hi,∅)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}



TF 2

(s,ℵ)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

∃s∗•s=s0as∗∧ ℵ0⊆ ℵ |tref (beginttr s∗)

(s0,ℵ0)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

(s,ℵ)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

`[def. timed failuresZ]

∃h:HS •

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

(strip(sttr t),{e:Event |(t,e)∈ ℵ})∈failuresZ(|{(prefix,HS)}|))

`[Lemma B.1; s0prefix s⇒strip(s0)prefix strip(s)]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

strip s0=tracesZh0∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

(strip(sttr t),{e:Event |(t,e)∈ ℵ})∈failuresZ(|{(prefix,HS)}|))

`[Lemma B.4]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•(∃prefix :HS |(prefix,h)∈PreHist •

(strip(sttr t),{e:Event |(t,e)∈ ℵ})∈failuresZ(|{(prefix,HS)}|)))

`[def. failuresZ]

B.2. Properties of the Timed Failures Model 269

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ • chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0))))

))

`[t<Rbeginttr s∗∨t⩾Rbeginttr s∗]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•

t<Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ • chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

∨

t⩾Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

270 Appendix B. Satisfaction of TFM Properties

∨

(∃e0:Event |(t,e0)/∈ ℵ • chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0))))))

`[t<Rbeginttr s∗⇒(sttr t=s0ttr t

∧ {e:Event |(t,e)∈ ℵ0} ⊆ {e:Event |(t,e)∈ ℵ});

t⩾Rbeginttr s∗⇒ {e:Event |(t,e)∈ ℵ0}=∅;

∀e:∅•false;

B⊆A∧(∀x:A•P(x)) ⇒(∀x:B•P(x));

B⊆A∧x/∈A⇒x/∈B]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•

t<Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip( s0ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

∨

t⩾Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} • false )))

`[Lemma B.1; (s0ttr t)prefix (sttr t)]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•

t<Rbeginttr s∗∧

B.2. Properties of the Timed Failures Model 271

(∃prefix :HS |(prefix,h)∈PreHist •

strip(s0ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

∨

t⩾Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

(∃prefix0:HS |(prefix0,prefix)∈PreHist •

strip(s0ttr t) = tracesZprefix0∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix0,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))

))))

`[transitivity of PreHist]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•

t<Rbeginttr s∗∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip(s0ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

272 Appendix B. Satisfaction of TFM Properties

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t⩾Rbeginttr s∗∧

(∃prefix0:HS |(prefix0,h)∈PreHist •

strip(s0ttr t) = tracesZprefix0∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix0,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[A∧B∨C∧B≡(A∨C)∧B]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T•(∃prefix :HS |(prefix,h)∈PreHist •

strip(s0ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(s0ttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[def. failuresZ]

∃h,h0:HS |(h0,h)∈PreHist •

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

(strip(s0ttr t),{e:Event |(t,e)∈ ℵ0})∈failuresZ(|{(prefix,HS)}|))

`[Lemma B.2; strip(s0ttr t)prefix strip s0]

∃h0:HS •

B.2. Properties of the Timed Failures Model 273

(∀i,j:N|(i,j)∈simultan of h0•time of(s0i) = time of(s0j)) ∧

strip s0=tracesZh0∧

∀t:T• ∃ prefix :HS |(prefix,h0)∈PreHist •

(strip(s0ttr t),{e:Event |(t,e)∈ ℵ0})∈failuresZ(|{(prefix,HS)}|)

`[def. timed failuresZ]

(s0,ℵ0)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}



TF 3

(s,ℵ)∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

∃ ℵ0:TimedRefusal | ℵ ⊆ ℵ0∧

(s,ℵ0)∈S{h:HS •timed failuresZ(|{(h,HS)}|)} •

(∀t:T;a:Event •

((t,a)/∈ ℵ0⇒((sttr t)ah(t,a)i,ℵ0|tref t)∈

S{h:HS •timed failuresZ(|{(h,HS)}|)})

∧

(t>R0R∧ ¬ (∃:T+•[t−R, t)× {a} ⊆ ℵ0)⇒

((s|ttr t)ah(t,a)i,ℵ0|tref t)∈

S{h:HS •timed failuresZ(|{(h,HS)}|)})

Let (s,ℵ)∈timed failuresZ(|{(h,HS)}|)for an arbitrary history h∈HS.

Our first goal is to construct, with respect to the chosen timed refusal ℵ, the set of all maximal

timed refusals ℵ0, because we must establish the existence of such a maximal timed refusal

in TF3. To this end, we need two auxiliary functions.

EquivTerm == λch :ranTermOf • {e:Event |chan of(e) = ch}

EquivExec == λch :ranExecOf •λin :Binding •

{e:Event |chan of(e) = ch ∧Inputs Cval of(e) = in}

The function EquivTerm maps each channel that carries termination events to the class (set)

of all termination events that can occur on that channel. Similarly, the function EquivExec

maps each channel that carries execution events to a function, which, in turn, maps each

input parameter binding to the class (set) of all execution events that can occur on the given

channel and that associate the given values with the input parameters.

We now define the set of all maximal timed refusals with respect to the chosen ℵ. Each

maximal timed refusal ℵ0in this set

•must contain ℵ,

•must contain for each time instant all events that are not possible continuations of the

timed trace sand

274 Appendix B. Satisfaction of TFM Properties

•must contain for each time instant and for each channel carrying termination or execu-

tion events all but one event of the respective class.

ℵmax == {ℵ0:TimedRefusal | ∀ t:T•

∃1ref == {e:Event |(t,e)∈ ℵ};ref0== {e:Event |(t,e)∈ ℵ0} •

∃nmemTerm :ranTermOf →Event;nmemExec :ranExecOf →Binding →Event |

∀ch :ranTermOf •(nmemTerm ch)∈(EquivTerm ch)\ref ∧

∀ch :ranExecOf;in :Binding •(nmemExec ch in)∈(EquivExec ch in)\ref •

ref0=ref

∪

{e:Event |strip(sttr t)ahei/∈

{pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}}

∪

S{ch :ranTermOf •(EquivTerm ch)\ {nmemTerm ch}}

∪

S{ch :ranExecOf;in :Binding •(EquivExec ch in)\ {nmemExec ch in}}

The following lemmata, which are local with respect to TF3, are immediate consequences of

the definition of the set ℵmax.

Lemma B.6

ℵ0∈ ℵmax

(t,e)∈ ℵ0

(t,e)∈ ℵ

∨

strip(sttr t)ahei/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) = Inputs C(val of e0)))

Lemma B.7

ℵ0∈ ℵmax

(t,e)/∈ ℵ0

strip(sttr t)ahei ∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

B.2. Properties of the Timed Failures Model 275

Lemma B.8

ℵ0∈ ℵmax

(t,e)∈ ℵ

strip(sttr t)ahei ∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) = Inputs C(val of e0)))

Let ℵ0be a maximal timed refusal with respect to ℵ, i.e., ℵ0∈ ℵmax.

We must prove four subgoals.

1.ℵ ⊆ ℵ0

2.(s,ℵ0)∈timed failuresZ(|{(h,HS)}|)

3. TF 3/C1

∀t2 : T;a:Event |(t2,a)/∈ ℵ0•

((sttr t2) ah(t2,a)i,ℵ0|tref t2) ∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

4. TF 3/C2

∀t0 : T;a:Event |t0>R0R∧ ¬ (∃:T+•[t0−R, t0) × {a} ⊆ ℵ0)•

((s|ttr t0) ah(t0,a)i,ℵ0|tref t0) ∈S{h:HS •timed failuresZ(|{(h,HS)}|)}

ad 1.

`[ℵ0∈ ℵmax;def. ℵmax]

ℵ ⊆ ℵ0



ad 2.

(s,ℵ)∈timed failuresZ(|{(h,HS)}|)

`[def. timed failuresZ]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

(strip(sttr t),{e:Event |(t,e)∈ ℵ})∈failuresZ(|{(prefix,HS)}|))

`[def. failuresZ;∀e:{a:S|P(a)} • P(e)]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

276 Appendix B. Satisfaction of TFM Properties

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ} •

strip(sttr t)ahei/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ • chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0))))

∧

(∀e:{a:Event |

strip(sttr t)ahai/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(a) = chan of(e0)∧

(chan of(a)∈ranTermOf

∨chan of(a)∈ranExecOf

∧Inputs C(val of a) = Inputs C(val of e0)))} •

strip(sttr t)ahei/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0))))

)

`[Lemma B.8; ((∀x:A•P(x)) ∧(∀x:B•P(x)) ⇒(∀x:A∪B•P(x)))]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |

B.2. Properties of the Timed Failures Model 277

(t,a)∈ ℵ

∨

strip(sttr t)ahai/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(a) = chan of(e0)∧

(chan of(a)∈ranTermOf

∨chan of(a)∈ranExecOf ∧Inputs C(val of a) = Inputs C(val of e0)))

} •

strip(sttr t)ahei/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

`[Lemma B.6; A⊆B⇒((∀x:B•P(x)) ⇒(∀x:A•P(x)))]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {pref,ext :HS |strip(sttr t) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) = Inputs C(val of e0)))))

`[strip(sttr t) = tracesZprefix ∧(prefix,h)∈PreHist ⇒

{pref,ext :HS |strip(sttr t) = tracesZpref ∧(pref,h)∈PreHist ∧

(pref,ext)∈PreHist •ext}={ext :HS |(prefix,ext)∈PreHist};

B⊆A⇒(x/∈R(|A|)⇒x/∈R(|B|))]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

278 Appendix B. Satisfaction of TFM Properties

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) = Inputs C(val of e0)))))

`[def. failuresZ]

(∀i,j:N|(i,j)∈simultan of h •time of(s i) = time of(s j)) ∧

strip s=tracesZh∧

(∀t:T• ∃ prefix :HS |(prefix,h)∈PreHist •

(strip(sttr t),{e:Event |(t,e)∈ ℵ0})∈failuresZ(|{(prefix,HS)}|))

`[def. timed failuresZ]

(s,ℵ0)∈timed failuresZ(|{(h,HS)}|)



ad 3.

(t2,a)/∈ ℵ0

`[Lemma B.7]

strip(sttr t2) ahai ∈ {pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

`[Lemma B.5]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} |

simultan of h∗=simultan of h

∩ {i,j:N|time of(s i)⩽Rt2∧time of(s j)⩽Rt2}

∪ {i:N|time of(s i) = t2•(i,#(sttr t2) + 1)} •

strip(sttr t2) ahai=tracesZh∗

`[(s,ℵ)∈timed failuresZ(|{(h,HS)}|);

(i,j)∈simultan of h∗⇒

((i,j)∈simultan of h ∨j= #(sttr t2) + 1 ∧time of(s i) = t2);

((sttr t2) ah(t2,a)i)(#(sttr t2) + 1) = (t2,a)]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((sttr t2) ah(t2,a)i)i) =

B.2. Properties of the Timed Failures Model 279

time of(((sttr t2) ah(t2,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗

`[t2⩽Rt∨t2>Rt]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((sttr t2) ah(t2,a)i)i) =

time of(((sttr t2) ah(t2,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗∧

∀t:T•t2⩽Rt∨t2>Rt

`[(h∗,h∗)∈PreHist;∀e:∅•false; (s,ℵ0)∈timed failuresZ(|{(h,HS)}|)]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((sttr t2) ah(t2,a)i)i) =

time of(((sttr t2) ah(t2,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗∧

(∀t:T•

t2⩽Rt∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip((sttr t2) ah(t2,a)i) = tracesZprefix ∧

(∀e:∅•

strip((sttr t2) ah(t2,a)i)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t2•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

∨

280 Appendix B. Satisfaction of TFM Properties

t2>Rt∧

(∃prefix∗:HS |(prefix∗,h)∈PreHist •

strip(sttr t) = tracesZprefix∗∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {ext :HS |(prefix∗,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

)

`[∃x:S•P(x)∧S⊆T⇒ ∃ x:T•P(x); Lemma B.3;transitivity of PreHist]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((sttr t2) ah(t2,a)i)i) =

time of(((sttr t2) ah(t2,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T•

t2⩽Rt∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(sttr t2) ahai=tracesZprefix ∧

(∀e:∅•

strip(sttr t2) ahaiahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t2•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t2>Rt∧

(∃prefix∗:HS |(prefix∗,h∗)∈PreHist •

strip(sttr t) = tracesZprefix∗∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {ext :HS |(prefix∗,ext)∈PreHist •tracesZext}

B.2. Properties of the Timed Failures Model 281

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[t2⩽Rt⇒(strip(((sttr t2) ah(t2,a)i)ttr t) = strip(sttr t2) ahai ∧

{e:Event |(t,e)∈ ℵ0|tref t2}=∅)

t2>Rt⇒(strip(((sttr t2) ah(t2,a)i)ttr t) = strip(sttr t)∧

{e:Event |(t,e)∈ ℵ0|tref t2}={e:Event |(t,e)∈ ℵ0})]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of((sttr t2ah(t2,a)i)i) =

time of((sttr t2ah(t2,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T•

t2⩽Rt∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip( ((sttr t2) ah(t2,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t2} •

strip(((sttr t2) ah(t2,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t2•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t2>Rt∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip( ((sttr t2) ah(t2,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t2} •

strip(((sttr t2) ah(t2,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

282 Appendix B. Satisfaction of TFM Properties

(∃e0:Event |(t,e0)/∈ ℵ0|tref t2•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[A∧B∨C∧B≡(A∨C)∧B]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((sttr t2) ah(t2,a)i)i) =

time of(((sttr t2) ah(t2,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T•(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(((sttr t2) ah(t2,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t2} •

strip(((sttr t2) ah(t2,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t2•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[def failuresZ]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of((sttr t2ah(t2,a)i)i) =

time of((sttr t2ah(t2,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T• ∃ prefix :HS |(prefix,h∗)∈PreHist •

(strip(((sttr t2) ah(t2,a)i)ttr t),{e:Event |(t,e)∈ ℵ0|tref t2})∈

failuresZ(|{(prefix,HS)}|))

`[def. timed failuresZ]

((sttr t2) ah(t2,a)i,ℵ0|tref t2) ∈S{h:HS •timed failuresZ(|{(h,HS)}|)})



ad 4.

t0>R0R∧ ¬ ∃ :T+•[t0−R, t0) × {a} ⊆ ℵ0

B.2. Properties of the Timed Failures Model 283

∀t1 : [0R,t0) • ∃ t2 : (t1,t0) •(t2,a)/∈ ℵ0

ℵ0∈TimedRefusal

`[def. TimedRefusal: union of finite set of refusal tokens]

∃t1 : [0R,t0) • ∀ t: (t1,t0) • {e:Event |(t,e)∈ ℵ0}={e:Event |(t1,e)∈ ℵ0}

s∈TimedTrace

`[def. TimedTrace: infinite timed traces must not be bounded in time]

∃t1 : [0R,t0) •s↑[t1,t0) = hi

Let t1 : [0R,t0) such that ∀t: (t1,t0) • {e:Event |(t,e)∈ ℵ0}={e:Event |(t1,e)∈ ℵ0} ∧ s↑

[t1,t0) = hi. Let t2 : (t1,t0) such that (t2,a)/∈ ℵ0.

(t2,a)/∈ ℵ0

`[Lemma B.7]

strip(sttr t2) ahai ∈ {pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •tracesZext}

`[Lemma B.5]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} |

simultan of h∗=simultan of h

∩ {i,j:N|time of(s i)<Rt2∧time of(s j)<Rt2} •

strip(sttr t2) ahai=tracesZh∗

`[s↑ttr [t2,t0) = hi]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} |

simultan of h∗=simultan of h

∩ {i,j:N|time of(s i)<Rt0∧time of(s j)<Rt0} •

strip(sttr t2) ahai) = tracesZh∗

`[(s,ℵ)∈timed failuresZ(|{(h,HS)}|);

∀i:doms|time of(s i)<Rt0•((s|ttr t0) ah(t0,a)i)i=s i]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

284 Appendix B. Satisfaction of TFM Properties

strip(sttr t2) ahai=tracesZh∗

`[t0>Rt2]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of((s|ttr t0ah(t0,a)i)i) =

time of((s|ttr t0ah(t0,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗∧

∀t:T•t<Rt2∨t2⩽Rt<Rt0∨t⩾Rt0

`[(h∗,h∗)∈PreHist;∀e:∅•false; (s,ℵ0)∈timed failuresZ(|{(h,HS)}|)]

∃h∗:{pref,ext :HS |strip(sttr t2) = tracesZpref ∧

(pref,h)∈PreHist ∧(pref,ext)∈PreHist •ext} •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗∧

(∀t:T•

t⩾Rt0∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip((sttr t2) ah(t2,a)i) = tracesZprefix ∧

(∀e:∅•

strip((sttr t2) ah(t2,a)i)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t2⩽Rt<Rt0∧

B.2. Properties of the Timed Failures Model 285

(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t2) = tracesZprefix ∧

(∀e:{a:Event |(t2,a)∈ ℵ0} •

strip(sttr t2) ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

∨

t<Rt2∧

(∃prefix :HS |(prefix,h)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf

∧Inputs C(val of e) = Inputs C(val of e0)))))

)

`[∃x:S•P(x)∧S⊆T⇒ ∃ x:T•P(x); Lemma B.3]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

strip(sttr t2) ahai=tracesZh∗∧

(∀t:T•

t⩾Rt0∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip((sttr t2) ah(t2,a)i) = tracesZprefix ∧

(∀e:∅•

strip((sttr t2) ah(t2,a)i)ahei/∈

286 Appendix B. Satisfaction of TFM Properties

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t2⩽Rt<Rt0∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(sttr t2) = tracesZprefix ∧

(∀e:{a:Event |(t2,a)∈ ℵ0} •

strip(sttr t2) ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t<Rt2∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(sttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0} •

strip(sttr t)ahei/∈ {ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[t⩾Rt0⇒

((s|ttr t0) ah(t0,a)i)ttr t= (s|ttr t0) ah(t0,a)i= (sttr t2) ah(t0,a)i ∧

{e:Event |(t,e)∈ ℵ0|tref t0}=∅;

strip(((s|ttr t0) ah(t0,a)i)ttr t) = strip((sttr t2) ah(t2,a)i)

t2⩽Rt<Rt0⇒

((s|ttr t0) ah(t0,a)i)ttr t=sttr t=sttr t2∧

{e:Event |(t2,e)∈ ℵ0}={e:Event |(t,e)∈ ℵ0}=

{e:Event |(t,e)∈ ℵ0|tref t0}

B.2. Properties of the Timed Failures Model 287

t<Rt2(<Rt0) ⇒

((s|ttr t0) ah(t0,a)i)ttr t=sttr t∧

{e:Event |(t,e)∈ ℵ0|tref t0}={e:Event |(t,e)∈ ℵ0}]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of((s|ttr t0ah(t0,a)i)i) =

time of((s|ttr t0ah(t0,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T•

t⩾Rt0∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip( ((s|ttr t0) ah(t0,a)i)ttr t) = tracesZprefix ∧

(∀e:{e:Event |(t,e)∈ ℵ0|tref t0} •

strip(((s|ttr t0) ah(t0,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t2⩽Rt<Rt0∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

strip( ((s|ttr t0) ah(t0,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t0} •

strip(((s|ttr t0) ah(t0,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0)))))

∨

t<Rt2∧

(∃prefix :HS |(prefix,h∗)∈PreHist •

288 Appendix B. Satisfaction of TFM Properties

strip( ((s|ttr t0) ah(t0,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t0} •

strip(((s|ttr t0) ah(t0,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[A∧D∨B∧D∨C∧D≡(A∨B∨C)∧D]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

strip((sttr t2) ah(t2,a)i) = tracesZh∗∧

(∀t:T•(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(((s|ttr t0) ah(t0,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t0} •

strip(((s|ttr t0) ah(t0,a)i)ttr t)ahei/∈

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[sttr t2 = s|ttr t0; strip((sttr t2) ah(t2,a)i) = strip((s|ttr t0) ah(t0,a)i)]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

strip( (s|ttr t0) ah(t0,a)i) = tracesZh∗∧

(∀t:T•(∃prefix :HS |(prefix,h∗)∈PreHist •

strip(((s|ttr t0) ah(t0,a)i)ttr t) = tracesZprefix ∧

(∀e:{a:Event |(t,a)∈ ℵ0|tref t0} •

strip(((s|ttr t0) ah(t0,a)i)ttr t)ahei/∈

B.2. Properties of the Timed Failures Model 289

{ext :HS |(prefix,ext)∈PreHist •tracesZext}

∨

(∃e0:Event |(t,e0)/∈ ℵ0|tref t0•chan of(e) = chan of(e0)∧

(chan of(e)∈ranTermOf

∨chan of(e)∈ranExecOf ∧Inputs C(val of e) =

Inputs C(val of e0))))))

`[def. failuresZ]

∃h∗:HS •

(∀i,j:N|(i,j)∈simultan of h∗•time of(((s|ttr t0) ah(t0,a)i)i) =

time of(((s|ttr t0) ah(t0,a)i)j)) ∧

strip((s|ttr t0) ah(t0,a)i) = tracesZh∗∧

(∀t:T•(∃prefix :HS |(prefix,h∗)∈PreHist •

(strip(((s|ttr t0) ah(t0,a)i)ttr t),{e:Event |(t,e)∈ ℵ0|tref t0})∈

failuresZ(|{(prefix,HS)}|)))

`[def. timed failuresZ]

((s|ttr t0) ah(t0,a)i,ℵ0|tref t0) ∈S{h:HS •timed failuresZ(|{(h,HS)}|)})



290 Appendix B. Satisfaction of TFM Properties

Appendix C

Relationship between Simulation and

Refinement in the Timed Failures/States

Model

In this appendix we prove some lemmata that we needed in Chapter 10 in order to establish

that forward and backward simulations between concrete specification units imply refine-

ment in the timed failures/states model.

Lemma C.1

tr =tracesZh

tr ahei/∈ {ext :S|(h,ext)∈PreHist •tracesZext}

⇔

tr ahei/∈ {ext :S|(h,ext)∈PreHist ∧

∃op :POP APP •events of ext = (events of h)ahopi • tracesZext}

We need the following lemmata to prove the current lemma.

Lemma C.2

If trace tr is associated with history h, then trace traheimust be associated with some history

ext whose event sequence component extends that of hby a single operation application.

tr =tracesZh

tr ahei ∈ {ext :History | ∃ op :POP APP •events of ext = (events of h)ahopi • tracesZext}

Lemma C.3

x∈A

x/∈B⇔x/∈B∩A

291

292 Appendix C. Relationship between Simulation and Refinement

Lemma C.4

The following rule formalises the condition under which an intersection operator (or logical

conjunction operator) inside a relational image can be distributed to the outside.

R(|B\A|)∩R(|A|) = ∅

R(|A|)∩R(|B|) = R(|A∩B|)

Lemma C.5

The conclusion of the following lemma matches the antecedent of the previous one.

{ext :S|(h,ext)∈PreHist ∧

¬ ∃ op :POP APP •events of ext = (events of h)ahopi • tracesZext}

∩ {ext :S| ∃ op :POP APP •events of ext = (events of h)ahopi • tracesZext}

=∅

It is valid because the lengths of the traces on the left hand side of the intersection operator

are different from the lengths of the traces on the right hand side.

Proof of Lemma C.1.

tr ahei/∈ {ext :S|(h,ext)∈PreHist •tracesZext}

⇔[Lemmata C.2, C.3]

tr ahei/∈ {ext :S|(h,ext)∈PreHist •tracesZext}

∩ {ext :History | ∃ op :POP APP •

events of ext = (events of h)ahopi • tracesZext}

⇔[Lemmata C.4, C.5;{x:S•P}∩{x:S•Q}={x:S•P∧Q}]

tr ahei/∈ {ext :S|(h,ext)∈PreHist ∧

∃op :POP APP •events of ext = (events of h)ahopi • tracesZext}



Lemma C.6

The following lemma is an immediate consequence of the definition of tracesZ: a trace de-

rived from a history is simply the translation (ev of op) of its sequence of operation applica-

tions.

tr =tracesZh

tr ahei/∈ {ext :S|(h,ext)∈PreHist •

∃op :POP APP •events of ext = (events of h)ahopi • tracesZext}

⇔

e/∈ev of op(|{op :POP APP | ∃ ext :S|(h,ext)∈PreHist •

events of ext = (events of h)ahopi}|)

293

Proof of Theorem 10.4.

Let hc∈HSC and ha∈HSA such that (hc,ha)∈Retrhist(|{MR}|). Let further be D2the second

disjunct within the universal quantifier of the definition of failuresZin Section 9.2.4. Note

that D2is independent of the history hfor which the set of failures is computed. We do thus

not need to consider D2in our proof.

(trc,Xc)∈failuresZ(|{(hc,HSC)}|)

`[def. failuresZ]

trc=tracesZhc∧

∀e:Xc•

trcahei/∈ {ext :HSC |(hc,ext)∈PreHist •tracesZext}

∨D2

`[Lemma C.1]

trc=tracesZhc∧

∀e:Xc•

trcahei/∈ {ext :HSC |(hc,ext)∈PreHist ∧

∃op :POP APP •events of ext = (events of hc)ahopi • tracesZext}

∨D2

`[Lemma C.6]

trc=tracesZhc∧

∀e:Xc•

e/∈ev of op(|{op :POP APP | ∃ ext :HSC |(hc,ext)∈PreHist •

events of ext = (events of hc)ahopi}|)

∨D2

`[Theorem 10.2]

trc=tracesZhc∧

∀e:Xc•

e/∈Retrev(|{MR}|)(|ev of op(|{op :POP APP | ∃ ext :HSA |(ha,ext)∈PreHist ∧

events of ext = (events of ha)ahopi}|)|)

∨D2

`[(∀e:Xc•e/∈R(|Y|)) ⇒(∀e:R∼(|Xc|)•e/∈Y)]

trc=tracesZhc∧

∀e:Retrev(|{MR}|)∼(|Xc|)•

e/∈ev of op(|{op :POP APP | ∃ ext :HSA |(ha,ext)∈PreHist ∧

events of ext = (events of ha)ahopi}|)

∨D2

294 Appendix C. Relationship between Simulation and Refinement

`[Theorem 10.3]

trc∈Retrtr(|{MR}|)(|{tracesZha}|)∧

∀e:Retrev(|{MR}|)∼(|Xc|)•

e/∈ev of op(|{op :POP APP | ∃ ext :HSA |(ha,ext)∈PreHist ∧

events of ext = (events of ha)ahopi}|)

∨D2

`[Lemma C.6]

trc∈Retrtr(|{MR}|)(|{tracesZha}|)∧

∀e:Retrev(|{MR}|)∼(|Xc|)•

(tracesZha)ahei/∈ {ext :HSA |(ha,ext)∈PreHist ∧

∃op :POP APP •events of ext = (events of ha)ahopi • tracesZext}

∨D2

`[Lemma C.1]

trc∈Retrtr(|{MR}|)(|{tracesZha}|)∧

∀e:Retrev(|{MR}|)∼(|Xc|)•

(tracesZha)ahei/∈ {ext :HSA |(ha,ext)∈PreHist •tracesZext}

∨D2

∃tra:Trace;Xa:Refusal |

trc∈Retrtr(|{MR}|)(|{tra}|)∧Xa=Retrev(|{MR}|)∼(|Xc|)•

tra=tracesZha∧

∀e:Xa•

traahei/∈ {ext :HSA |(ha,ext)∈PreHist •tracesZext}

∨D2

`[def. failuresZ;D2is independent of history; X⊆R(|R∼(|X|)|)]

∃tra:Trace;Xa:Refusal |

(tra,Xa)∈failuresZ(|{(ha,HSA)}|)•

trc∈Retrtr(|{MR}|)(|{tra}|)∧Xc⊆Retrev(|{MR}|)(|Xa|)

`[def. Retrfail]

(trc,Xc)∈Retrfail(|{MR}|)(|failuresZ(|{(ha,HSA)}|)|)



Lemma C.7

The following lemma states that the component simultan of of a history does not influence its

membership to the set of histories associated with a specification unit: two histories differing

295

only in the component simultan of are either both members or both no members.

h∈Histories(|{(M,OPS)}|)

events of h =events of h∗∧states of h =states of h∗∧ops of h =ops of h∗

h∗∈Histories(|{(M,OPS)}|)

Lemma C.8

If two histories hcand haare related by Retrhist, then for each prefix of hcthere is a prefix of

hasuch that these prefixes are related by Retrhist.

hc∈HSC;ha∈HSA

(hc,ha)∈Retrhist(|{MR}|)

∀prefc:HSC |(prefc,hc)∈PreHist •

∃prefa:HSA |(prefa,ha)∈PreHist •(prefc,prefa)∈Retrhist(|{MR}|)

Proof of Theorem 10.5.

Let hc∈HSC be arbitrary.

(sc,ℵc)∈timed failuresZ(|{(hc,HSC)}|)

`[def. timed failuresZ]

(∀i,j:N|(i,j)∈simultan of hc•time of(sci) = time of(scj)) ∧

strip sc=tracesZhc∧

∀t:T• ∃ prefc:HSC |(prefc,hc)∈PreHist •

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈failuresZ(|{(prefc,HSC)}|)

`[Theorem 10.2]

∃ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

strip sc=tracesZhc∧

∀t:T• ∃ prefc:HSC |(prefc,hc)∈PreHist •

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈failuresZ(|{(prefc,HSC)}|)

`[Lemma C.8]

∃ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

strip sc=tracesZhc∧

∀t:T• ∃ prefc:HSC |(prefc,hc)∈PreHist •

∃prefa:HSA |(prefa,ha)∈PreHist ∧(prefc,prefa)∈Retrhist(|{MR}|)•

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈failuresZ(|{(prefc,HSC)}|)

`[Theorem 10.4]

∃ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

strip sc=tracesZhc

∀t:T• ∃ prefc:HSC |(prefc,hc)∈PreHist •

296 Appendix C. Relationship between Simulation and Refinement

∃prefa:HSA |(prefa,ha)∈PreHist ∧(prefc,prefa)∈Retrhist(|{MR}|)•

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|failuresZ(|{(prefa,HSA)}|)|)

`[Theorem 10.3]

∃ha:HSA |(hc,ha)∈Retrhist(|{MR}|)•

strip sc∈Retrtr(|{MR}|)(|{tracesZha}|)∧

∀t:T• ∃ prefa:HSA |(prefa,ha)∈PreHist •

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|failuresZ(|{(prefa,HSA)}|)|)

`[Lemma C.7]

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

(∀i,j:N|(i,j)∈simultan of h∗

a•time of(sci) = time of(scj)) ∧

strip sc∈Retrtr(|{MR}|)(|{tracesZh∗

a}|)

∀t:T• ∃ prefa:HSA |(prefa,h∗

a)∈PreHist •

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|failuresZ(|{(prefa,HSA)}|)|)

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

(∀i,j:N|(i,j)∈simultan of h∗

a•time of(sci) = time of(scj)) ∧

strip sc∈Retrtr(|{MR}|)(|{tracesZh∗

a}|)

∀t:T• ∃ prefa:HSA |(prefa,h∗

a)∈PreHist •

∃tr∗

a:Trace;X∗

a:Refusal |(tr∗

a,X∗

a)∈failuresZ(|{(prefa,HSA)}|)•

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|{(tr∗

a,X∗

a)}|)

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

domsa=domsc∧(∀i:domsc•time of(sci) = time of(sai)) •

(∀i,j:N|(i,j)∈simultan of h∗

a•time of(sai) = time of(saj)) ∧

strip sc∈Retrtr(|{MR}|)(|{tracesZh∗

a}|)∧strip sa=tracesZh∗

a∧

∀t:T• ∃ prefa:HSA |(prefa,h∗

a)∈PreHist •

∃tr∗

a:Trace;X∗

a:Refusal |(tr∗

a,X∗

a)∈failuresZ(|{(prefa,HSA)}|)•

strip(sattr t) = tr∗

a∧ {e:Event |(t,e)∈ ℵa}=X∗

a∧

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈Retrfail(|{MR}|)(|{(tr∗

a,X∗

a)}|)

297

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

domsa=domsc∧(∀i:domsc•time of(sci) = time of(sai)) •

(∀i,j:N|(i,j)∈simultan of h∗

a•time of(sai) = time of(saj)) ∧

strip sa=tracesZh∗

a∧

∀t:T• ∃ prefa:HSA |(prefa,h∗

a)∈PreHist •

(strip(sattr t),{e:Event |(t,e)∈ ℵa})∈failuresZ(|{(prefa,HSA)}|)∧

(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|{(strip(sattr t),{e:Event |(t,e)∈ ℵa})}|)

`[def. timed failuresZ]

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

domsa=domsc∧(∀i:domsc•time of(sci) = time of(sai)) •

(sa,ℵa)∈timed failuresZ(|{(h∗

a,HSA)}|)∧

∀t:T•(strip(scttr t),{e:Event |(t,e)∈ ℵc})∈

Retrfail(|{MR}|)(|{(strip(sattr t),{e:Event |(t,e)∈ ℵa})}|)∧

`[def. Retrtf ]

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal •

(sc,ℵc)∈Retrtf (|{MR}|)(|{(sa,ℵa)}|)∧(sa,ℵa)∈timed failuresZ(|{(h∗

a,HSA)}|)

∃h∗

a:HSA |(hc,h∗

a)∈Retrhist(|{MR}|)•

(sc,ℵc)∈Retrtf (|{MR}|)(|timed failuresZ(|{(h∗

a,HSA)}|)|)



Lemma C.9

The first lemma concerns the relation timedst of stseq, which was defined in Chapter 9 in or-

der to facilitate the definition of timed statesZ. For a pair (hc,ha)of histories related by Retrhist,

we can always find a timed state tstafor each timed state tstccomputed by timedst of stseq

such that they are related by Retrtst. We must simply choose the identical injective function

index to time for tstcand tsta.

(ha,hc)∈Retrhist(|{MR}|)

∀tstc:timedst of stseq(|{hc}|)•

∃tsta:timedst of stseq(|{ha}|)•(tstc,tsta)∈Retrtst(|{MR}|)

298 Appendix C. Relationship between Simulation and Refinement

Lemma C.10

For each pair of timed failures related by Retrtf , the time instants recorded in their timed

traces are identical.

∀sa,sc:TimedTrace;ℵa,ℵc:TimedRefusal |((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)•

{t:T| ∃ i:domsc•

chan of(ev of(sci)) ∈ranTermOf ∪ranExecOf ∧time of(sci) = t}

={t:T| ∃ i:domsa•

chan of(ev of(sai)) ∈ranTermOf ∪ranExecOf ∧time of(sai) = t}

Proof of Theorem 10.6.

Let (sa,ℵa)∈TFA and (sc,ℵc)∈TFC be arbitrary such that ((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|).

tstc∈timed statesZ(|{hc}|)(|{(sc,ℵc)}|)

`[def. timed statesZ]

tstc∈timedst of stseq(|{hc}|)∧

domtstc={0R}∪{t:T| ∃ i:domsc•

chan of(ev of(sci)) ∈ranTermOf ∪ranExecOf ∧time of(sci) = t}

`[Lemma C.9]

∃tsta:timedst of stseq(|{ha}|)|(tstc,tsta)∈Retrtst(|{MR}|)•

domtstc={0R}∪{t:T| ∃ i:domsc•

chan of(ev of(sci)) ∈ranTermOf ∪ranExecOf ∧time of(sci) = t}

`[def. Retrtst]

∃tsta:timedst of stseq(|{ha}|)|(tstc,tsta)∈Retrtst(|{MR}|)•

domtsta={0R}∪{t:T| ∃ i:domsc•

chan of(ev of(sci)) ∈ranTermOf ∪ranExecOf ∧time of(sci) = t}

`[Lemma C.10]

∃tsta:timedst of stseq(|{ha}|)|(tstc,tsta)∈Retrtst(|{MR}|)•

domtsta={0R}∪{t:T| ∃ i:domsa•

chan of(ev of(sai)) ∈ranTermOf ∪ranExecOf ∧time of(sai) = t}

`[def. timed statesZ]

∃tsta:timedst of stseq(|{ha}|)|(tstc,tsta)∈Retrtst(|{MR}|)•

tsta∈timed statesZ(|{ha}|)(|{(sa,ℵa)}|)

tstc∈Retrtst(|{MR}|)(|timed statesZ(|{ha}|)(|{(sa,ℵa)}|)|)



299

Lemma C.11

The following lemma states that the relation Retrtf distributes over the parallel composition

operator.

((sa

z,ℵa

z),(sc

z,ℵc

z)) ∈Retrtf (|{MR}|)

((sa

csp,ℵa

csp),(sc

csp,ℵc

csp)) ∈Retrtf (|{MR}|)

((sc

z,sc

csp),ORE) synch sc

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)

((sa

z,sa

csp),ORE) synch sa

ℵa

z\(T×OREX) = ℵa

csp \(T×OREX)

((sa,ℵa

z∪ ℵa

csp),(sc,ℵc

z∪ ℵc

csp)) ∈Retrtf (|{MR}|)

Proof of Theorem 10.7.

((sc,ℵc),tstc)∈tfs of modelINT(|{(CSUC,MC)}|)

`[def. tfs of modelINT]

. . .

∃hc:HSC;sc

z,sc

csp :TimedTrace;ℵc

z,ℵc

csp :TimedRefusal •

(sc

z,ℵc

z)∈timed failuresZ(|{(hc,HSC)}|)∧

((sc

csp,ℵc

csp)/∈timed failuresETFM [[ CSUC.EA ]](MC,CSUC.I∪CSUC.L)

∨(sc

csp,ℵc

csp)∈

timed failuresETCSP [[ CSUC.Behav Behaviour ]](CSUC.Behav,(MC,MC),CSUC.I∪CSUC.L))∧

((sc

z,sc

csp),ORE) synch sc∧

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)∧ ℵc=ℵc

z∪ ℵc

csp ∧

((sc

z,ℵc

z),tstc)∈timed statesZ(|{hc}|)

`[Theorem 10.5]

. . .

∃hc:HSC;sc

z,sc

csp :TimedTrace;ℵc

z,ℵc

csp :TimedRefusal •

∃ha:HSA;sa

z:TimedTrace;ℵa

z:TimedRefusal |

(ha,hc)∈Retrhist(|{MR}|)∧((sa

z,ℵa

z),(sc

z,ℵc

z)) ∈Retrtf (|{MR}|)•

(sa

z,ℵa

z)∈timed failuresZ(|{(ha,HSA)}|)∧

((sc

csp,ℵc

csp)/∈timed failuresETFM [[ CSUC.EA ]](MC,CSUC.I∪CSUC.L)∧

∨(sc

csp,ℵc

csp)∈

timed failuresETCSP [[ CSUC.Behav Behaviour ]](CSUC.Behav,(MC,MC),CSUC.I∪CSUC.L))∧

((sc

z,sc

csp),ORE) synch sc∧

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)∧ ℵc=ℵc

z∪ ℵc

csp ∧

((sc

z,ℵc

z),tstc)∈timed statesZ(|{hc}|)

`[Theorem 10.6]

300 Appendix C. Relationship between Simulation and Refinement

. . .

∃hc:HSC;sc

z,sc

csp :TimedTrace;ℵc

z,ℵc

csp :TimedRefusal •

∃ha:HSA;sa

z:TimedTrace;ℵa

z:TimedRefusal |(ha,hc)∈Retrhist(|{MR}|)∧

((sa

z,ℵa

z),(sc

z,ℵc

z)) ∈Retrtf (|{MR}|)•

∃tsta:TimedState |(tsta,tstc)∈Retrtst(|{MR}|)•

(sa

z,ℵa

z)∈timed failuresZ(|{(ha,HSA)}|)∧

((sc

csp,ℵc

csp)/∈timed failuresETFM [[ CSUC.EA ]](MC,CSUC.I∪CSUC.L)∧

∨(sc

csp,ℵc

csp)∈

timed failuresETCSP [[ CSUC.Behav Behaviour ]](CSUC.Behav,(MC,MC),CSUC.I∪CSUC.L))∧

((sc

z,sc

csp),ORE) synch sc∧

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)∧ ℵc=ℵc

z∪ ℵc

csp ∧

tsta∈timed statesZ(|{ha}|)(|{(sa

z,ℵa

z)}|)

`[Assumptions 10.3 and 10.4]

. . .

∃hc:HSC;sc

z,sc

csp :TimedTrace;ℵc

z,ℵc

csp :TimedRefusal •

∃sa

csp :TimedTrace;ℵa

csp :TimedRefusal |((sa

csp,ℵa

csp),(sc

csp,ℵc

csp)) ∈Retrtf (|{MR}|)•

∃ha:HSA;sa

z:TimedTrace;ℵa

z:TimedRefusal |(ha,hc)∈Retrhist(|{MR}|)∧

((sa

z,ℵa

z),(sc

z,ℵc

z)) ∈Retrtf (|{MR}|)•

∃tsta:TimedState |(tsta,tstc)∈Retrtst(|{MR}|)•

(sa

z,ℵa

z)∈timed failuresZ(|{(ha,HSA)}|)∧

((sa

csp,ℵa

csp)/∈timed failuresETFM [[ CSUA.EA ]](MA,CSUA.I∪CSUA.L)

∨(sa

csp,ℵa

csp)∈

timed failuresETCSP [[ CSUA.Behav Behaviour ]](CSUA.Behav,(MA,MA),CSUA.I∪CSUA.L))∧

((sc

z,sc

csp),ORE) synch sc∧

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)∧ ℵc=ℵc

z∪ ℵc

csp ∧

tsta∈timed statesZ(|{ha}|)(|{(sa

z,ℵa

z)}|)

`[parallel composition is total]

. . .

∃hc:HSC;sc

z,sc

csp :TimedTrace;ℵc

z,ℵc

csp :TimedRefusal •

∃sa

csp :TimedTrace;ℵa

csp :TimedRefusal |((sa

csp,ℵa

csp),(sc

csp,ℵc

csp)) ∈Retrtf (|{MR}|)•

∃ha:HSA;sa

z:TimedTrace;ℵa

z:TimedRefusal |(ha,hc)∈Retrhist(|{MR}|)∧

((sa

z,ℵa

z),(sc

z,ℵc

z)) ∈Retrtf (|{MR}|)•

∃tsta:TimedState |(tsta,tstc)∈Retrtst(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

((sa

z,sa

csp),ORE) synch sa∧ ℵa

z\(T×OREX) = ℵa

csp \(T×OREX)•

301

(sa

z,ℵa

z)∈timed failuresZ(|{(ha,HSA)}|)∧

((sa

csp,ℵa

csp)/∈timed failuresETFM [[ CSUA.EA ]](MA,CSUA.I∪CSUA.L)

∨(sa

csp,ℵa

csp)∈

timed failuresETCSP [[ CSUA.Behav Behaviour ]] (CSUA.Behav,(MA,MA),CSUA.I∪CSUA.L))∧

((sc

z,sc

csp),ORE) synch sc∧

ℵc

z\(T×OREX) = ℵc

csp \(T×OREX)∧ ℵc=ℵc

z∪ ℵc

csp ∧

tsta∈timed statesZ(|{ha}|)(|{(sa

z,ℵa

z)}|)

`[Lemma C.11]

. . .

∃sa

csp :TimedTrace;ℵa

csp :TimedRefusal •

∃ha:HSA;sa

z:TimedTrace;ℵa

z:TimedRefusal •

∃tsta:TimedState |(tsta,tstc)∈Retrtst(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal •

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)∧

((sa

z,sa

csp),ORE) synch sa∧ ℵa

z\(T×OREX) = ℵa

csp \(T×OREX)∧

(sa

z,ℵa

z)∈timed failuresZ(|{(ha,HSA)}|)∧

((sa

csp,ℵa

csp)/∈timed failuresETFM [[ CSUA.EA ]](MA,CSUA.I∪CSUA.L)

∨(sa

csp,ℵa

csp)∈

timed failuresETCSP [[ CSUA.Behav Behaviour ]](CSUA.Behav,(MA,MA),CSUA.I∪CSUA.L))∧

tsta∈timed statesZ(|{ha}|)(|{(sa

z,ℵa

z)}|)

`[def. tfs of modelINT]

(tsta,tstc)∈Retrtst(|{MR}|)∧

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)∧

((sa,ℵa),tsta)∈tfs of modelINT(|{(CSUA,MA)}|)

`[def. RetrInterface/State]

((sc,ℵc),tstc)∈RetrInterface/State(|{RSU}|)(|tfs of modelINT(|{(CSUA,MA)}|)|)



Lemma C.12

For the transition between tfs of modelINT and tfs of modelEXT, we need a lemma similar to

Lemma C.11: the relation Retrtf must distribute over the hiding operator.

((s∗

a,ℵ∗

a),(s∗

c,ℵ∗

c)) ∈Retrtf (|{MR}|)

scttr ORE =s∗

ℵ∗

c=ℵc∪(T×ORE)

sattr ORE =s∗

ℵ∗

a=ℵa∪(T×ORE)

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)

302 Appendix C. Relationship between Simulation and Refinement

Proof of Theorem 10.8.

((sc,ℵc),tstc)∈tfs of modelEXT(|{(CSUC,MC)}|)

`[def. tfs of modelEXT]

∃s∗

c:TimedTrace;ℵ∗

c:TimedRefusal •

((s∗

c,ℵ∗

c),tstc)∈tfs of modelINT(|{(CSUC,MC)}|)∧

scttr ORE =s∗

c∧ ℵ∗

c=ℵc∪(T×ORE)

`[Theorem 10.7]

∃s∗

c:TimedTrace;ℵ∗

c:TimedRefusal •

∃s∗

a:TimedTrace;ℵ∗

a:TimedRefusal;tsta:TimedState |

((s∗

a,ℵ∗

a),(s∗

c,ℵ∗

c)) ∈Retrtf (|{MR}|)∧(tsta,tstc)∈Retrtst(|{MR}|)•

((s∗

a,ℵ∗

a),tsta)∈tfs of modelINT(|{(CSUA,MA)}|)∧

scttr ORE =s∗

c∧ ℵ∗

c=ℵc∪(T×ORE)

`[hiding operator is total]

∃s∗

c:TimedTrace;ℵ∗

c:TimedRefusal •

∃s∗

a:TimedTrace;ℵ∗

a:TimedRefusal;tsta:TimedState |

((s∗

a,ℵ∗

a),(s∗

c,ℵ∗

c)) ∈Retrtf (|{MR}|)∧(tsta,tstc)∈Retrtst(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

sattr ORE =s∗

a∧ ℵ∗

a=ℵa∪(T×ORE)•

((s∗

a,ℵ∗

a),tsta)∈tfs of modelINT(|{(CSUA,MA)}|)∧

scttr ORE =s∗

c∧ ℵ∗

c=ℵc∪(T×ORE)

`[Lemma C.12]

∃s∗

a:TimedTrace;ℵ∗

a:TimedRefusal;tsta:TimedState |

(tsta,tstc)∈Retrtst(|{MR}|)•

∃sa:TimedTrace;ℵa:TimedRefusal |

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)∧

sattr ORE =s∗

a∧ ℵ∗

a=ℵa∪(T×ORE)•

((s∗

a,ℵ∗

a),tsta)∈tfs of modelINT(|{(CSUA,MA)}|)

`[def. tfs of modelEXT]

(tsta,tstc)∈Retrtst(|{MR}|)∧

((sa,ℵa),(sc,ℵc)) ∈Retrtf (|{MR}|)∧

((sa,ℵa),tsta)∈tfs of modelEXT(|{(CSUA,MA)}|)

`[def. RetrInterface/State]

((sc,ℵc),tstc)∈RetrInterface/State(|{RSU}|)(|tfs of modelEXT(|{(CSUA,MA)}|)|)



Appendix D

RT-Z Syntax

The concrete syntax of RT-Z is formally defined in this appendix. Again, we follow the

approach taken in the Z Standard by using the same subset of the standard ISO [1996] as

the syntactic metalanguage. The operators of this syntactic metalanguage that we use in the

following syntax definition are described in Table D.1, which we adopt from [ISO, 2002, p. 3].

As elaborated in Part II, the syntax of RT-Z is built on the syntax of the Z notation. For in-

stance, the TYPES & CONSTANTS section of a specification unit is constituted by a Z section.

Therefore, the following syntax definition refers to non-terminal symbols of the concrete

syntax of the Z notation, as defined in [ISO, 2002, Section 8.2]. For convenience, we map

the identifiers of these non-terminals to corresponding identifiers that clearly indicate their

Z origin.1

For the predicate languages of both the extended timed failures model (ETFM) and the timed

failures/states model (TFSM), we define the syntax of the core language (to understand the

term “core language” see the remarks on p. 134).

In the following syntax definition, non-terminals with the suffix −tok denote corresponding

terminal symbols, e.g.,

1Section and Expression are mapped to ZSect and ZExpr, respectively.

symbol definition

=defines a non-terminal on the left in terms of the syntax on the right

|separates alternatives

,separates notation to be concatenated

{} delimit notation to be repeated zero or more times

[] delimit optional notation

() are grouping brackets

‘‘ delimit a terminal symbol

;delimits a definition

Table D.1: Syntactic metalanguage.

303

304 Appendix D. RT-Z Syntax

{-tok =‘{‘

Moreover, the non-terminal NL denotes a “newline.”

RT-Z Specifications

RTZSpec = [ZSect,NL],(CSpecUnit |ASpecUnit),{NL,(CSpecUnit |ASpecUnit)};

Id =LETTER,{LETTER |DIGIT |‘ ‘};

LETTER =‘a‘|. . . |‘z‘|‘A‘|. . . |‘Z‘;

DIGIT =‘0‘|. . . |‘9‘;

Specification Units

CSpecUnit =‘SPEC.UNIT‘,Id,[ [-tok ,Id,{,-tok ,Id},]-tok ],

[‘EXTENDS‘,Id,{,-tok ,Id}],

NL,CSpecSect,{NL,CSpecSect};

CSpecSect =ExtendsSect

|SubunitsSect

|TypesconstSect

|InterfaceSect

|EnvassumpSect

|LocalSect

|StateSect

|OppredsSect

|BehaviourSect

;

ASpecUnit =‘SPEC.UNIT‘,Id,[ [-tok ,Id,{,-tok ,Id},]-tok ],

[‘EXTENDS‘,Id,{,-tok ,Id}],

NL,ASpecSect,{NL,ASpecSect};

ASpecSect =ExtendsSect

|TypesconstSect

|InterfaceSect

|EnvassumpSect

|IORelSect

|StatepropSect

|BehavpropSect

;

ExtendsSect =‘EXTENDS‘,NL,ExtendsDecl,{;-tok,NL,ExtendsDecl};

ExtendsDecl =Id,{NL,ExtendsItem,;-tok};

305

ExtendsItem =‘instantiate ‘,Id,‘ with ‘,Id,{,-tok ,Id,‘ with ‘,Id}

|‘rename ‘,Id,‘ to ‘,Id,{,-tok ,Id,‘ to ‘,Id}

|‘hide ‘,Id,{,-tok ,Id}

|‘redefine ‘,Id,{,-tok ,Id}

;

SubunitsSect =‘SUBUNITS‘,NL,SubunitsDecl,{;-tok,NL,SubunitsDecl};

SubunitsDecl =‘subunit‘,Id,‘spec.unit‘,Id,{NL,SubunitsItem,;-tok};

SubunitsItem =‘rename ‘,Id,‘ to ‘,Id,{,-tok ,Id,‘ to ‘,Id}

|‘hide ‘,Id,{,-tok ,Id}

|‘instantiate ‘,Id,‘ with ‘,Id,{,-tok ,Id,‘ with ‘,Id}

;

TypesconstSect =‘TYPES & CONSTANTS‘,NL,ZSect;

InterfaceSect =‘INTERFACE‘,NL,

‘port‘,Id,‘domain‘,ZExpr,

{;-tok,NL,‘port‘,Id,‘domain‘,ZExpr};

EnvassumpSect =‘ENVIRONMENTAL ASSUMPTIONS‘,NL,

(PredDef ETFM |EvSetDef),

{NL,(PredDef ETFM |EvSetDef)};

LocalSect =‘LOCAL‘,NL,

‘channel‘,Id,‘domain‘,ZExpr,

{;-tok,NL,‘channel‘,Id,‘domain‘,ZExpr}

;

StateSect =‘STATE‘,NL,ZSect;

OppredsSect =‘OPS & PREDS‘,[ [-tok ,Id,{,-tok ,Id},]-tok ],NL,ZSect;

BehaviourSect =‘BEHAVIOUR‘,NL,(ProcDef |EvSetDef),

{NL,(ProcDef |EvSetDef)};

IORelSect =‘I/O RELATIONS‘,NL,ZSect;

StatepropSect =‘STATE PROPERTIES‘,NL,ZSect;

BehavpropSect =‘BEHAVIOURAL PROPERTIES‘,NL,(PredDef TFSM |EvSetDef),

{NL,(PredDef TFSM |EvSetDef)};

306 Appendix D. RT-Z Syntax

Process Terms

Proc =Id,[ (-tok ,Id,{,-tok ,Id},)-tok ]

|‘Stop‘|‘Skip‘

|Proc,;-tok,Proc

|Proc,‘|[‘,EvSetExpr,‘]|‘,Proc

|Proc,‘|[‘,EvSetExpr,|-tok,EvSetExpr,‘]|‘,Proc

|Proc,‘||| ‘,Proc

|Proc,‘‘,Proc |Proc,‘u‘,Proc

|Id,(-tok ,Proc,)-tok |Id,‘−1‘,(-tok ,Proc,)-tok

|Proc,‘\‘,EvSetExpr |Proc,‘4‘,Proc

|‘u‘,Id,‘∈‘,ZExpr,Proc

|‘|||‘,Id,‘∈‘,ZExpr,Proc

|‘k‘,Id,‘∈‘,ZExpr,[-tok ,EvSetExpr,]-tok ,Proc

|Id,‘?‘,(-tok ,Id,‘:‘,ZExpr,)-tok ‘→‘,Proc

|Id,‘?‘,(-tok ,Id,‘:‘,ZExpr,)-tok ,‘@‘,Id,‘→‘,Proc

|Id,‘!‘,ZExpr,‘→‘,Proc

|‘Wait ‘,TExpr |Proc,‘.‘,{-tok ,TExpr,}-tok ,Proc

|Proc,‘4‘,TExpr,Proc

;

ProcDef =Id,[ (-tok ,Id,{,-tok ,Id},)-tok ],‘b=‘,Proc;

Event Sets

EvSetDef =Id,‘b=‘,EvSetExpr;

EvSetExpr =RefExpr |Id;

Predicates (ETFM)

Pred ETFM =AtomicPred ETFM

|Pred ETFM,‘∧‘,Pred ETFM

|Pred ETFM,‘∨‘,Pred ETFM

|‘¬‘,Pred ETFM

|Pred ETFM,‘⇒‘,Pred ETFM

|Pred ETFM,‘⇔‘,Pred ETFM

|‘∀‘,Id,‘:‘,ZExpr,‘•‘,Pred ETFM

|‘∃‘,Id,‘:‘,ZExpr,‘•‘,Pred ETFM

|‘let ‘,Id,‘== ‘,ZExpr,‘•‘,Pred ETFM

;

PredDef ETFM =Id,[ (-tok ,Id,{,-tok ,Id},)-tok ],‘b=‘,Pred ETFM;

307

AtomicPred ETFM =Id,[ (-tok ,Id,{,-tok ,Id},)-tok ]

|Id,(-tok ,Id,‘b=‘,ZExpr,{,-tok ,Id,‘b=‘,ZExpr},)-tok

|TTrExpr,‘in ‘,TTrExpr

|TTrExpr,‘prefix ‘,TTrExpr

|TrExpr,‘in ‘,TrExpr

|TrExpr,‘prefix ‘,TrExpr

|TRefExpr,‘⊆‘,TRefExpr

|RefExpr,‘⊆‘,RefExpr

|TExpr,‘⩽R‘,TExpr

|TExpr,‘∈‘,TIntExpr

|NatExpr,‘≤‘,NatExpr

;

ValExpr =ZExpr

|‘seq‘,TrExpr

|‘set‘,TrExpr

|‘head ‘,TrExpr |‘foot ‘,TrExpr

|‘first ‘,TTrExpr |‘last ‘,TTrExpr

|‘time‘,TExpr

;

TExpr =‘0R‘|‘1R‘|Id

|TExpr,‘+R‘,TExpr |TExpr,‘∗R‘,TExpr

|‘begin ‘,TTrExpr |‘begin ‘,TRefExpr

|‘begin ‘,(-tok ,TTrExpr, ,-tok ,TRefExpr,)-tok

|‘end ‘,TTrExpr |‘end ‘,TRefExpr

|‘end ‘,(-tok ,TTrExpr, ,-tok ,TRefExpr,)-tok

;

TIntExpr = [-tok ,TExpr, ,-tok ,TExpr,]-tok

|(-tok ,TExpr, ,-tok ,TExpr,)-tok

|[-tok ,TExpr, ,-tok ,TExpr,)-tok

|(-tok ,TExpr, ,-tok ,TExpr,]-tok

;

TTrExpr =‘s‘

|‘h‘,‘i‘

|‘h‘,(-tok ,TExpr, ,-tok ,Id,[‘.‘,ValExpr],)-tok ,

{,-tok ,(-tok ,TExpr, ,-tok ,Id,[‘.‘,ValExpr],)-tok },‘i‘

|TTrExpr,‘a‘,TTrExpr

|‘tail ‘,TTrExpr |‘init ‘,TTrExpr

|TTrExpr,‘ttr ‘,RefExpr |TTrExpr,‘\ttr ‘,RefExpr

|TTrExpr,‘↑ttr ‘,TIntExpr

|TTrExpr,‘ttr ‘,TExpr |TTrExpr,‘|ttr ‘,TExpr

|TTrExpr,‘ttr ‘,TExpr |TTrExpr,‘|ttr ‘,TExpr

|TTrExpr,‘+ttr ‘,TExpr |TTrExpr,‘˙

−ttr ‘,TExpr

;

308 Appendix D. RT-Z Syntax

TRefExpr =‘ℵ‘

|‘∅‘

| {-tok ,(-tok ,TExpr, ,-tok ,Id,[‘.‘,ValExpr],)-tok ,

{,-tok ,(-tok ,TExpr, ,-tok ,Id,[‘.‘,ValExpr],)-tok },}-tok

|TRefExpr,‘∪‘,TRefExpr

| {-tok ,‘head ‘,TTrExpr,}-tok | {-tok ,‘foot ‘,TTrExpr,}-tok

|TRefExpr,‘\tref ‘,RefExpr

|TRefExpr,‘↑tref ‘,TIntExpr

|TRefExpr,‘|tref ‘,TExpr |TRefExpr,‘tref ‘,TExpr

|TRefExpr,‘+tref ‘,TExpr |TRefExpr,‘˙

−tref ‘,TExpr

;

TrExpr =‘h‘,‘i‘|‘h‘,Id,‘.‘,ValExpr,{,-tok ,Id,‘.‘,ValExpr},‘i‘

|TrExpr,‘a‘,TrExpr |‘strip ‘,TTrExpr |‘tail ‘,TrExpr |‘init ‘,TrExpr

|TrExpr,‘tr ‘,RefExpr |TrExpr,‘\tr ‘,RefExpr

;

RefExpr =‘{| ‘,Id,‘|}‘

|‘∅‘| {-tok ,Id,[‘.‘,ValExpr],{,-tok ,Id,[‘.‘,ValExpr]} }-tok

|RefExpr,‘∪‘,RefExpr

| {-tok ,‘first ‘,TTrExpr,}-tok | {-tok ,‘last ‘,TTrExpr}-tok

|‘σ‘,TrExpr |‘σ‘,TTrExpr

;

NatExpr =Id

|‘0‘|‘succ‘,NatExpr

|TTrExpr,‘↓ttr ‘,RefExpr |TrExpr,‘↓tr ‘,RefExpr

;

Predicates (TFSM)

Pred TFSM =AtomicPred TFSM

|Pred TFSM,‘∧‘,Pred TFSM

|Pred TFSM,‘∨‘,Pred TFSM

|‘¬‘,Pred TFSM

|Pred TFSM,‘⇒‘,Pred TFSM

|Pred TFSM,‘⇔‘,Pred TFSM

|‘∀‘,Id,‘:‘,ZExpr,‘•‘,Pred TFSM

|‘∃‘,Id,‘:‘,ZExpr,‘•‘,Pred TFSM

|‘let ‘,Id,‘== ‘,ZExpr,‘•‘,Pred TFSM

;

309

AtomicPred TFSM =AtomicPred ETFM

|Id,‘at ‘,TExpr

|Id,‘before ‘,TExpr

|Id,‘invariant‘

|Id,‘during ‘,TIntExpr

;

310 Appendix D. RT-Z Syntax

Appendix E

Glossary of Timed CSP Notation

We summarise the notation of timed CSP used throughout this thesis. As a convention, s

denotes a timed trace, seq a sequence, ℵa timed refusal, ean event, ta time instant, Aa set of

events, Ia time interval and ca channel.

Σ: universal set of events.

X: termination event (X/∈Σ).

ΣX:Σ∪ {X}.

τ: internal event (τ /∈Σ).

channel(c.v): channel component cof compound event c.v.

value(c.v): value component vof compound event c.v.

{| c|}: set of events that can be communicated along channel c.

hi: empty sequence (timed, untimed trace).

he1, . . . , eNi: sequence (timed, untimed trace) consisting of the elements (timed, untimed

events) e1, . . . , eN.

seq1aseq2: concatenation of sequences (timed/untimed traces) seq1and seq2.

head seq: first element of sequence seq (timed/untimed trace).

tail seq: sequence seq (timed/untimed trace) without the first element.

foot seq: last element of sequence seq (timed/untimed trace).

init seq: sequence seq (timed/untimed trace) without the last element.

#seq: length of sequence seq (timed/untimed trace).

σseq: set of elements appearing in sequence seq (timed/untimed trace).

311

312 Appendix E. Glossary of Timed CSP Notation

seq1in seq2:seq1is a contiguous subsequence of seq2.

seq1prefix seq2:seq1is a prefix of seq2.

strip s: untimed trace corresponding to timed trace s.

first s: first event appearing in timed trace s.

last s: last event appearing in the finite timed trace s.

beginttr s,begintref ℵ,begintfail(s,ℵ): time of the first event in timed trace s, timed refusal ℵor

timed failure (s,ℵ).

endttr s,endtref ℵ,endtfail(s,ℵ): time of the last event in finite timed trace s, least upper bound

of times appearing in timed refusal ℵor timed failure (s,ℵ).

sttr A,ℵtref A,tr tr A: timed trace s, timed refusal ℵor untimed trace tr restricted to the

set of events A.

σ(s),σtref (ℵ): set of events appearing in timed trace sor timed refusal ℵ.

s↓ttr A,tr ↓tr A: number of occurrences of events from Ain timed trace sor untimed trace

tr.

s\ttr A,ℵ \tref A,(s,ℵ)\tfail A,tr \tr A: timed trace s, timed refusal ℵ, timed failure (s,ℵ)or

untimed trace tr without the elements of A.

s↑ttr I,ℵ ↑tref I: projection of timed trace sor timed refusal ℵto time interval I.

sttr t,s|ttr t,ℵ |tref t: timed trace sbefore time t, timed trace sstrictly before time tand

timed refusal ℵbefore time t.

sttr t,s|ttr t,ℵtref t: timed trace safter time t, timed trace sstrictly after time tand timed

refusal after time t.

s+ttr t,ℵ+tref t,(s,ℵ) +tfail t: timed trace s, timed refusal ℵor timed failure (s,ℵ)translated

through ttime units.

s˙

−ttr t,ℵ˙

−tref t,(s,ℵ)˙

−tfail t: timed trace s, timed refusal ℵor timed failure (s,ℵ)translated

back through ttime units.

(s1,ℵ1)(s2,ℵ2): information order on timed failures. (s1,ℵ1)contains less trace and

refusal information than (s2,ℵ2).

sinterleaves (s1,s2):sis an interleaving of the sequences s1and s2.

ssynchA(s1,s2):ssynchronises s1and s2on events in AX.

Bibliography

M. Abadi and L. Lamport. Composing specifications. ACM Transactions on Programming

Languages and Systems, 15(1):73–132, Jan. 1993.

J.-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996.

M. Ainsworth, A. H. Cruickshank, and P. J. L. Wallis. Viewpoint specification and Z. Infor-

mation and Software Technology, 36(1):43–51, 1994.

R. J. Allen. A Formal Approach to Software Architecture. PhD thesis, School of Computer

Science, Carnegie Mellon University, 1997.

K. Araki, A. Galloway, and K. Taguchi, editors. Proceedings of the 1st International Conference

on Integrated Formal Methods, 1999. Springer-Verlag.

J. C. M. Baeten and J. A. Bergstra. Real time process algebra. Formal Aspects of Computing, 3:

142–188, 1991.

E. A. Boiten, H. Bowman, J. Derrick, P. F. Linington, and M. W. A. Steen. Viewpoint consist-

ency in ODP. Computer Networks, 34(3):503–537, Sept. 2000.

E. A. Boiten, H. Bowman, J. Derrick, and M. Steen. Issues in multiparadigm viewpoint

specification. In A. Finkelstein and G. Spanoudakis, editors, SIGSOFT ’96 International

Workshop on Multiple Perspectives in Software Development (Viewpoints ’96), pages 162–166.

ACM, 1996.

T. Bolognesi and E. Brinksma. Introduction to the ISO specification language LOTOS. Com-

puter Networks and ISDN Systems, 14:25–59, 1987.

T. Bolognesi, F. Lucidi, and S. Trigila. Converging towards a timed LOTOS standard. Com-

puter Standards & Interfaces, 16:87–118, 1994.

T. Bolognesi, J. van de Lagemaat, and C. Vissers. LOTOSphere: Software Development with

LOTOS. Kluwer Academic Publishers, 1995.

H. Bowman, E. Boiten, J. Derrick, and M. Steen. Viewpoint consistency in ODP, a general

interpretation. In E. Najm and J.-B. Stefani, editors, First IFIP International Workshop on

Formal Methods for Open Object-Based Distributed Systems, pages 189–204. Chapman & Hall,

Mar. 1996.

H. Bowman, E. A. Boiten, J. Derrick, and M. W. A. Steen. Strategies for consistency checking

based on unification. Science of Computer Programming, 33:261–298, Apr. 1999a.

313

314 Bibliography

H. Bowman, M. Steen, E. Boiten, and J. Derrick. A formal framework for viewpoint consist-

ency. Computing Laboratory Technical Report 22-99, University of Kent at Canterbury,

1999b.

M. Broy, F. Dederichs, C. Dendorfer, M. Fuchs, T. F. Gritzner, and R. Weber. The design of

distributed systems — an introduction to FOCUS. Technical Report TUM-I9202, Institut

f¨

ur Informatik, Technische Universit¨

at M¨

unchen, 1992.

J. Bryans, J. Davies, and S. Schneider. Towards a denotational semantics for ET-LOTOS.

In I. Lee and S. A. Smolka, editors, CONCUR ’95: Concurrency Theory, 6th International

Conference, number 962 in Lecture Notes in Computer Science, pages 269–283. Springer-

Verlag, 1995.

R. B¨

ussow, R. Geisler, W. Grieskamp, and M. Klar. The µSZ notation version 1.0. Technical

Report 97–26, Technische Universit¨

at Berlin, Fachbereich Informatik, 1997.

R. B¨

ussow and W. Grieskamp. The Z of ZETA. Technische Universit¨

at Berlin, December 1998.

The ZETA System Documentation.

M. Butler, L. Petre, and K. Sere, editors. Proceedings of the 3rd International Conference on

Integrated Formal Methods, IFM 2002, number 2335 in Lecture Notes in Computer Science,

2002. Springer-Verlag.

Z. Chaochen, C. A. R. Hoare, and A. P. Ravn. A calculus of durations. Information Processing

Letters, 40(5):269–276, Dec. 1991.

C. Choppy, P. Poizat, and J.-C. Royer. A global semantics for views. In International Conference

on Algebraic Methodology and Software Technology, AMAST’2000, number 1816 in Lecture

Notes in Computer Science, pages 165–180. Springer-Verlag, 2000.

E. Clarke and J. Wing. Formal methods: State of the art and future directions. Technical

Report CMU-CS-96-178, Carnegie Mellon University, Aug. 1996.

A. Coen-Porisini, R. A. Kemmerer, and D. Mandrioli. Specification of realtime systems using

ASTRAL. IEEE Transactions on Software Engineering, 23(9):572–598, Sept. 1997.

B. A. Davey and H. A. Priestley. Introduction to Lattices and Order. Cambridge University

Press, 1990.

J. Davies. Specification and Proof in Real-Time CSP. Technical monograph, Oxford University,

1993. Cambridge University Press.

J. Davies and S. Schneider. Real-time CSP. In T. Rus and C. Rattray, editors, Theories and

Experiences for Real-Time System Development. World Scientific Publishing Company, Inc.,

Feb. 1995.

J. W. de Bakker, C. Huizing, W. P. de Roever, and G. Rozenberg, editors. Real-Time: Theory in

Practice, number 600 in Lecture Notes in Computer Science, 1991. Springer-Verlag.

R. de Nicola and M. C. B. Hennessy. Testing equivalences for processes. Theoretical Computer

Science, 34:83–133, 1984.

Bibliography 315

J. Derrick and E. Boiten. Refinement in Z and Object-Z. Springer-Verlag, 2001.

J. Derrick, E. Boiten, H. Bowman, and M. Steen. Viewpoints and consistency: translating

LOTOS to Object-Z. Computer Standards and Interfaces, 21:251–272, Aug. 1999.

J. Derrick and G. Smith. Structural refinement in Object-Z / CSP. In Grieskamp et al. [2000].

J. S. Dong and B. Mahony. Active object in TCOZ. In J. Staples, M. Hinchey, and S. Liu,

editors, Proceedings of the 1998 IEEE International Conference on Formal Engineering Methods

(ICFEM’98), pages 16–25. IEEE Computer Society Press, 1998.

H. Ehrig and M. Große-Rhode, editors. Proceedings of INT 2002 : Second International Workshop

on Integration of Specification Techniques for Applications in Engineering, 2002. URL http:

//tfs.cs.tu-berlin.de/˜mgr/int02/proceedings.html.

H. Ehrig and B. Mahr. Fundamentals of algebraic specifications. Springer-Verlag, 1985.

H. B. Enderton. Elements of set theory. Academic Press, 1977.

ESPRESS. Engineering of safety-critical embedded systems (research project), 1998. URL

http://www.first.gmd.de/˜espress/.

C. Fidge. A comparative introduction to CSP, CCS and LOTOS. Technical Report 93-24,

Software Verification Research Centre, Department of Computer Science, University of

Queensland, 1994.

C. J. Fidge, I. J. Hayes, A. P. Martin, and A. K. Wabenhorst. A set-theoretic model for real-

time specification and reasoning. In J. Jeuring, editor, Mathematics of Program Construction

(MPC’98), number 1422 in Lecture Notes in Computer Science, pages 188–206. Springer-

Verlag, 1998.

A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nuseibeh. Inconsistency handling in

multi-perspective specifications. IEEE Transactions on Software Engineering, 20(8):569–578,

1994.

A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: A

framework for integrating multiple perspectives in systems development. International

Journal of Software Engineering and Knowledge Engineering, 1(2):31–58, 1992.

C. Fischer. CSP-OZ: A combination of Object-Z and CSP. In H. Bowman and J. Derrick,

editors, Formal Methods for Open Object-Based Distributed Systems (FMOODS ’97), volume 2,

pages 423–438. Chapman & Hall, 1997.

C. Fischer. How to combine Z with a process algebra. In J. P. Bowen, A. Fett, and M. G.

Hinchey, editors, ZUM ’98: The Z Formal Specification Notation, number 1493 in Lecture

Notes in Computer Science, pages 5–23. Springer-Verlag, 1998.

C. Fischer. Combination and Implementation of Processes and Data: from CSP-OZ to Java. PhD

thesis, Fachbereich Informatik, Universit¨

at Oldenburg, 2000.

C. Fischer and H. Wehrheim. Model-checking CSP-OZ specifications with FDR. In Araki

et al. [1999], pages 315–334.

316 Bibliography

Formal Systems (Europe) Ltd. Failures-Divergence Refinement – FDR2 User Manual, 2000. URL

http://www.fsel.com/fdr2_manual.html.

W. Grieskamp, M. Heisel, and H. D¨

orr. Specifying embedded systems with statecharts and

Z: an agenda for cyclic software components. Science of Computer Programming, 40(1):31–

57, 2001.

W. Grieskamp, T. Santen, and B. Stoddart, editors. Proceedings of the 2nd International Confer-

ence on Integrated Formal Methods, IFM 2000, number 1945 in Lecture Notes in Computer

Science, 2000. Springer-Verlag.

M. Große-Rhode. Semantic integration of heterogeneous formal specifications via trans-

formation systems. Technischer Bericht 2001/13, Technische Universit¨

at Berlin, Fakult¨

f¨

ur Elektrotechnik und Informatik, 2001.

R. K. Gupta. Introduction to embedded systems. Course Material, 2002. URL http://

www1.ics.uci.edu/˜rgupta/ics212.html. University of California at Irvine.

A. G. Hamilton. Numbers, sets and axioms: the apparatus of mathematics. Cambridge University

Press, 1982.

D. Harel. Statecharts: a visual formalism for complex systems. Science of Computer Program-

ming, 8:231–274, 1987.

D. Harel and A. Naamad. The STATEMATE semantics of Statecharts. ACM Transactions on

Software Engineering and Methodology, 5(4):293–333, 1996.

A. Haxthausen and C. George. A concurrency case study using RAISE. In Woodcock and

Larsen, editors, FME’93: Industrial-Strength Formal Methods, number 670 in Lecture Notes

in Computer Science, pages 367–387. Springer-Verlag, 1993.

M. Heisel. Improving Software Quality with Formal Methods. Habilitation thesis, Technische

Universit¨

at Berlin, 1997.

M. Heisel and C. S¨

uhl. Combining Z and Real-Time CSP for the development of safety-

critical systems. In Proceedings 15th International Conference on Computer Safety, Reliability

and Security. Springer-Verlag, 1996.

M. Heisel and C. S¨

uhl. Methodological support for formally specifying safety-critical soft-

ware. In Proceedings 16th International Conference on Computer Safety, Reliability and Security.

Springer-Verlag, 1997.

C. Heitmeyer, R. Jeffords, and B. Labaw. Automated consistency checking of requirements

specifications. ACM Transactions on Software Engineering and Methodology, 5(3):231–261,

1996.

C. Heitmeyer and D. Mandrioli. Formal Methods for Real-Time Computing. John Wiley & Sons,

1996.

S. Helke and F. Kamm¨

uller. Representing hierarchical automata in interactive theorem

provers. In R. J. Boulton and P. B. Jackson, editors, Proceedings of the 14th International

Conference on Theorem Proving in Higher Order Logics (TPHOLs 2001), number 2152 in Lec-

ture Notes in Computer Science, pages 233–248. Springer-Verlag, 2001.

Bibliography 317

M. Hennessy and T. Regan. A process algebra for timed systems. Information and Computa-

tion, 117(2):221–239, 1995.

C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.

J. Hoenicke and E.-R. Olderog. Combining specification techniques for processes, data and

time. In Butler et al. [2002], pages 245–266.

ISO. Information Technology – Syntactic Metalanguage – Extended BNF. International

Standard ISO/IEC 14977:1996, International Organization for Standardization, 1996.

ISO. Information processing systems – Open systems interconnection – Estelle – A formal

description technique based on an extended state transition model. International Standard

9074, International Organization for Standardization, 1997.

ISO. Information technology – Open Distributed Processing – Reference model: Overview.

International Standard 10746-1, International Organization for Standardization, 1998.

ISO. Information Technology – Z Formal Specification Notation – Syntax, Type System and

Semantics. Draft International Standard ISO/IEC 13568:2002, International Organization

for Standardization, 2002.

F. Jahanian and A. K. Mok. Modechart: A specification language for real-time systems. IEEE

Transactions on Software Engineering, 20(12):933–947, 1994.

C. B. Jones. Systematic Software Development Using VDM. Prentice-Hall, 1986.

M. B. Josephs. A state-based approach to communicating processes. Distributed Computing,

3:9–18, 1988.

S. Kalvala. A formulation of TLA in Isabelle. In Proc. 8th International Higher Order Theorem

Proving, pages 214–228, 1995.

Kolyang, T. Santen, and B. Wolff. A structure preserving encoding of Z in Isabelle/HOL. In

J. von Wright, J. Grundy, and J. Harrison, editors, Theorem Proving in Higher Order Logics

— 9th International Conference, number 1125 in Lecture Notes in Computer Science, pages

283–298. Springer-Verlag, 1996.

P. Koopman. Embedded systems in the real world. Course Material: Dependable Em-

bedded Systems, 1999. URL http://www-2.cs.cmu.edu/˜koopman/des_s99/emb_

sys_intro.pdf. Carnegie Mellon University.

P. J. Koopman. Embedded system design issues (the rest of the story). In IEEE International

Conference on Computer Design (ICCD ’96), pages 310–319. IEEE Computer Society, 1996.

K. Kronl¨

of, editor. Method Integration—Concepts and Case Studies. Wiley Series in Software

Based Systems. John Wiley & Sons, 1993.

L. Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and

Systems, 16(3):872–923, May 1994.

318 Bibliography

L. Lamport. Specifying concurrent systems with TLA+. In M. Broy and R. Steinbr¨

uggen,

editors, Calculational System Design, volume 173 of NATO: Computer & Systems Sciences.

IOS Press, 2000.

L. L´

eonard and G. Leduc. An introduction to ET-LOTOS for the description of time-sensitive

systems. Computer Networks and ISDN Systems, 29:271–292, 1997.

N. G. Leveson. Safeware: System Safety and Computers. Addison-Wesley, 1995.

B. Mahony and J. S. Dong. Blending Object-Z and Timed CSP: The semantics of TCOZ.

Technical Report 97-24, Commonwealth Scientific and Industrial Research Organisation

(CSIRO), 1997.

B. Mahony and J. S. Dong. Blending Object-Z and Timed CSP: An introduction to TCOZ. In

Proceedings of the 20th International Conference on Software Engineering, pages 95–104. IEEE

Computer Society Press, 1998a.

B. Mahony and J. S. Dong. Network topology and a case study in TCOZ. In J. P. Bowen,

A. Fett, and M. G. Hinchey, editors, ZUM ’98: The Z Formal Specification Notation, number

1493 in Lecture Notes in Computer Science, pages 308–327. Springer-Verlag, 1998b.

B. Mahony and J. S. Dong. Overview of the semantics of TCOZ. In K. Araki, A. Galloway,

and K. Taguchi, editors, Proceedings of the 1st International Conference on Integrated Formal

Methods. Springer-Verlag, 1999a.

B. Mahony and J. S. Dong. Sensors and actuators in TCOZ. In J. Wing, J. Woodcock, and

J. Davies, editors, FM’99—Formal Methods, number 1709 in Lecture Notes in Computer

Science, pages 1166–1185. Springer-Verlag, 1999b.

B. Mahony and J. S. Dong. Timed Communicating Object Z. IEEE Transactions on Software

Engineering, 26(2):150–176, 2000.

Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems—Specification.

Springer-Verlag, 1992.

A. J. R. G. Milner. Communication and Concurrency. Prentice Hall, 1989.

F. Moller and C. Tofts. A temporal calculus of communicating systems. In J. C. M. Baeten

and J. W. Klop, editors, CONCUR ’90: Theories of Concurrency: Unification and Extension,

number 458 in Lecture Notes in Computer Science, pages 401–415. Springer-Verlag, 1990.

X. Nicollin and J. Sifakis. An overview and synthesis on timed process algebras. In de Bakker

et al. [1991], pages 526–548.

J. Ostroff. Verification of safety critical systems using TTM/RTTL. In de Bakker et al. [1991],

pages 573–602.

D. L. Parnas and J. Madey. Functional documents for computer systems. Science of Computer

Programming, 25(1):41–61, 1995.

L. C. Paulson. ML for the Working Programmer. Cambridge University Press, 1991.

Bibliography 319

L. C. Paulson. Isabelle’s Object-Logics. Computer Laboratory, University of Cambridge, 1996.

B. F. Potter, J. E. Sinclair, and D. Till. An Introduction to Formal Specification and Z. Prentice

Hall International Series in Computer Science, 2nd edition, 1996.

A. P. Ravn, H. Rischel, and K. M. Hansen. Specifying and verifying requirements of real-time

systems. IEEE Transactions on Software Engineering, Jan. 1993.

A. W. Roscoe. An alternative order for the failures model. Journal of Logic and Computation, 2

(5):557–577, Oct. 1992.

A. W. Roscoe. Unbounded non-determinism in CSP. Journal of Logic and Computation, 3(2):

131–172, Apr. 1993.

A. W. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1998.

A. W. Roscoe and G. Barrett. Unbounded nondeterminism in CSP. In Mathematical Founda-

tions of Programming Semantics, number 442 in Lecture Notes in Computer Science, pages

160–193. Springer-Verlag, 1989.

M. Saaltink. The Z/EVES system. In J. P. Bowen, M. G. Hinchey, and D. Till, editors, ZUM

’97: Z Formal Specification Notation. 11th International Conference of Z Users, number 1212 in

Lecture Notes in Computer Science, pages 72–85. Springer-Verlag, 1997.

B. Scattergood. The Semantics and Implementation of Machine-Readable CSP. PhD thesis, Oxford

University Computing Laboratory, Programming Research Group, 1998.

S. Schneider. Correctness and Communication in Real-time Systems. PhD thesis, Oxford Univer-

sity Computing Laboratory, Programming Research Group, 1990.

S. Schneider. Abstraction and testing. In J. M. Wing, J. Woodcock, and J. Davies, editors,

FM’99 – Formal Methods, number 1708 in Lecture Notes in Computer Science, pages 738–

757. Springer-Verlag, 1999a.

S. Schneider. Concurrent and Real-time Systems: The CSP Approach. John Wiley & Sons, 1999b.

A. Sherif, A. Sampaio, and S. Cavalcante. An integrated approach to specification and val-

idation of real-time systems. In J. N. Oliveira and P. Zave, editors, Proceedings of FME

2001: Formal Methods for Increasing Software Productivity, number 2021 in Lecture Notes in

Computer Science, pages 278–299. Springer-Verlag, 2001.

G. Smith. A semantic integration of Object-Z and CSP for the specification of concurrent

systems. In J. Fitzgerald, C. Jones, and P. Lucas, editors, Proceedings of FME’97: Industrial

Benefit of Formal Methods, number 1313 in Lecture Notes in Computer Science, pages 62–81.

Springer-Verlag, 1997.

G. Smith. The Object-Z Specification Language. Advances in Formal Methods Series. Kluwer

Academic Publishers, 2000.

G. Smith. An integration of Real-Time Object-Z and CSP for specifying concurrent real-time

systems. In Butler et al. [2002], pages 267–285.

320 Bibliography

G. Smith and J. Derrick. Specification, refinement and verification of concurrent systems—an

integration of Object-Z and CSP. Formal Methods in System Design, 18(3):249–284, 2001.

G. Smith and I. J. Hayes. Towards Real-Time Object-Z. In Araki et al. [1999], pages 49–65.

SoftSpez. Software specification: Integration of software specification techniques for ap-

plications in engineering. DFG Priority Programme, 2000. URL http://tfs.cs.

tu-berlin.de/projekte/indspec/SPP/index.html.

I. Sommerville. Software Engineering. Addison-Wesley, 5th edition, 1995.

J. M. Spivey. The Z Notation: A Reference Manual. Prentice-Hall, 2nd edition, 1992.

C. S¨

uhl. RT-Z: An integration of Z and timed CSP. In Araki et al. [1999], pages 29–48.

C. S¨

uhl. Applying RT-Z to develop safety-critical systems. In T. Maibaum, editor, Proceedings

of the Third International Conference on Fundamental Approaches to Software Engineering (FASE

2000), number 1783 in Lecture Notes in Computer Science, pages 51–65. Springer-Verlag,

2000.

C. S¨

uhl. An overview of the integrated formalism RT-Z. Formal Aspects of Computing, 13(2):

94–110, 2002.

W. A. Sutherland. Introduction to Metric and Topological Spaces. Oxford University Press, 1975.

H. Tej and B. Wolff. A corrected failure-divergence model for CSP in Isabelle/HOL.

In J. Fitzgerald, C. B. Jones, and P. Lucas, editors, FME’97: Industrial Applications and

Strengthened Foundations of Formal Methods, number 1313 in Lecture Notes in Computer

Science, pages 318–337. Springer-Verlag, Sept. 1997.

H. E. Treharne. Combining Control Executives and Software Specifications. PhD thesis, Depart-

ment of Computer Science, Royal Holloway, University of London, 2000.

UK Ministry of Defence. Defence standard 00-55: Requirements for safety related software

in defence equipment, Aug. 1997.

UNIFORM. Universal formal methods workbench (research project), 1998. URL http:

//www.informatik.uni-bremen.de/uniform/.

M. Weber. Systematic design of embedded control systems. GMD-Bericht 283, GMD—

Forschungszentrum Informationstechnik GmbH, 1997.

J. C. P. Woodcock and J. Davies. Using Z: Specification, Refinement, and Proof. Prentice Hall,

1996.

J. B. Wordsworth. Software Development with Z. Addison-Wesley, 1992.

P. Zave and M. Jackson. Conjunction as composition. ACM Transactions on Software Engin-

eering and Methodology, 2(4):379–411, Oct. 1993.

P. Zave and M. Jackson. Where do operations come from: A multiparadigm specification

technique. IEEE Transactions on Software Engineering, 22(7):508–528, 1996.

Index of Terms

abstract data types . . . . . . . . . . . . . . . . . . 160

abstract language constructs . . . . . 15, 229

abstraction levels . . . . . . . . . . . . . . 4, 15, 223

ACPρ...............................263

ACT ONE . . . . . . . . . . . . . . . . . 23, 182, 263

admissible . . . . . . . . . . . . . . . . . . . . . 259, 261

aggregation . . . . . . . . . . . . . . . . . 66–82, 200

indexed . . . . . . . . . . . . .78–81, 194, 198

simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

aggregation hierarchy . . . . 68, 71, 75, 105

algebraic laws . . . . . . . . . . . . . . . . . . . . . . . . 24

alternating bit protocol . . . . . . . . . . . 54, 95

architectural description language . . . 262

architecture . . . . . . . . . . . . . . . . . 10, 46, 183

ASTRAL . . . . . . . . . . . . . . . . . . . . . . . . . 54, 68

B ....................................54

base formalisms . . . . . . . . . 31, 39, 171, 176

BaseStates ............................88

behaviour

continuous . . . . . . . . . . . . . . . . . . 16, 209

discrete . . . . . . . . . . . . . . . . . . . . . . . . . . 16

hybrid . . . . . . . . . . . . . . . . . . . . . . . 13, 16

BehaviourExt ..........................89

blocking view . . . . . . . . . . . . . . . . . . . 49, 159

calculus . . . . . . . . . . . . . . . . . . . 227–230, 260

CCS ............................23, 263

channels . . . . . . . . . . . . . . . . . . . . . . . . 12, 236

classification . . . . . . . . . . . . . . . . . . 4, 31, 223

closed system view . . . . 12, 105, 151, 156

coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

complexity . . . . . . . . . . . . . . . . 4, 53, 65, 225

component-oriented approaches . . . . . . 31

compositional . . . . . . . . . . . . . 236, 247, 260

compositionality . . . . . . . . . . . . . . . 220, 226

computational model . . . . . . . . . . . . . . . .238

concrete language constructs. . . . . 15, 229

concurrent . . . 7, 53, 69–71, 78, 106–108,

205, 225

consistency . . . . . . . . . . . . . . . . . . . . . . 27, 31

checks . . . . . . . . . . . . . . . . . . . . . . 27, 230

contraction mappings . . . . . . . . . . 148, 257

control behaviour . . . . . . . . . . . . . . . . 37, 46

correspondences . . . . . . . . . . . . . . 27, 33, 34

CSP ....................17, 21, 183, 236

CSP part . . . . . . . . . . . . . . . . . 39, 44, 46, 105

CSP-OZ. . . . . . . . 17–19, 33, 104, 171–176

data-processing tasks . . . . . . . . . . . . . . . . . 15

data-related characteristics. . . . . 37, 39, 45

decomposition style . . . . . . . . . . . . . . 29, 32

delayed reference expansion . . . . . . . . . . 77

development process . . . . . . . . . . . . . . . . 4, 9

distributed . . . . . . . . . . . . . . . . . . . . . . . 7, 205

distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 78

double event approach . . . . . . . . . . . . . . . 48

duality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249

Duration Calculus . . . . . . . . . . . . . . . . . . .264

dynamic behaviour . . . . . . . . 37, 39, 60, 62

embedded systems . . . . . . . . . . . . . . 3, 7, 37

environment . . . . . . . . . . . . . . . . . . . . 11, 236

environmental assumptions 13, 206, 224

ET-LOTOS . . . . . . . . . . . . . . . . . . . . . . . . . . 263

event transitions . . . . . . . . . . . . . . . . . . . .238

events . . . . . . . . . . . . . . . . . . . . . . 11, 12, 236

operation-related . . . . . . . . . . . . . . . . 124

plain............................124

evolution transitions . . . . . . . . . . . . . . . . 238

321

322 Index of Terms

execution . . . . . . . . . . . . . . . . . . . . . . . . . . .245

maximal . . . . . . . . . . . . . . . . . . . . . . . .245

extended timed failures model . . 109, 122

extension . . . . . . . . . . . . . . . . . . . . . . . . 83–94

failures . . . . . . . . . . . . . . . . . . . . . . . . 124, 127

failures–divergences model . 22, 104, 158

fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

finite variability . . . . . . . . . . . . . . . . 125, 247

fixed points . . . . . . . . . . . . . . . . . . . . 148, 256

least ............................148

formal description technique. . . . . . . . . . 23

formal methods . . . . . 3, 24, 226, 229, 230

formal semantics . . . . . . . . . . . . . . . . . . . . . 15

formal specification . . . . . . . . . . . . . . . . . 224

gas burner . . . . . . . . . . . . . . . . . . . . . . . . . .207

global definitions. . . . . . . . . . . . . . . . 53, 184

global invariants . . . . 68–71, 75, 106, 225

GlobalInv .............................68

hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

hierarchical decomposition . . . . . . . . . . . 53

history . . . . . . . . . . . . . . . . . . . . . . . . . 110, 117

history model . . . . . . . . . . . . . 109, 117–122

I/O relations . . . . . . . . . . . . . . . . . . . . . . . . . 40

immediate reference expansion . . . . . . . 76

incremental . . . . . . . . . . . . . . . . . . . . . . 66, 83

information hiding . . . . . . . . . . . . . . . . . . . 14

InitExt ................................88

integrated formalism . . . . . . . . . . . . . . . . . . 3

integration

conserving . 4, 21, 23, 33, 37, 39, 103,

223

monolithic . . . . . . . . . . . . 17, 18, 21, 33

interface . . . . . . . . . . . . . . . . . . . . . . . . 12, 236

intermediate semantic models . . . . . . . 109

IO refinement . . . . . . . . . . . . . . . . . . 152, 160

library . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 84

lifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

links . . . . . . . . . . . . . . . . . . . . . 39, 46, 99, 111

LOTOS . . . . . . . . . 23–24, 34, 54, 180–182

maximal parallelism . . . . . . . . . . . . 237, 240

maximal progress . . . . . . . . . 237, 242, 245

methodological support . . . . . . . . . 25, 229

metric space . . . . . . . . . . . . . . . . . . . 256, 257

complete . . . . . . . . . . . . . . . . . . . 148, 256

Modechart/RTL. . . . . . . . . . . . . . . . . . . . . 264

model checker . . . . . . . . . . . . . . . . . . . . . .229

models (Z) . . . . . . . . . . . . . . . . . . . . . 110, 234

multi-lift system . . . . . . . . . . . . . . . . . . . .183

multi-viewpoint specification . . . . . . . . . 31

mutual recursion . . . . . . . . . . . . . . . . . . . . 244

non-interference conditions . . . . . . . . . . 106

nondeterminism . . . . . . . . . . . . . . . . . . . . 104

unbounded . . . . . . . . . . . . . . . . 148, 258

Object-Z . . . 17, 18, 19, 20, 21, 54, 66, 71,

183, 225

open system view . . . . . 12, 105, 151, 157

operation

execution . . . . . . . . . . . . . . . . . . . . . . . . 48

invocation . . . . . . . . . . . . . . . . . . 47, 116

termination . . . . . . . . . . . . . . . . . 47, 116

operation-related events . . . . . . . . . . . . . . 77

parallel . . . . . . . . . . . . . . . . . . . see concurrent

partial operation events . . . . . . . . . . . . .116

partial order

complete . . . . . . . . . . . . . . . . . . . . . . . . 148

partial specifications. . . . . . . . . . . . . . . . . . 31

port .................................58

pre-history . . . . . . . . . . . . . . . . . . . . . . . . . .121

predicate language . . . 133, 134, 141, 224

process algebras . . . . . . . . . . . . . . . . . . . . . 236

process control . . . . . . . . . . . . . . . . . . . . . . 3, 7

process term language . . . . . . . 46, 60, 238

process variable . . . . . . . . . . . . . . . . . . . . . 243

processes . . . . . . . . . . . . . . . . . . . . . . . . . . .236

promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

schema . . . . . . . . . . . . . . . . . . . . . . 75, 80

reactive . . . . . . . . . . . . . . . . . . . . . . . 7, 15, 262

Index of Terms 323

real numbers . . . . . . . . . . . . . . . . . . . . . . . . 122

real-time . . . . . . . . . . . . . . . . . . . . 3, 183, 235

constraints . . . . . . . . . . . . . 7, 15, 37, 39

reduction process . 66, 69, 72, 78, 86, 162

refinement . . . . . . . .4, 5, 21, 151–167, 226

order . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

techniques . . . . . . . . . . . . . . . . . 158, 223

refusals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

reliability . . . . . . . . . . . . . . . . . . . . . . . 3, 8, 15

renaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

retrieve relations . . . . . . . . . . . . . . . . . . . .152

reuse . . . . . . . . . . . . . 4, 21, 33, 83, 176, 224

RSL...........................24–25, 33

safety . . . . . . . . . . . . . . . . . 13, 207, 225, 259

constraints . . . . . . . . . . . . . . . . . . 12, 207

safety-critical. . . . . . . . . . 3, 7, 15, 214, 225

schema calculus . . . . . . . . . . . . . . . . . . . . . 235

section

BEHAVIOUR......................60

BEHAVIOURAL PROPERTIES. . . . . 62

ENVIRONMENTAL ASSUMPTIONS.58

INTERFACE......................57

I/O RELATIONS ................61

LOCAL ...........................58

OPS & PREDS ....................59

STATE ...........................58

STATE PROPERTIES ............62

SUBUNITS .......................71

TYPES & CONSTANTS ............55

sections (RT-Z) . . . . . . . . . . . . . . . . . . . . . . . 54

sections (Z) . . . . . . . . . . . . . . . . . . . . . . . . . 233

semantic integration . . . . . . . . . . . . . . . . . 144

semantic metalanguage . . . . . . . . . . . . . . 112

semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

denotational 5, 19, 25, 103–146, 223,

224, 229, 234

operational . . . . . . . . . . . . 24, 229, 238

separation of concerns . . . . . . . 53, 70, 223

simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

downward . . . . . . . . . . . . . . . . . . . . . .158

upward . . . . . . . . . . . . . . . . . . . . . . . . .158

single-event approach . . . . . . . . . . . . . . . . 48

software design . . . . . . . . . . . . . . . . . . 11, 45

specification . . . . . . . . . . . . . . . . . 11, 14

software engineering . . . . . . . . . . . . . . . . . 53

software requirements

elicitation . . . . . . . . . . . . . . . . . . . . . . . . 10

specification . . . . . . . . . . . . . . . . . 11, 13

specification macros . . . . . . . . 43, 141, 259

specification units . . . . . . . . . . . . . . . . . 5, 53

abstract . . . . . . . . . . . . . . . . . . . . . . 61–62

concrete . . . . . . . . . . . . . . . . . . . . . 54–55

parametrised . . . . . . . . . . . . . . . . . . . . . 95

retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 152

spin ................................246

state guards . . . . . . . . . . . . . . . . . . . . . . . . . . 21

state-based techniques . . . . . . . . . . . . . . . 158

state-oriented . . . . . . . . . . . . . . 46, 111, 234

state-transition systems . . . . . . . . . 112, 158

StateExt ...............................88

static structure . . . . . . . . . . . . . . . . 37, 39, 45

stimulus–response behaviour . 37, 46, 60,

197

structuring operators . . . . . 5, 20, 224, 225

SubunitStates .........................74

syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 303

system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

system design . . . . . . . . . . . . . . . . . . . . 10, 45

specification . . . . . . . . . . . . . . . . . . . . . 10

system model . . . . . . . . . 4, 11, 23, 29, 172

system requirements

analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

specification . . . . . . . . . . . . . . . . . . . . . . 9

systems engineering . . . . . . . . . . . . . . . . . . 53

TCCS...............................263

TCOZ . . . . 20–21, 33, 103, 176–180, 183

temporal logic . . . . . . . . . . . . . . . . . . . . . . . 30

temporal ordering . . . . . . . . . . . 39, 62, 247

theorem prover . . . . . . . . . . . . . . . . . . . . .230

time additivity . . . . . . . . . . . . . . . . . . . . . .244

time closure . . . . . . . . . . . . . . . . . . . . . . . . .244

time determinism . . . . . . . . . . . . . . . . . . .244

time domain . . . . . . . . . . . . . . . . . . . . . . . . 122

time interpolation . . . . . . . . . . . . . . . . . . .244

time-guarded . . . . . . . . . . . . . . . . . . . . . . .247

time-variant state properties . . 43, 62, 92,

141

timed CSP . . . . . . . . . . . . . . . 3, 20, 235–263

timed events . . . . . . . . . . . . . . . . . . . 124, 247

timed failures . . . . . . . . 125, 128, 247, 249

324 Index of Terms

timed failures model . 124, 128, 247,249

finite (FTF) . . . . . . . . . . . . . . . . . . . . . .256

timed failures semantics . . . . . . . . . . . . .126

timed failures/states model . 63, 105, 109,

111, 141

timed observations . . . . . . . . . 40, 103, 108

timed refusals . . . . . . 21, 40, 103, 125, 248

timed specifications . . . . . . . . . . . . . . . . . 258

timed states . . . . . . . . . . . 40, 103, 108, 141

timed traces . . . . . . . . 21, 40, 103, 124, 247

timestop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

TLA+.........................25–26, 54

tool support. . . . . . . . . . . . . . . . . . . . 230, 233

TPL ................................264

traces . . . . . . . . . . . . . . . . . . . . . . . . . . 124, 127

transformation rules . . . . . . . 66, 69, 82, 86

TTM/RTTL . . . . . . . . . . . . . . . . . . . . . . . . .264

urgency . . . . . . . . . . . . . . . . . . . . . . . . 242, 245

value domain . . . . . . . . . . . . . . . 44, 55, 112

verification . . . . . . . . . . . . . . . . . . . . . 21, 260

techniques . . . . . . . . . . . . . . . . . 220, 226

viewpoint-oriented

approaches . . . . . . . . . . . . . . . . . . . . . . 31

combinations . . . . . . . . . . . . . . . . . . . . 31

viewpoints

formal setting . . . . . . . . . . . . . . . . 27–28

inZ.......................... 28–29

well-defined . . . . . . . . . . . . . . . . . . . 106–108

well-formed. . . . . . . . . . . . . . . 108, 117–121

well-formedness condition. . . . . . 117–118

well-timed . . . . . . . . . . . . . . . . . . . . . 247, 256

wide-spectrum language . . . . . . . . . . . . . 24

Z notation . . . . . . . . . . . . . . . 3, 18, 233–235

Z part. . . . . . . . . . . . . . . . . . . . 39, 44, 45, 105

Z Standard . . . . . . . . . . . . . . . . . 73, 109, 233

Zeno................................246

Zermelo–Fraenkel . . . . . . . . . . . . . . 109, 234

Index of Semantic Definitions

Symbols

[[ ]]P

ETFM ............................135

[[ ]]

α...............................141

[[ ]]

Ref ..............................140

[[ ]]

TRef .............................139

[[ ]]

TTr .............................139

[[ ]]

Zval .............................138

[[ ]]P

TFSM ............................142

ASpecUnit...........................146

AssocSubspace .......................115

Binding .............................114

ChannelValue ........................124

chan of .............................124

ChanSgn ............................112

ConcOps ............................119

CSpecUnit ...........................113

Event ...............................124

events of ............................117

ev of ................................125

ev of op ............................127

Exec ................................116

Failure ..............................124

failuresZ.............................128

FinRefusalTokenSet ...................125

HalfOpenInterval .....................125

Histories ............................121

History ..............................117

InitModel ............................114

Inputs ...............................114

Invoc................................116

Invocations ..........................117

InvTermComb ........................120

MaxWellFormed......................119

OP APP ............................114

OpModel ............................115

op name.............................114

op params ...........................114

OpSeqEffects .........................116

OpSetNonInterference.................116

ops of ...............................117

ORC ................................124

Outputs .............................114

PartialOpSeq.........................117

PlainOf .............................114

POP APP ...........................116

pop name ...........................116

pop params ..........................116

PreHist ..............................121

Primed ..............................114

PrimedOf ...........................114

ProcEnv .............................112

Refusal ..............................124

RefusalToken .........................125

325

326 Index of Semantic Definitions

simultan of ..........................117

StateModel ..........................114

states of .............................117

StateVars ............................114

T...................................123

T+..................................123

Term ................................116

tfs of modelEXT ......................145

tfs of modelINT ......................145

TimedEvent ..........................125

TimedFailure .........................125

timed failuresETCSP [[ ]] ..............129

timed failuresETFM [[ ]] ..............133

TimedFailuresModel ..................126

timed failures statesA[[ ]] ..............147

timed failures statesC[[ ]] ..............146

timed failuresZ.......................128

TimedRefusal ........................125

TimedState...........................141

timed statesZ.........................144

timedst of stseq......................144

TimedTrace ..........................125

time of ..............................125

Trace ................................124

tracesZ..............................127

val of ...............................124

WellFormed1.........................118

WellFormed2.........................118

WellFormed3.........................119