University of West Bohemia

Faculty of Applied Sciences

Doctoral Thesis



in partial fulllment of the requirements
for the degree of
Doctor of Philosophy
in specialization
Computer Science and Engineering




Ing. Csar Allain Pacheco

Model-Based Development of Java Distributed
Applications for Embedded Systems







Supervisor: Doc. Ing. Stanislav Racek, CSc.
Date of state doctoral exam: December 12, 2005
Date of thesis consignation: March, 20 of 2010


Pilsen, 2010

















Disertan prce



k zskn akademickho titulu
doktor
v oboru
Informatika a vpoetn technika





Ing. Csar Allain Pacheco

Model-Based Development of Java Distributed
Applications for Embedded Systems

kolitel: Doc. Ing. Stanislav Racek, CSc.
Datum sttn zavren zkouky: 12. prosinca 2005
Datum odevzdn prce: 20. brezna 2010
V Plzni, 2010

Prohlen


Zapadoesk univerzita v Plzni

Fakulta aplikovanch vd

Pedkldm tmto k posouzen a obhajob disertan prci zpracovanou na zvr
doktorskho studia na Fakukt aplikovanch vd Zpadoesk university v Plzni.

Prohlauji tmto, ze tuto prci jsem vypracoval samostatn, pouitm odborn literatury a
dostupnch pramen uvedench v seznamu, jen je souast tto prce.




V Plzni dni 20 brezna 2010. Ing. Csar Allain Pacheco






























Abstract

The purpose of this work is to show a method of verification and testing via simulation of
pieces of software for distributed embedded systems, before they are implemented in a real
hardware system. These pieces of software will work in an embedded integral system. The
process of verification begins with the study of each requirement of the system following
with the creation of the statecharts, creation of timed automaton for each statechart,
verifying the properties of the system. This task can be reached using UPPAAL
verification software and TCTL (Timed Computation Tree Logic) formalism. After
verification of the requirements we can start with the simulation of each requirement in
Java language, using time serialization method that is accomplished by J-Serializer. The
model of the surrounding environment is modelled using J-Sim libraries.

For the reactive real time and system analysis two important formal approaches stand out:
the verification of models and the deductive analysis based on assistants of tests. First it is
characterized for being completely automatizable but it presents/displays difficulties when
dealing with systems with a great number of states or that they have no annotated
parameters. The second allows dealing with arbitrary systems but it requires the interaction
of the user. This work explores a work methodology that allows making compatible the use
of a checker of models like Kronos and the assistant of Coq tests in the system analysis of
real time. For it we formalized graphs (timed automatons) and logic TCTL (and CTL). The
graphs allow describing the systems, whereas the logic is used to specify the temporary
requirements.








Acknowledgments

I would like to thank my supervisor Doc. Ing. Stanislav Racek for his support and
guidance. Also my wife and daughters, Ana and Mirtha, for them patient and love.



















1


Table of Contents
1 Introduction ................................................................................................................ 6
1.1 Models Verification ............................................................................................. 8
1.2 Demonstration of Correctness .............................................................................. 8
1.3 Experimental Verification of the Correctness. ...................................................... 9
1.4 Organization of the Work ................................................................................... 10
2 Related Work ............................................................................................................ 12
2.1 Petri Nets ........................................................................................................... 12
2.1.1 Petri Nets Basis ...................................................................................... 12
2.1.2 Formal Definition and Basic Terminology .............................................. 13
2.1.3 Variations on the definition .................................................................... 14
2.1.4 Formulation in terms of vectors and matrices ......................................... 14
2.1.5 Mathematical proprieties of Petri Nets .................................................... 15
2.1.6 Extensions .............................................................................................. 17
2.1.7 Restrictions ............................................................................................ 19
2.1.8 Application areas .................................................................................... 20
2.1.9 Usability ................................................................................................. 20
2.2 - Calculus ....................................................................................................... 20
2.2.1 Informal Definition ................................................................................ 20
2.2.2 Process Construct ................................................................................... 20
2.2.3 A small Example .................................................................................... 21
2.2.4 Formal Definition ................................................................................... 22
2.2.5 Extensions and Variants ......................................................................... 23
2.2.6 Properties ............................................................................................... 24
2.2.7 Bisimulation in the -calculus ................................................................ 25
2.2.8 Applications ........................................................................................... 26
2.2.9 Implementation ...................................................................................... 27
2.2.10 - Calculus and Java ............................................................................... 27
2.2.11 Usability ................................................................................................. 28
2.3 LTSA Labeled Transition System Analyzer ....................................................... 28
2.3.1 FSP ........................................................................................................ 29
2.3.2 How it works .......................................................................................... 29
2.3.3 Usability ................................................................................................. 30
2.4 SPIN Communicating Automata ..................................................................... 30
2.4.1 What we can do with SPIN? ................................................................... 30
2.4.2 SPINs Essentials ................................................................................... 30
2.4.3 Usability ................................................................................................. 31

2
2.5 Java PathFinder 1 Constructing Formal Models from Java Multithreaded
Programs .................................................................................................................... 31
2.5.1 Usability ................................................................................................. 31
2.6 Bandera Model Checking ............................................................................. 31
2.6.1 Usability ................................................................................................. 32
2.7 The Model Checker Verisoft Checking UNIX Concurrent Systems ................. 32
2.7.1 Description of a Concurrent System ....................................................... 32
2.7.2 State Space Exploration Techniques ....................................................... 33
2.7.3 Usability ................................................................................................. 33
2.8 The ExitBlock Algorithm ................................................................................... 34
2.8.1 How it works .......................................................................................... 34
2.8.2 The Algorithm ........................................................................................ 34
2.8.3 ExitBlock RW ..................................................................................... 36
2.8.4 ExitBlock DD ...................................................................................... 36
2.8.5 Usability ................................................................................................. 37
2.9 Java PathFinder 2 Executable Models of the Java Virtual Machine ................. 37
2.9.1 Abstraction ............................................................................................. 38
2.9.2 Static Analysis........................................................................................ 38
2.9.3 Runtime Analysis ................................................................................... 38
2.9.4 Usability ................................................................................................. 39
2.10 Temporized Graphs and TCTL .......................................................................... 39
2.10.1 Temporized Graphs (Automaton) ........................................................... 39
2.10.2 Formal Semantics ................................................................................... 40
2.10.3 Execution Traces .................................................................................... 41
2.11 Parallel Composition of Temporized Graphs ...................................................... 42
2.11.1 Definition of Composition ...................................................................... 42
2.11.2 Semantics ............................................................................................... 43
2.12 TCTL: Timed Computation Tree Logic.............................................................. 43
2.12.1 TCTL Semantics .................................................................................... 44
2.12.2 Some Abbreviations ............................................................................... 45
2.13 Models Verification: Temporized Graphs and TCTL ......................................... 45
2.14 Time Discretization ............................................................................................ 46
2.14.1 Continuous Time vs. Discrete Time ........................................................ 46
2.14.2 A Discrete Time Model .......................................................................... 47
2.14.3 Algorithmic Interpretation of Temporized Graphs .................................. 48
2.15 Tools ................................................................................................................. 51
2.15.1 J Sim. .................................................................................................. 51
2.15.2 The Simulation Library J-Sim ................................................................ 51
2.15.3 JiJ Java in Java Simulation .................................................................. 56
2.15.4 J SourceMorph .................................................................................... 56
2.16 UPPAAL Timed Systems ................................................................................ 56

3
2.16.1 What we can do with UPPAAL? ............................................................ 56
2.16.2 Uppaals Essentials ................................................................................ 56
2.16.3 Modeling Timed Systems with Uppaal ................................................... 57
2.16.4 Simulating a System ............................................................................... 61
2.16.5 Verification ............................................................................................ 62
2.16.6 Documentation and case Studies ............................................................. 63
3 Goals of the Thesis .................................................................................................... 64
3.1 Motivation ......................................................................................................... 64
4 Distributed State Space Model of Java Distributed Programs ............................... 66
4.1 Introduction ....................................................................................................... 66
4.2 A Distributed Program ....................................................................................... 66
4.3 A Model of Distributed Executions .................................................................... 67
4.4 Models of communication networks ................................................................... 69
4.5 Global state of a distributed system .................................................................... 69
4.5.1 Global state ............................................................................................ 70
4.6 Cuts of a distributed computation ....................................................................... 71
4.7 Past and future cones of an event ....................................................................... 72
4.8 Models of process communications .................................................................... 73
5 Model-Based Development of Distributed Java Embedded Systems ...................... 74
5.1 The Proposed Development Process ................................................................... 74
Part One: Software Requirement Engineering, TCTL and Uppaal. ..................... 74
5.1.1 Requeriments Engineering-Process......................................................... 74
5.1.2 Types of Requirements ........................................................................... 75
5.1.3 Requirement Specification for Real-Time Systems ................................. 76
5.1.4 Formal Methods in Software Specification ............................................. 76
5.1.5 Limitations of Formal Methods .............................................................. 77
5.1.6 Finite State Machines ............................................................................. 78
5.1.7 Statecharts .............................................................................................. 78
5.1.8 Object-Oriented Anaysis and the Unified Modelling Language .............. 81
5.1.9 Use Cases ............................................................................................... 81
5.1.10 Class diagram ......................................................................................... 82
5.1.11 Recommendations on Specification Approach for Real-Time Systems ... 83
5.1.12 Organizing the Requirements Document ................................................ 83
5.1.13 Organizing and Writing Requirements .................................................... 84
5.1.14 Requirements Validation and Review ..................................................... 85
5.1.15 Requirements Validation Using Model Checking ................................... 85
5.1.16 Formal Verification TCTL, Evaluation of Each Node and Code
Generation ......................................................................................................... 86
Part Two: Distributed Simulation Based in the HLA Standard for use with the J-
Sim Simulation Library ...................................................................................... 89

4
5.1.17 Requirements to Solution ....................................................................... 89
5.1.18 Principle solutions .................................................................................. 89
5.1.19 Communication protocol members of the Federation .............................. 90
5.1.20 Implementation of the Solution............................................................... 94
Part Three: Modification of software XRTI ...................................................... 107
6 Case Study ............................................................................................................... 137
Part one the software engineering approach ........................................................... 137
6.1 Introduction ..................................................................................................... 137
6.1.1 Purpuse ................................................................................................ 137
6.1.2 Scope ................................................................................................... 137
6.1.3 Definitions, Acronyms, Abbreviations .................................................. 138
6.2 Overall Description .......................................................................................... 140
6.2.1 Intersection Overview .......................................................................... 140
6.2.2 Product Perspective .............................................................................. 141
6.2.3 Product Functions ................................................................................. 145
6.2.4 User Characteristics .............................................................................. 145
6.2.5 Constraints ........................................................................................... 145
6.2.6 Assumptions and Dependencies............................................................ 146
6.3 Specific Requirements (funcional requirements) ........................................... 146
6.3.1 User Interfaces ..................................................................................... 147
6.3.2 Hardware Interfaces ............................................................................. 147
6.3.3 Software Interfaces ............................................................................... 148
6.3.4 Communications Interfaces .................................................................. 148
6.4 Classes/Objects ................................................................................................ 148
6.4.1 Intersection Controller .......................................................................... 148
6.4.2 Approach.............................................................................................. 152
6.4.3 Pedestrian Traffic Standard .................................................................. 153
6.4.4 Vehicle Traffic Standard ...................................................................... 153
6.4.5 Pedestrian Service Button ..................................................................... 154
6.4.6 Vehicle Presence Detector .................................................................... 155
6.4.7 Manual Override .................................................................................. 155
6.4.8 Remote Override .................................................................................. 156
6.4.9 Emergency Vehicle Interface ................................................................ 157
6.4.10 Network Interface ................................................................................. 157
6.4.11 Traffic History...................................................................................... 158
6.4.12 Incident Log ......................................................................................... 158
6.5 Performance Requirements (non functional requirements) ............................ 159
6.5.1 Timing Requirements ........................................................................... 159
Part two: Using TCTL formalism with UPPAAL tool ............................................... 162
6.5.2 Timed automatons ................................................................................ 163
6.5.3 Property Verification Using UPPAAL .................................................. 177

5
Part 3: Software System Design and Simulation........................................................ 193
6.5.4 The Abstract Control Interface ............................................................. 194
6.5.5 Model of the Control Program .............................................................. 194
6.5.6 Model of the Control Program environment.......................................... 195
6.5.7 Overall System Performance ................................................................ 196
7 Conclusions ............................................................................................................. 198
8 Bibliography ............................................................................................................ 199
9 Authors Publications ............................................................................................. 206


6
1 Introduction

We live in a world today in which software plays a critical part. The most critical software
is not running on large systems and PCs. Rather, it runs inside the infrastructure and in the
devices that we use every day. Our transportation, communications, and energy systems
will not work if the embedded software contained in our cars, phones routers and power
plants crashes.
The design of this invisible, embedded software is crucial to all of us. Yet, there has been a
real shortage of good information as to effective design and implementation practices
specific to this very different world. Make no mistake, it is indeed different and often more
difficult to design embedded software than more traditional programs. Time, and the
interaction of multiple tasks in real-time, must be managed. Seemingly esoteric concepts,
such as priority inversion, can become concrete in a hurry when they bring a device to its
knees. Efficiently a small memory footprint and the ability to run on lower cost hardware
become key design considerations because they directly affect cost, power usage, size,
and battery life. Of course, reliability is paramount when affect so much is at stake
company and product reputations, critical infrastructure functions, and, some times, even
lives.
Programming embedded systems is a special discipline and demands that embedded
systems developers have working knowledge of a multitude of technology areas. These
areas range from low level hardware devices, compiler technology, and debugging
techniques, to the inner workings of the real time operating systems and multithreaded
application design. These requirements can be overwhelming to programmers new to the
embedded world. The learning process can be long and stressful.
Testing is a necessary part of the life cycle of any software product, regardless of its size,
application area, or its user. There are many techniques developed in software engineering,
dealing with the issue of testing. Usually, they have one thing in common: they are
developed exclusively for sequential programs. If a sequential program is executed twice
with the same input data and the program does not involve any randomization inside, the
same output is obtained in both runs. Therefore, if invalid or unpredicted output data is
obtained, it is very easy to reproduce the same program behavior again and it is very likely
that a bug causing the problem will be discovered.
However, it is not true for concurrent and distributed programs anymore. Concurrent and
distributed programs contain more or less independent units of code processes for
multitasking and threads for multithreading executed in parallel. Usually there is an

7
indeterministic scheduler, at the level of operating system or at the program level, which
causes that the concurrency units or rather their parts, consisting of an arbitrary number
of instructions are always executed in a different order. The total number of all possible
schedules of the same concurrent program is therefore almost infinite. Since the
concurrency units usually share some data, which is the reason why they are parts of the
same computation system, any bug concerning the access to these shared data causes that
invalid output of the whole computation is generated or even causes the total computation
process to behave in an unpredictable way or to crash completely. Finding these bugs and
finding the reasons why a concurrent program behaves in a strange and unintended way are
not trivial task.
The usual way of debugging used when something goes wrong in the program is to print
out comments on the standard or error output, log them to files or otherwise send them
somewhere the programmer will eventually read them. This system can inform the
programmer what is happening inside the program, but it cannot say why something (e.g. a
deadlock) has happened. It does not report the true cause of a wrong behavior. An analysis
of the program at the programmers level could substantially help him/her to understand
why the program behaves incorrectly.
Better than debugging a program when a problem is discovered is certainly testing it in a
predefined way while the program is being developed. This approach can save time and
reveal possible bugs with certain probability not by accident.
To fulfill the above mentioned we introduce two approaches to the solution of the testing
problem. First, each node of computer distributed embedded system will be analyzed by a
formal mechanism TCTL (Time Computation Tree Logic) and evaluated by UPPAAL tool
to accomplish some time and concurrent requirements in the node and between the others
nodes of the system.
The output of the first approach becomes an input to the second, which illustrate an
experimental method that uses a serialization of threads that is a method of concurrent
distributed program execution that allows only one thread of a program to run at a given
time. Thread switching at exactly defined places only and it is fully under control of a
serialization execution engine that makes (pseudo)random decisions about thread
switching. A great benefit of the serialization method is a possibility to take a consistent
snapshot of a distributed Java program at defined places.
As you see the intention of this work is to reduce the quantity of bug-error-prone in a
distributed embedded system.
In the last years a concerted effort of investigation has been reversed in the development of
methods and tools for the specification and the analysis of the correction of real-time
systems. Nevertheless there is a clearly preferable formalism, methodology or a tool to
others in all circumstances. For the analysis of the correction of this class of systems two
important formal approaches stand out:

- Verification of correction. In this approach a system is considered when test
correct that all possible execution satisfies the specification. Some well-known
techniques are good, they allow crossing of exhaustive way the space of possible
executions and exist tools for implementing them.


8
- Demonstration of correction. In this case a mathematical test that is constructed
or derived the system satisfies its specification. Here the tools attend the
programmer in the process of construction of the test.

- Experimental Verification of the Correctness. In this case a model is
implemented via program verification in the Java language and some tools
developed at the University of West Bohemia.



1.1 Models Verification
The called method of verification of models (model checking) was developed to verify
reactive systems - those that behave as a sequence of stimulus-answers in relation to means
and later has been extended also to real-time systems, in which the correction depends on
the magnitudes of the temporary retardations. Using this methodology the systems are
modelled as graphs and the specification are expressed, generally, by means of formulas in
a temporary logic (for example, [1], [2], [3]). An efficient procedure is used to determine
automatically if the specifications are satisfied by the graphs. This technique has been used
successfully to detect subtle errors in different systems, in particular in protocols of
communications (for example, [4]). During the past few years the size of the systems that
can be verified this way has increased well-known. This has been consequence of the
development of new techniques within the same strategy, like symbolic model checking
and the verification on the fly. Between the tools that implement some of these
techniques stand out Kronos [5], HyTech [6] and Uppaal [7].

1.2 Demonstration of Correctness
This approach allows constructing a demonstration - in the mathematical sense of the term
with which a system satisfies a specification. In this work we are interested in tools based
on constructive theories of types [8], [9], [10], which have been formulated like
Mathematical foundation of the Constructive one. In the last decade, several equipment of
investigation has dedicated to a considerable effort to the design and implementation of
interactive publishers of test based on theories of types. Examples of these systems are
ALF [11], Coq [12] and I BEQUEATH [13].
One of the main characteristics of the same is the unifying character of the theory that
implement, in which can be expressed programs, theorems and tests of these. Another
remarkable point is that the user is guided in interactive form by system in the process of
construction of a program or one tries, being verified immediately the validity of each
passage of the development. The main objective of these systems is to become
sophisticated tools that attend in the task of the incremental development of correct
programs. Nevertheless, necessary the conceptual frame stops to develop verified software
is of a very high complexity and requires covering many aspects that in fact escape to the
construction of an assistant of tests. These systems have a language of order specification

9
superior, allow to test in logic of high order and they provide definitions with inductive and
coinductive types. The experimentation developed in its use has focused mainly in to
demonstrate the correction of sequential programs, but given its expressive power we
consider that they also can be adapted to reason on reactive systems and, in particular, of
real time. Some carried out experiences in this direction and particularly in Coq are [14],
[15], [16], among others.

1.3 Experimental Verification of the Correctness.
Java and Concurrency. The Java programming language owns all the tools necessary to
work with a multithreaded program but, it cannot protect the programmer from all possible
traps, pitfalls, and dangerous things that multithreading threatens with.
Java threads run in parallel, but actually they run in a pseudo-parallel manner because of a
limited amount of processor resources. The virtual machine is allowed to switch threads at
arbitrary places of their code which causes an inpredectable sequence of program
operations during every run.
To protect shared resources and allow for monitor methods guarding, Java introduces
methods wait(), notify, and notifyAll(), able to manipulate thread execution state. Using
these methods is quite often a source of incorrect program behavior which can lead to
liveness failures or turn objects to wrong states.
What is the organization of this approach?
- First. A general description/analysis of distributed Java program behavior should be
presented. The analysis should identify various entities and describe their behavior
during a program execution, mainly during threading-specific operatios.
- Second. Based on the analysis, a method of reactive Java concurrent program
checking should be developed. The method should target mainly:
o The ability to execute a concurrent Java program in a managed/simulated
way so that all entities identified in point First and operations on them are
properly simulated.
o The ability t analyze the tested program at runtime in such a way that is not
affected by Java multithreading, i.e. the ability to view the program from a
global point of view in a consistent state in the same way a classic
sequential program can be seen.
o The ability to discover a fault behavior, by this we mean either
multithreading related incorrectness in the program or a situation when
the tested program is not able to fulfill its task, e.g. when a controlled
device gets to a wrong state.
o The ability to test a reactive program within a close to real environment
that supplies events and data to it the environment should provide
program data that are expected in the target environment and it should
reflect program output data by changing its state appropriately.
- Three. Tools fulfilling the aforementioned requirements should be developed to
demonstrate that the presented theory and solutions based on it are viable.
- Fourth. The method and the tools should be demonstrated on a representative
example.

10


1.4 Organization of the Work

The organization of the rest of the work is as follows:
Chapter 2 - Related Work present possible approaches to concurrent system checking. It
enumerates and describes some theoretical methods and some tools for system checking,
model checkers.

Chapter 3 Temporized Graphs and TCTL -we introduce the temporized graphs, used to
describe real-time systems, and logic TCTL, used like language of specification of
temporary properties. Also, we analyzed a discretization of the inherent continuous
temporary dominion to the graphs and the logic considered, on the basis of which we
obtain an alternative semantics that we will assume in the rest of this work.

Chapter 4 Distributed State Model of Java Distributed Programs we present a model of
distributed executions, causal precedence relation, models of communication networks,
and global state. We use a cuts of a distributed computation and model of process
communications.

Chapter 5 Design Principles for Distributed Embedded Applications a conceptual
model of distributed embedded system is developed. The focus of the model is on the
simulation of the system.

Chapter 6 Model Based Development of Distributed Java Embedded Systems in this
chapter is presented the theory presented in chapters 3, 4, and 5. Basically describes how
checking of an embedded system program can be incorporated into the development
process and hoe it can be done to get the maximum performance in a low expenses time.

Chapter 7 Tools tools used in the development process as UPPAAL, J- Sim, J-Source
Morph are briefly explained.

Chapter 8 Case Study demonstrates the work presented on a checking and verification
case study. It describes a simple embedded distributed program that controls a system of
water sources.

Chapter 9 Conclusions and Further Work concludes the document, evaluates the result
of the work and present possible extensions of the work.










11





































12
2 Related Work
Many approaches to the solution in this field have been reviewed. In this chapter some of
them, remarkable and used will be more reviewed. Some of them solve problems of
systems using formal methods, others directly analyze a program or implemented in source
code or its feasible one. Only some methods presented/displayed in specialize here in Java,
those that are not it can be reused with Java after additional work. We will begin with the
proposals more theoretical than they are in the highest level of abstraction and soon we
will come with methods that are concentrated in the implementation of a programming
language. Finally, we will present/display algorithms and tools that work directly with
software realized in Java, or with code of Java or in byte code (compiled code).

Principles and Techniques

2.1 Petri Nets
A Petri net (also known as a place/transition net or P/T net) is one of
several mathematical modeling languages for the description of discrete distributed
systems. A Petri net is a directed bipartite graph, in which the nodes represent transitions
(i.e. discrete events that may occur), places (i.e. conditions), and directed arcs (that
describe which places are pre- and/or post conditions for which transitions). Petri nets were
invented in August 1939 by Carl Adam Petri for the purpose of describing chemical
processes.

2.1.1 Petri Nets Basis
A Petri net consists of places, transitions, and directed arcs. Arcs run between places and
transitions, never between places or between transitions. The places from which an arc
runs to a transition are called the input places of the transition; the places to which arcs run
from a transition are called the output places of the transition.
Places may contain any non-negative number of tokens. A distribution of tokens over the
places of a net is called a marking. A transition of a Petri net may fire whenever there is a
token at the end of all input arcs; when it fires, it consumes these tokens, and places tokens
at the end of all output arcs. A firing is atomic, i.e., a single non-interruptible step.

13
Execution of Petri nets is nondeterministic: when multiple transitions are enabled at the
same time, any one of them may fire. If a transition is enabled, it may fire, but it doesn't
have to.
Since firing is nondeterministic, and multiple tokens may be present anywhere in the net
(even in the same place), Petri nets are well suited for modeling the concurrent behavior of
distributed systems.

2.1.2 Formal Definition and Basic Terminology
The following formal definition is loosely based on (Peterson 1981). Many alternative
definitions exist.

2.1.2.1 Syntax
A Petri net graph (called Petri net by some, but see below) is a 3-tuple , where
- S is a finite set of places
- T is a finite set of transitions
- S and T are disjoint, i.e. no object can be both a place and a transition
- is a multiset of arcs, i.e. it defines arcs and assigns to each
arc a non-negative integer arc multiplicity; note that no arc may connect two places
or two transitions.
The flow relation is the set of arcs: . In many textbooks, arcs can
only have multiplicity 1, and they often define Petri nets using F instead of W.
A Petri net graph is a bipartite multidigraph with node partitions S and T.
The preset of a transition t is the set of its input places: ; its postset is
the set of its output places:
A marking of a Petri net (graph) is a multiset of its places, i.e., a mapping . We
say the marking assigns to each place a number of tokens.
A Petri net (called marked Petri net by some, see above) is a 4-tuple , where
- (S,T,W) is a Petri net graph;
- M
0
is the initial marking, a marking of the Petri net graph.

2.1.2.2 Execution Semantics
The behavior of a Petri net is defined as a relation on its markings, as follows.
Note that markings can be added like any multiset:
The execution of a Petri net graph can be defined as the transition relation
on its markings, as follows:
- For any t in T:

-
In words:
- firing a transition t in a marking M consumes W(s,t) tokens from each of its input
places s, and produces W(t,s) tokens in each of its output places s.

14
- A transition is enabled (it may fire) in M if there are enough tokens in its input
places for the consumptions to be possible, i.e. iff .
We are generally interested in what may happen when transitions may continually fire in
arbitrary order.
We say that a marking M' is reachable from a marking M in one step if ; we say
that it is reachable from M if , where is the transitive closure of ; that is, if
it is reachable in 0 or more steps.
For a (marked) Petri net , we are interested in the firings that can be
performed starting with the initial marking M0. Its set of reachable markings is the set

The reachability graph of N is the transition relation restricted to its reachable markings
R(N). It is the state space of the net.
A firing sequence for a Petri net with graph G and initial marking M0 is a sequence of
transitions such that . The set of firing
sequences is denoted as L(N).

2.1.3 Variations on the definition
As already remarked, a common variation is to disallow arc multiplicities and replace the
bag of arcs W with a simple set, called the flow relation, . This limits
expressive power, but not significantly: multi-arcs are rarely used in practice, while in
theoretical considerations, allowing them rarely makes a significant difference.
Another common variation, e.g. in, e.g. Desel and Juhs (2001)[17], is to allow capacities
to be defined on places. This is discussed under extensions below.

2.1.4 Formulation in terms of vectors and matrices
The markings of a Petri net can be regarded as vectors of nonnegative integers
of length | S | .
Its transition relation can be described as a pair of | S | by | T | matrices:
W , defined by
W + , defined by
Then their difference
WT = W + W
can be used to describe the reachable markings in terms of matrix multiplication, as
follows. For any sequence of transitions w, write o(w) for the vector that maps every
transition to its number of occurrences in w. Then, we have
is a firing sequence of .
Note that it must be required that w is a firing sequence; allowing arbitrary sequences of
transitions will generally produce a larger set.



15




2.1.5 Mathematical proprieties of Petri Nets

One thing that makes Petri nets interesting is that they provide a balance between modeling
power and analyzability: many things one would like to know about concurrent systems
can be automatically determined for Petri nets, although some of those things are very
expensive to determine in the general case. Several subclasses of Petri nets have been
studied that can still model interesting classes of concurrent systems, while these problems
become easier.
An overview of such decision problems, with decidability and complexity results for Petri
nets and some subclasses, can be found in Esparza and Nielsen (1995)[18].

2.1.5.1 Reachability
The reachability problem for Petri nets is to decide, given a Petri net N and a marking M,
whether .
Clearly, this is a matter of walking the reachability graph defined above, until either we
reach the requested marking or we know it can no longer be found. This is harder than it
may seem at first: the reachability graph is generally infinite, and it is not easy to
determine when it is safe to stop.
In fact, this problem was shown to be EXPSPACE-hard [19] years before it was shown to
be decidable at all (Mayr, 1981). Papers continue to be published on how to do it
efficiently [20]
While reachability seems to a be a good tool to find erroneous states, for practical
problems the constructed graph usually has far too many states to calculate. To alleviate
this problem, linear temporal logic is usually used in conjunction with the tableau method
to prove that such states cannot be reached. LTL uses the semi-decision technique to find if
indeed a state can be reached, by finding a set of necessary conditions for the state to be
reached then proving that those conditions cannot be satisfied.

2.1.5.2 Livenees
Petri nets can be described as having different levels of liveness L
0
L
0
. A Petri net
(N,M
0
) is called L
k
-live iff all of its transitions are L
k
-live, where a transition is
- L
0
-live (dead), iff it can never fire, i.e. it is not in any firing sequence in L(N,M
0
)
- L
1
-live (potentially fireable), iff it may fire, i.e. it is in some firing sequence in
L(N,M
0
)
- L
2
-live iff it can fire arbitrarily often, i.e. if for every positive integer k, it occurs at
least k times in some firing sequence in L(N,M
0
)
- L
3
-live iff it can fire infinitely often, i.e. if for every positive integer k, it occurs at
least k times in V, for some prefix-closed set of firing sequences

16
- L
4
-live (live) iff it may always fire, i.e., it is L
1
-live in every reachable marking in
R(N,M
0
))
These definitions are in accordance with Murata's[21].
Note that these are increasingly stringent requirements: L
j+1
-liveness implies L
j
-liveness.


Figure 2.1: A Petri net in which for k = 0,1,2,3, transition t
k
is L
k
-live

2.1.5.3 Boundenedness

A Petri net is inherently k-bounded if in no reachable state can at any place contain more
than k tokens. A Petri net is safe if it is 1-bounded. Naturally, the initial M0 marking is
also restricted by the boundedness. Note that a Petri net is inherently bounded if and only if
all its reachability graphs (i.e reachability graphs with all possible starting states) all have a
finite number of states.
Formally, is a set of capacity restrictions, which assigns to each place some
positive number denoting the maximum number of tokens that can occupy that
place. A net in which each of its places has some capacity k, is known as an 'inherently k-
bounded' Petri net.
Boundedness is decidable by looking at covering, by constructing the Karp-Miller Tree. In
computer programming and other applications, the property of boundedness of a Petri net
is used to model limits on available system resources such as CPUs and I/O buses.



Figure 2.2: Example place-transformations.

The grey place that was originally inherently 2-bounded has been transformed into two
places: a grey original, and a counter place


17
Boundedness of a certain place in an inherently bounded net can be mimicked in a non-
inherently bounded net by doing a place-transformation, where a new place (called
counter-place) is created, and all transitions that put x tokens to the original place take x
tokens from the counter-place, and all transitions that take away x tokens from the original
place put x tokens to the counter-place. The number of tokens in M0 must now satisfy the
equation place+counter-place=boundedness. Thus, doing a place-transformation for all
places in a bounded net, and restricting the starting state M0 to conform to the above noted
equality, a bounded net can easily be transformed to a non-bounded net. Therefore any
analysis that is used on inherently non-bounded nets can be used on bounded nets (but not
the other way around).

Figure 2.3: Reachability graph of (a) Petri net Example if the net is 2-bounded. In this case,
it can only have a maximum of 9 (or 32) states.

2.1.6 Extensions
There are many extensions to Petri nets. Some of them are completely backwards-
compatible (e.g. coloured Petri nets) with the original Petri net, some add properties that
cannot be modelled in the original Petri net (e.g. timed Petri nets). If they can be modelled
in the original Petri net, they are not real extensions, instead, they are convenient ways of
showing the same thing, and can be transformed with mathematical formulas back to the
original Petri net, without losing any meaning. Extensions that cannot be transformed are
sometimes very powerful, but usually lack the full range of mathematical tools available to
analyse normal Petri nets.
The term high-level Petri net is used for many Petri net formalisms that extend the basic
P/T net formalism; this includes coloured Petri nets, hierarchical Petri nets, and all other
extensions sketched in this section. The term is also used specifically for the type of
coloured nets supported by CPN Tools.
A short list of possible extensions:
- Additional types of arcs; two common types are:

18
o a reset arc does not impose a precondition on firing, and empties the place
when the transition fires; this makes reachability undecidable[22], while
some other properties, such as termination, remain decidable;[23]
o an inhibitor arc imposes the precondition that the transition may only fire
when the place is empty; this allows arbitrary computations on numbers of
tokens to be expressed, which makes the formalism Turing complete.
- In a standard Petri net, tokens are indistinguishable. In a Coloured Petri Net, every
token has a value.[24] In popular tools for coloured Petri nets such as CPN Tools,
the values of tokens are typed, and can be tested (using guard expressions) and
manipulated with a functional programming language. A subsidiary of coloured
Petri nets are the well-formed Petri nets, where the arc and guard expressions are
restricted to make it easier to analyse the net.

- Another popular extension of Petri nets is hierarchy: Hierarchy in the form of
different views supporting levels of refinement and abstraction were studied by
Fehling. Another form of hierarchy is found in so-called object Petri nets or object
systems where a Petri net can contain Petri nets as its tokens inducing a hierarchy
of nested Petri nets that communicate by synchronization of transitions on different
levels. See [19] for an informal introduction to object Petri nets.

- A Vector Addition System with States (VASS) can be seen as a generalisation of
a Petri net. Consider a finite state automaton where each transition is labelled by a
transition from the Petri net. The Petri net is then synchronised with the finite state
automaton, i.e., a transition in the automaton is taken at the same time as the
corresponding transition in the Petri net. It is only possible to take a transition in the
automaton if the corresponding transition in the Petri net is enabled, and it is only
possible to fire a transition in the Petri net if there is a transition from the current
state in the automaton labelled by it. (The definition of VASS is usually formulated
slightly differently.)

- Prioritised Petri nets add priorities to transitions, whereby a transition cannot fire,
if a higher-priority transition is enabled (i.e. can fire). Thus, transitions are in
priority groups, and e.g. priority group 3 can only fire if all transitions are disabled
in groups 1 and 2. Within a priority group, firing is still non-deterministic.

- The non-deterministic property has been a very valuable one, as it lets the user
abstract a large number of properties (depending on what the net is used for). In
certain cases, however, the need arises to also model the timing, not only the
structure of a model. For these cases, timed Petri nets have evolved, where there are
transitions that are timed, and possibly transitions which are not timed (if there are,
transitions that are not timed have a higher priority than timed ones). A subsidiary
of timed Petri nets are the stochastic Petri nets that add nondeterministic time
through adjustable randomness of the transitions. The exponential random
distribution is usually used to 'time' these nets. In this case, the nets' reachability
graph can be used as a Markov chain.


19
- Dualistic Petri Nets (dP-Nets) is a Petri Net extension developed by E. Dawis, et
al.[25] to better represent real-world process. dP-Nets balance the duality of
change/no-change, action/passivity, (transformation) time/space, etc., between the
bipartite Petri Net constructs of transformation and place resulting in the unique
characteristic of transformation marking, i.e., when the transformation is "working"
it is marked. This allows for the transformation to fire (or be marked) multiple
times representing the real-world behavior of process throughput. Marking of the
transformation assumes that transformation time must be greater than zero. A zero
transformation time used in many typical Petri Nets may be mathematically
appealing but impractical in representing real-world processes. dP-Nets also exploit
the power of Petri Nets' hierarchical abstraction to depict Process architecture.
Complex process systems are modeled as a series of simpler nets interconnected
through various levels of hierarchical abstraction. The process architecture of a
packet switch is demonstrated in [26], where development requirements are
organized around the structure of the designed system. dP-Nets allow any real-
world process, such as computer systems, business processes, traffic flow, etc., to
be modeled, studied, and improved.

There are many more extensions to Petri nets, however, it is important to keep in mind,
that as the complexity of the net increases in terms of extended properties, the harder it is
to use standard tools to evaluate certain properties of the net. For this reason, it is a good
idea to use the most simple net type possible for a given modeling task.


2.1.7 Restrictions
Instead of extending the Petri net formalism, we can also look at restricting it, and look at
particular types of Petri nets, obtained by restricting the syntax in a particular way. The
following types are commonly used and studied:
In a state machine (SM), every transition has one incoming arc, and one outgoing arc. This
means, that there cannot be concurrency, but there can be conflict (i.e. Where should the
token from the place go? To one transition or the other?). Mathematically:

In a marked graph (MG), every place has one incoming arc, and one outgoing arc. This
means, that there cannot be conflict, but there can be concurrency. Mathematically:

In a free choice net (FC), - every arc is either the only arc going from the place, or it is the
only arc going to a transition. I.e. there can be both concurrency and conflict, but not at the
same time. Mathematically:
Extended free choice (EFC) - a Petri net that can be transformed into an FC.
In an asymmetric choice net (AC), concurrency and conflict (in sum, confusion) may
occur, but not asymmetrically. Mathematically:


20
In a multiple asymmetric choice net (MAC), multiple concurrencies and conflict (in sum,
multiple confusion) may occur, but no confusion. Mathematically: for a set |P|=k,
exist a subset and contains all subset and is the Power Set 2k without the empty subset
In an arbitrary Petri net (PN), confusion is allowed (i.e. everything is allowed)

2.1.8 Application areas
Software design, workflow management, data analysis, concurrent programming,
reliability engineering, diagnosis, discrete process control.

2.1.9 Usability
Using Petri nets requires that a model of the simulated / analyzed system has to be
constructed first. This requires a detailed analysis of the source code of the tested software
if not done during the design phase. Constructing the model is further complicated by the
fact that a Java concurrent program can hardly be considered a discrete system so a process
of abstraction must be applied. Petri nets are certainly a helpful verification mean in an
early design phase but almost unusable if analysis of an already existing software is
required.

2.2 - Calculus
In theoretical computer science, the the -calculus is a process calculus originally
developed by Robin Milner, Joachim Parrow and David Walker as a continuation of work
on the process calculus CCS (Calculus of Communicating Systems). The aim of the -
calculus is to be able to describe concurrent computations whose configuration may change
during the computation. The goal is the formal description of a system consisting of
parallel processes and channels between them.


2.2.1 Informal Definition

The -calculus belongs to the family of process calculi, mathematical formalisms for
describing and analyzing properties of concurrent computation. In fact, the -calculus, like
the -calculus, is so minimal that it does not contain primitives such as numbers, booleans,
data structures, variables, functions, or even the usual flow control statements (such as if...
then...else, while...).

2.2.2 Process Construct


21
Central to the -calculus is the notion of name. The simplicity of the calculus lies in the
dual role that names play as communication channels and variables.
The process constructs available in the calculus are the following (a precise definition is
given in the following section):
- Concurrency, written , where P and Q are two processes or threads executed
concurrently.
- Communication, where input prefixing is a process waiting for a message
that was sent on a communication channel named c before proceeding as P, binding
the name received to the name x. Typically, this models either a process expecting
a communication from the network or a label c usable only once by a goto
c operation.
Output prefixing describes that the name y is emitted on channel c before proceeding
asP. Typically, this models either sending a message on the network or a goto
c operation.
replication, written , which may be seen as a process which can always create a new
copy of P. Typically, this models either a network service or a label c waiting for any
number of goto cooperation.
Creation of a new name, written , which may be seen as a process allocating a new
constant x within P. As opposed to functional programming's let x=... in... operation, the
constants of -calculus are defined by their name only and are always communication
channels.
The nil process, written 0, is a process whose execution is complete and has stopped.
Although the minimalism of the -calculus prevents us from writing programs in the
normal sense, it is easy to extend the calculus. In particular, it is easy to define both control
structures such as recursion, loops and sequential composition and data types such as first-
order functions, truth values, lists and integers. Moreover, extensions of the -
calculus have been proposed which take into account distribution or public-key
cryptography. The applied -calculus due to Abadi and Fournet [27] puts these various
extensions on a formal footing by extending the -calculus with arbitrary datatypes.

2.2.3 A small Example

Below is a tiny example of a process which consists of three parallel components. The
channel name x is only known by the first two components.

The first two components are able to communicate on the channel x, and the
name z becomes bound toy. The continuation of the process is therefore

Note that the remaining y is not affected because it is defined in an inner scope. The
second and third parallel components can now communicate on the channel name z,
and x is bound to v. The continuation of the process is now

Note that since the local name x has been output, the scope of x is extended to cover the
third component as well. Finally, the channel x can be used for sending the name x.

22

2.2.4 Formal Definition

Syntax
Let be a set of objects called names. The processes of -calculus are built from names by
the syntax (where x and y are any names from )

Names can be bound by the restriction and input prefix constructs. The sets of free and
bound names of a process in calculus are defined inductively as follows.
The 0 process has no free names and no bound names.
The free names of are a, x, and the free names of P. The bound names of are
the bound names of P.
The free names of a(x).P area and the free names of P, except for x. The bound names
of a(x).P are x and the bound names of P.
The free names of P | Q are those of P together with those of Q. The bound names
of P | Q are those of P together with those of Q.
The free names of (x).P are those of P, except for x. The bound names of (x).P are x and
the bound names of P.
The free names of !P are those of P. The bound names of !P are those of P.
Structural congruence
Central to both the reduction semantics and the labelled transition semantics is the notion
of structural congruence. Two processes are structurally congruent, if they are identical up
to structure. In particular, parallel composition is commutative and associative.
More precisely, structural congruence is defined as the least equivalence relation preserved
by the process constructs and satisfying:
Alpha-conversion:
if Q can be obtained from P by renaming one or more bound names in P.
Axioms for parallel composition:



Axioms for restriction:


Axiom for replication:

Axiom relating restriction and parallel:
if x is not a free name of Q.
This last axiom is known as the "scope extension" axiom. This axiom is central, since it
describes how a bound name x may be extruded by an output action, causing the scope
of x to be extended.

23
Reduction semantics
We write if P can perform a computation step, following which it is now P'.
This reduction relation is defined as the least relation closed under a set of reduction
rules.
The main reduction rule which captures the ability of processes to communicate through
channels is the following:

where Q[z / y] denotes the process Q in which the free name z has been substituted for the
free name y. Note that this substitution may involve alpha-conversion to avoid name
clashes.
There are three additional rules:
If then also .
This rule says that parallel composition does not inhibit computation.
If , then also .
This rule ensures that computation can proceed underneath a restriction.
If and where , then also .
The latter rule states that processes that are structurally congruent have the same
reductions.
The example revisited
Consider again the process

Applying the definition of the reduction semantics, we get the reduction

Next, we get the reduction

Note that since the local name x has been output, the scope of x is extended to cover the
third component as well. This was captured using the scope extension axiom.
Labelled semantics
Alternatively, one may give the pi-calculus a labelled transition semantics (as has been
done with the Calculus of Communicating Systems). Transitions in this semantics are of
the form:

This notation signifies that P after the action becomes P'. can be an input action a(x),
an output action , or a tau-action corresponding to an internal communication.
A standard result about the labelled semantics is that it agrees with the reduction semantics
in the sense that if and only if for some action .

2.2.5 Extensions and Variants
The syntax given above is a minimal one. However, the syntax may be modified in various
ways.
A nondeterministic choice operator P + Q can be added to the syntax.
A test for name equality [x = y]P can be added to the syntax. This match operator can
proceed as P if and only if x and y are the same name. Similarly, one may add a mismatch
operator for name inequality. Practical programs which can pass names (URLs or pointers)

24
often use such functionality: for directly modelling such functionality inside the calculus,
this and related extensions are often useful.
The asynchronous -calculus allows only outputs with no continuation, i.e. output atoms of
the form , yielding a smaller calculus. However, any process in the original calculus
can be represented by the smaller asynchronous -calculus using an extra channel to
simulate explicit acknowledgement from the receiving process. Since a continuation-free
output can model a message-in-transit, this fragment shows that the original -calculus,
which is intuitively based on synchronous communication, has an expressive asynchronous
communication model inside its syntax.
The polyadic -calculus allows communicating more than one name in a single
action: (polyadic output) and x(z1,...zn) (polyadic input). This polyadic
extension, which is useful especially when studying types for name passing processes, can
be encoded in the monadic calculus by passing the name of a private channel through
which the multiple arguments are then passed in sequence. The encoding is defined
recursively by the clauses
is encoded as
is encoded as
All other process constructs are left unchanged by the encoding.
In the above, [P] denotes the encoding of all prefixes in the continuation P in the same
way.
The full power of replication !P is not needed. Often, one only considers replicated
input !x(y).P, whose structural congruence axiom is .
Replicated input process such as !x(y).P can be understood as servers, waiting on
channel x to be invoked by clients. Invocation of a server spawns a new copy of the
process P[a / y], where a is the name passed by the client to the server, during the latter's
invocation.
A higher order -calculus can be defined where not only names but processes are sent
through channels. The key reduction rule for the higher order case is

Here, Y denotes a process variable which can be instantiated by a process term. Sangiorgi
established the surprising result that the ability to pass processes does not increase the
expressivity of the -calculus: passing a process P can be simulated by just passing a name
that point to P instead.

2.2.6 Properties

Turing completeness
The -calculus is a universal model of computation. This was first observed by Milner in
his paper "Functions as Processes" (Mathematical Structures in Computer Science, Vol. 2,
pp. 119-141, 1992), in which he presents two encodings of the lambda-calculus in the -
calculus. One encoding simulates the call-by-value reduction strategy, the other encoding
simulates the lazy (call-by-name) strategy.
The features of the -calculus that make these encodings possible are name-passing and
replication (or, equivalently, recursively defined agents). In the absence of

25
replication/recursion, the -calculus ceases to be Turing-powerful. This can be seen by the
fact the bisimulation equivalence becomes decidable for the recursion-free calculus and
even for the finite-control -calculus where the number of parallel components in any
process is bounded by a constant (Mads Dam: On the Decidability of Process Equivalences
for the pi-Calculus. Theoretical Computer Science 183, 1997, pp. 215-228.)

2.2.7 Bisimulation in the -calculus

As for process calculi, the -calculus allows for a definition of bisimulation equivalence. In
the -calculus, the definition of bisimulation equivalence (also known as bisimilarity) may
be based on either the reduction semantics or on the labelled transition semantics.
There are (at least) three different ways of defining labelled bisimulation equivalence in
the -calculus: Early, late and open bisimilarity. This stems from the fact that the -
calculus is a value-passing process calculus.
In the remainder of this section, we let p and q denote processes and R denote binary
relations over processes.

Early and late bisimilarity

Early and late bisimilarity were both discovered by Milner, Parrow and Walker in their
original paper on the -calculus.[28]
A binary relation R over processes is an early bisimulation if for every pair of
processes ,
whenever then for every name y there exists some q' such that
and ;
for any non-input action , if then there exists some q' such that and ;
and symmetric requirements with p and q interchanged.
Processes p and q are said to be early bisimilar, written if the pair for some
early bisimulation R.
In late bisimilarity, the transition match must be independent of the name being
transmitted. A binary relation R over processes is a late bisimulation if for every pair of
processes ,
whenever then for some q' it holds that and for every name
y;
for any non-input action , if implies that there exists some q' such that
and ;
and symmetric requirements with p and q interchanged.
Processes p and q are said to be late bisimilar, written if the pair for some
late bisimulation R.
Both and suffer from the problem that they are not congruence relations in the sense
that they are not preserved by all process constructs. More precisely, there exist
processes p and q such that but . One may remedy this problem by
considering the maximal congruence relations included in and , known as early
congruence and late congruence, respectively.

26

Open bisimilarity

Fortunately, a third definition is possible, which avoids this problem, namely that of open
bisimilarity, due to Sangiorgi [27].
A binary relation R over processes is an open bisimulation if for every pair of
elements and for every name substitution and every action , whenever
then there exists some q' such that and .
Processes p and q are said to be open bisimilar, written if the pair for some
open bisimulation R.
Early, late and open bisimilarity are in fact all distinct. The containments are proper,
so .
In certain subcalculi such as the asynchronous pi-calculus, late, early and open bisimilarity
are known to coincide. However, in this setting a more appropriate notion is that
of asynchronous bisimilarity.
The reader should note that, in the literature, the term open bisimulation usually refers to a
more sophisticated notion, where processes and relations are indexed by distinction
relations; details are in Sangiorgi's paper cited above.

Barbed equivalence

Alternatively, one may define bisimulation equivalence directly from the reduction
semantics. We write if process p immediately allows an input or an output on name a.
A binary relation R over processes is a barbed bisimulation if it is a symmetric relation
which satisfies that for every pair of elements we have that
(1) if and only if for every name a
and
(2) for every reduction there exists a reduction
such that .
We say that p and q are barbed bisimilar if there exists a barbed
bisimulation R where .
Definying a context as a term with a hole [] we say that two processes P and Q
are barbed congruent, written if for every context C[] we have that . It
turns out that barbed congruence coincides with the congruence induced by early
bisimilarity.

2.2.8 Applications

The -calculus has been used to describe many different kinds of concurrent systems. In
fact, some of the most recent applications lie outside the realm of computer science.
In 1997, Martin Abadi and Andrew Gordon proposed an extension of the -calculus,
the Spi-calculus, as a formal notation for describing and reasoning about cryptographic
protocols. The spi-calculus extends the -calculus with primitives for encryption and
decryption. There is now a large body of work devoted to variants of the spi-calculus,
including a number of experimental verification tools. One example is the tool

27
ProVerif[29] due to Bruno Blanchet, based on a translation of the applied -calculus into
Blanchet's logic programming framework. Another example is Cryptyc [30], due to
Andrew Gordon and Alan Jeffrey, which uses Woo and Lam's method of correspondence
assertions as the basis for type systems that can check for authentication properties of
cryptographic protocols.
Around 2002, Howard Smith and Peter Fingar became interested in using the -calculus as
a description tool for modeling business processes. As of July 2006, there is discussion in
the community as to how useful this will be. Most recently, the -calculus has been used as
the theoretical basis of Business Process Modeling Language (BPML), and of Microsoft's
XLANG.[29]
The -calculus has also attracted interest in molecular biology. In 1999, Aviv
Regev and Ehud Shapiro showed that one can describe a cellular signaling pathway (the
so-called RTK/MAPK cascade) and in particular the molecular "lego" which implements
these tasks of communication in an extension of the -calculus.[30]

2.2.9 Implementation
The following programming languages are implementations either of the -calculus or of
its variants:
- Acute
- Business Process Modeling Language (BPML)
- Nomadic Pict
- Occam-
- Pict
- JoCaml (based on the Join-calculus a variant of -calculus)
- Funnel (A JRE-compatible join calculus implementation)
- The CubeVM (a stackless implementation)
- The SpiCO language: a stochastic pi-calulus for concurrent objects


2.2.10 - Calculus and Java
Igarashi and Kobayashi [31] used the _-calculus to create a general framework of type
systems, called a generic type system. This system can be instantiated to a variety of type
systems by changing its parameters: a subtyping relation and a consistency condition.
Whatever the parameters are, the derived systems retain important properties of the generic
type system. Therefore, the properties have to be proven just once in the generic type
system and are valid for any instance. The importance of the work of Igarashi and
Kobayashi lies in showing that a number of non-trivial type systems, such as those
ensuring deadlock freedom and race freedom, can be derived from the generic system and
proven correct. This is of a great importance for verifying concurrent Java programs,
however, they do not give any clue how it should be applied on concurrent Java programs.
Neither Java nor any other programming language is mentioned in their work to be
convertible to an instance of the generic type system. Neither is stated how source code (of

28
any language) or bytecode (of Java) should be converted by hand to formulas that would
be verified against a specific instance of the type system. Therefore, the _-calculus generic
type system seems to be a purely theoretical tool with no practical influence on Java
programs testing and verification and thus completely unusable for our purposes.
Jacobs and Piessens [32] created a formal semantics of Java as a mapping of Java
programs to -calculus processes. The semantics covers a substantial part of the Java
language, although not the entire language. Some of the supported features are
polymorphism, typecasts, exceptions, implementation of the Java Memory Model with per-
thread memory caching, etc. There is, however, a number of features not yet included in
the semantics, including arrays, static fields, string literals, and especially the thread state
manipulation methods of the Object class wait(), notify(), and notifyAll(), which is a great
disadvantage when dealing with concurrent programs. Also, access modifiers cannot be
expressed. Unfortunately, the authors omit any details on using the formal semantics in
real life. There is no obvious link between a real Java source/byte code, i.e. the authors do
not mention any tool or method to create a set of -calculus expressions that could be a
subject of further investigation. In addition, the authors do not say how to make use of the
resulting _-calculus expressions. So there is a missing link between the resulting
description of a program and a statement that would prove or disprove a proposed property
of the program.

2.2.11 Usability

At this moment, there is no evidence that the _-calculus is able to solve real problems in
the area of Java concurrent programs development. All research done so far in this field is
rather theoretical and does not target problems with real Java software. It is thought
possible that it can be successful in the area it was originally intended for communication
systems design.


2.3 LTSA Labeled Transition System Analyzer
LTSA is a verification tool for concurrent systems. It mechanically checks that the
specification of a concurrent system satisfies the properties required of its behavior. In
addition, LTSA supports specification animation to facilitate interactive exploration of
system behavior.
A system in LTSA is modeled as a set of interacting finite state machines. The properties
required of the system are also modeled as state machines. LTSA performs compositional
reachability analysis to exhaustively search for violations of the desired properties. More
formally, each component of a specification is described as a Labeled Transition System
(LTS), which contains all the states a component may reach and all the transitions it may
perform. However, explicit description of an LTS in terms of its states set of action labels
and transition relation is cumbersome for other than small systems. Consequently, LTSA

29
supports a process algebra notation (FSP) for concise description of component behavior.
The tool allows the LTS corresponding to a FSP specification to be viewed graphically.
LTSA has an extensible architecture which allows extra features to be added by means of
plug-ins. LTSA and its plug-ins can be downloaded from [33]


2.3.1 FSP
The Finite State Process (FSP) notation (Magee, Kramer et al. 1997; Magee and Kramer
1999) is designed to be easily machine readable, and thus provides a preferred language to
specify abstract workflows. FSP is a textual notation (technically a process calculus) for
concisely describing and reasoning about concurrent programs. The constructed FSP can
be used to model the exact transition of workflow processes through a modeling tool such
as the Labeled Transition System Analyzer (LTSA) (Magee and Kramer 1999), which
provides compilation of an FSP into a state machine and provides a resulting LTS. LTSA
is a tool which provides a means to construct and analyze complex models of finite state
process specifications. This tool, which is fully explained in (Magee and Kramer 1999),
provides us with an opportunity to model workflows prior to implementation and
deployment testing, and with an MSC editor and synthesis extensions (S.Uchitel and
Kramer 2001) to easily model a scenario-based design specification, which can increase
the expectation that process composition will provide the necessary path of invocation in
all states specified (e.g. reliably by eliminating deadlock situations). With process
animator extensions, the tool can also provide a facilitator in simulating workflow
specifications. An example FSP for a parallel composition of concurrent invoke and
receive transitions in a process is given in Figure 29. The composed Labelled Transition
system for this system is also illustrated.

INVOKE =
(invoke_activity-
>END).
RECEIVE=
(receive_activity-
>END).
||PSEQ = (INVOKE ||
RECEIVE).

Figure 2.4: FSP and LTS of a sequential process composition


2.3.2 How it works

After the processes are described, LTSA can perform a breadth-first search on the LTS. If
a property violation or a deadlock is found, the shortest trace of actions that would lead to
the property violation or deadlock is displayed. Alternatively, this algorithm can be
replaced by Holtzmanns bitstate hashing technique Supertrace which is not a complete

30
search of the state space. Super trace is only used if the complete search is not possible due
to size.

2.3.3 Usability
LTS, FSP, and the LTS Analyzer (now in version 3.0) is a set of extremely helpful tools
that can diagnose the concurrent system before it is implemented. Therefore, the actual
software has to be written according to the model. However, as in the case of any other
theoretical method, errors can be introduced to the code during further development, so
another tool has to be used later.

2.4 SPIN Communicating Automata

SPIN is a tool mainly developed by G.J. Holzmann at Bell Laboratories, Murray Hill, New
Jersey, USA. SPIN was designed for simulation and verification of distributed algorithms.
It is freely available in Internet.

2.4.1 What we can do with SPIN?
The systems under study first have to be described in Promela, SPINs specification
language. Promela is an imperative language which looks like C augmented with a few
communication primitives. Hence, Promela allows to describe the behavior of each process
in the system, as well as the interactions between them. For communication, the processes
may use FIFO communication channels, rendez-vous or shared variables.
SPIN essentially operates with two modes. The first one allows the user to get familiar
with the behaviour of his system by simulating its execution. The second one checks, by
means of an exhaustive search of the set of reachable states, that the system satisfies some
properties stated in e.g. PLTL, lineat time temporal logic.

2.4.2 SPINs Essentials
The theoretical basis for SPIN originates from the model of automata communicating via
bounded channels. SPIN does not permit to study infinite state systems (timed systems,
Petri nets, etc.)[34].
Its key feature is the availability of several state space reduction methods: state
compression, on-the-fly verification and hashing techniques (via bit-state, see below).
Although finite, the number of reachable states of the systems model can easily reach tenth
of millions.


31
2.4.3 Usability
SPIN is very simple to use and matches extremely well the needs for an introduction to
problems inherent to verification of distributed systems.
As for its performances, it provides a lot of new techniques to cope with state space
explosion (intrinsic to verification of parallel systems).


2.5 Java PathFinder 1 Constructing Formal Models from
Java Multithreaded Programs
The SPIN tool verifies concurrent systems but only works with formal models. Java
PathFinder 1 creates these models from existing source code, allowing SPIN to be used for
verification of Java concurrent programs.
The Java program, that is testes, may contain assertions which are translated to the
corresponding assertions in the Promela language. The SPIN model checker checks for any
violation of the specified assertions, and for deadlocks, too. The assertions can also be
expressed directly in the linear temporal logic (LTL), as in the case of SPIN. In the former
case, the tester can use the Verify class and its static method assert(). The body of the
method is not translated to Promela (only its parameter the tested condition) but can be
used during normal testing.
The translation from java source code to Promela can be found in [35] due to its
complexity it will not be presented in this work.
Java PathFinder supports a subset of the Java language; however, this subset seems to be a
reasonable part of the whole language and the other, unsupported, part will unlikely be
missed.
2.5.1 Usability

Java PathFinder has been used in NASA for testing real programs in the project
development of new operating system for the Deep Space 1 spacecraft. Many errors were
found mainly for the time dependent behaviour conducting to deadlock.

2.6 Bandera Model Checking

Bandera is a set of tools for model checking Java concurrent programs. It is able to extract
a finite-state model from a program source code, let the user define desired properties that
should be fulfilled, run a verifier, and finally map the verifiers output back to the source
code if a violation of a defined property is detected.
Bandera has been developed at the University of Hawaii and in the Laboratory of Kansas
State University by researches and students since 1998. More information can be handled
in [36] and [37].

32

2.6.1 Usability

The Bandera tool set has been used for development of software for avionics software at
NASA and Honeywell Technology Center in cooperation with Java Path Finder 2 to check
properties of that software.
Using Bandera, however, requires previous knowledge of temporal logic, explicit state
model-checking and abstract implementation.

2.7 The Model Checker Verisoft Checking UNIX Concurrent
Systems
The Verisoft tool is a verification tool for systematic exploration of the state systems
composed of several concurrent processes executing arbitrary C code. Therefore, there are
many differences between the model checker SPIN and Verisoft: SPIN needs a formal
model of the examined system written in a special language called Promela, while Verisoft
operates with real source code of the verified system. A brief description of the model
checker Verisoft and the algoritms it uses can be found in [38].
Every process of the concurrent system to be analyzed is mapped to a UNIX process. The
execution of the system processes is controlled by an external process, called the
scheduler. By suspending and resuming a given process, the scheduler is able to step
through the state space of the examined system. When a deadlock or an assertion violation
is detected, the program is stopped and the computation history is shown to the user.
Verisoft also checks for divergences and livelocks. A divergence occurs when a process
does not attempt to execute any visible operation for more than a given amount of time. A
livelock occurs when a process has no enabled transition during a sequence os more than a
given number of successive global states.

2.7.1 Description of a Concurrent System
The verified concurrent system is composed of a finite set P of processes and a finite set O
of communication objects. Each process P P executes a sequence of operations a
sequential deterministic program. Processes communicate with each other by performing
operations on communication objects. A communication object O O is defined by pair
(V, OP), where V is the domain of the object and OP is its set of operations.
Operations on communication objects are called visible while other operations are by
default invisible. The execution of a visible operation is blocking if it cannot be completed.
Invisible operations cannot block.
At any time, the system is said to be in a state. It is in a global state when the next
operation to be executed by every process in the system is a visible operation. The initial
state

33
Of the system is also considered to be a global. A process transition is a visible operation
followed by a finite sequence of invisible operations performed by a single process. A
transition may be disabled when the execution of its visible operation is blocking,
otherwise it is enabled. By completing a transition of a process from a global state s, the
system reaches a successor of s.
So the global state of a concurrent system is seen by VeriSoft as a set of global states plus
a set of s transitions between pairs of these global states plus an initial global state.

2.7.2 State Space Exploration Techniques
The state-space algorithm of exploration is based on recursion. It starts with the initial state
and executes all enabled transitions leading from it. The same algorithm repeats in each
found from the initial state.
The algorithm assumes that each state has a unique identifier and a unique and manageable
representation that can be stored to its data structures. However, this assumption is not
valid anymore when dealing with real programs because the values of all memory
locations a process can read from or write to are different if the same state is reached for
the second time.
The basic algorithm uses the following data structures:
- A set of states whose successors are still unexplored.
- A hashtable of already visited states.
- Sets of enabled transitions, one set per state.
Because of the broken assumption stated above, so called stateless search algorithm can
replace the original one. The main difference is that the latter one does not store any
intermediate results to the memory. An unpleasant result is that the algorithm may not
terminate if the program contains cycles, even if the set of global states is finite.
VeriSoft uses an enhanced version of the stateless search algorithm, employing so called
sleep sets and persistent sets. They serve the following purposes:
- Sleep Set. A sleep set is associated with every global state. It contains those
transitions that are enabled but will not be explored from a given state. Initially, this
set (the sleep set of the initial state) is empty. If a transition is executed, it is added
to the sleep set of the state from which it was executed so that it cannot be executed
anymore if the computation reaches the same state again. The target global state of
a transition t inherits the sleep set of the last explored state but only those
transitions that are independent with t are kept in the set.
- Persistent Set. A persistent set is also associated with every global state. It is such a
subset T of the set of all enabled transitions in a given state s that all transitions not
in T (and enabled in s or in a state reachable from s through transitions not in T) are
independent with all transitions in T.

2.7.3 Usability


34
The tool is restricted to operate in Unix environment only it works with processes of the
operating system) and therefore not usable for purposes of Java programs analysis and
debugging.

2.8 The ExitBlock Algorithm
The ExitBlock algorithm finds errors in concurrent Java programs resulting from
unintended timing dependences. [39], [40].
This algorithm enumerates all possible behaviors of a Java multithreaded program for a
given input. It does not need a separate model or specification of the tested program or its
source code; it does the testing dynamically using information gathered while running the
program.
ExitBlock is also able to detect common timing dependences errors, for example errors
that occur only in certain orderings of modules that are individually correctly
synchronized, or using a simple if statement instead of while cycle to test a condition
variable. It also has an extended version that is able to detect deadlocks in the program.
The implemented algorithm needs a special virtual machine in order to be executed,
conventional JVMs cannot be used. Such a JVM the Rivet JVM was developed
concurrently with the tool at MIT.

2.8.1 How it works
The ExitBlock algorithm requires that the tested program comply with the three following
testing criteria:
- Mutual Exclusion Locking Discipline. The discipline dictates that each shared
variable is associated with at least one mutual-exclusion lock and that the lock(s)
are always held whenever any thread accesses that variable. Since ExitBlock is not
able to detect violations of this discipline itself, it uses the Eraser algorithm [41],
running in parallel, to detect them.
- Finalization. In Java, the finalize() methods can be run in any order and at any time,
depending on the JVM schedules them to run. The algorithm assumes that
finalizers do not influence the rest of the program in the sence that neither
assertions nor deadlocks can result from different schedules of finalizers.
- Terminating Threads. ExitBlock requires the tested program (and therefore every
thread of the program) to have a defined endpoint. ExitBlock uses the depth-first
search algorithm to enumerate all possible schedules of the program. With a non
terminating thread, the algorithm would not therefore inspect the rest of schedules
but would stay locked in a cycle forever.

2.8.2 The Algorithm
The ExitBlock algorithm is based on the following idea: Lets divide the program into
atomics blocks (based on synchronized blocks). Shared variables cannot be accesses

35
outside these atomics blocks because the locking discipline would be violated. Shared
variables modified by a thread inside of an atomic block. This means that enumerating
possible orders of atomics blocks of a program covers all possible behaviours of the
program. So the algorithm only needs to consider at the level of atomics blocks, not at the
level of Java bytecode instructions.
All possible atomic blocks cannot be enumerated statically since their number is data
dependent. So it is necessary to run the program and enumerate all possible schedules
using the depth-first algorithm.
The algorithm first executes one complete schedule of the program. Then, it goes back up
from the end of the program to the end of the last atomic block. Here, by choosing a
different thread to run, the algorithm creates a new branch of the schedule tree. The
program is again executed until completion. This process is systematically repeated. If
there is no such thread in a certain node of the tree that has not run yet from here, the
algorithm goes back up one atomic block (one level in the tree) and starts to make new
branches from here. The algorithm terminates if there is no such thread in the initial state
which means that all schedules have already been inspected.
The algorithm needs to have guaranteed that it can back up the program to a previous state
(before the current branch was executed), which is done using checkpointing, and it must
also be provided with the ability of deterministic replay to ensure the program receives the
same inputs as it is re-executed. Both the checkpointing and the deterministic replay are
provided by the Rivet virtual machine.
An atomic block ends with a lock exit or the end of a thread and it begins at the point
where the last atomic block ends or at the beginning of a thread. So non-synchronized code
is grouped together with its following synchronized code to from one atomic block. This
produces a few atomic blocks as possible and therefore the number of possible schedules is
also reduced. Nothing changes if there are nested synchronized blocks. The borders of
atomic blocks are still lock exists and thread and deaths, nothing more.
Every thread of the program is put in one of the three following sets:

Block Set. A thread is in a block set of a lock if it needs to acquire that lock but the lock is
held by another thread.
Delayed Thread Set. A set of threads not allowed executing at a checkpoint in order for
ExitBlock to schedule another thread. This set contains threads already executed from that
checkpoint. They are all re-enabled (remove from this set) after the first atomic block of
the branch.
Enabled Set. All other threads are put in the enabled set.
These sets are attributed to every checkpoint in the program. When the execution returns to
a checkpoint, these sets must be restored. This avoids the situation when a thread created
after a checkpoint would be scheduled at a place and time where it does not exist yet.
If the currently running thread cannot obtain a lock, a new thread must be scheduled
instead. Since threads can switch on atomic block boundaries only, the running thread and
the current branch of the tree must be aborted, the program must be scheduled instead. The
original thread is placed in the block set of the lock.
Calls to the wait() method of a lock are handled in the same way that lock exist are - an
atomic block terminated. The thread calling wait() is also removed from the set of enabled
threads. On contrary, all threads notified with a call to notifyAll() are put to the block set of

36
the respective lock because all notified threads must first obtain the lock in the order to get
schedulable. With notify(), the algorithm is the same but just one thread can be woken up.
Since it is a nondeterministic behavior, a new branch must be created for every possibly
woken up thread. Because a different thread must be notified in every branch, another
thread set exits: the No Notify Set. It contains threads already notified in a branch that
cannot be notified again.
In this basic version of the algorithm, the number of schedules that must be explored grows
exponentially in both the number of threads and the number of locks used by each thread.

2.8.3 ExitBlock RW
The ExitBlock-RW algorithm is a modification of the basic ExitBlock algorithm enabling
some schedules to be omitted during the program verification. If two atomic blocks have
no data dependences between them, then the order of their execution with respect to each
other has no effect on whether an assertion is violated or not. The ExitBlock-RW uses data
dependency analysis to prune the tree of explored schedules.
While executing an atomic block, all reads and writes are recorded. Instead of delaying the
current thread, a set of delayed threads is kept along with the reads and writes that were
executed in the atomic block. Only those threads from the delayed are re-enabled after the
next atomic block, whose reads and writes intersect with the currently running threads
reads and writes.
Two sets of reads and writes (r
1
, w
1
) and (r
2
, w
2
) interact if and only if
(w
1
w
2
) (r
1
w
2
) (w
2
w
2
).
The number of schedules that must be explored in this version of ExitBlock is polygonal in
the number of locks and still exponential in the number of threads.


2.8.4 ExitBlock DD
In general, two kinds of deadlock can be distinguished in concurrent Java programs
according to the authors of ExitBlock:
Lock-Cycle Deadlocks involve two or more threads blocked only on locks, i.e. blocked
when they attempt to enter a synchronized block.
Condition Deadlocks involve two or more threads that are blocked inside a synchronized
block on wait(), i.e. after they have found that a guarding condition does not hold.
As for the former kind of deadlock, the algorithm must keep track of thread-lock cycles
since at least two locks and two threads must be involved in a deadlock. If a lock cannot be
acquired by a thread, the algorithm uses so called reverse lock chain analysis. If the
current thread cannot obtain a lock and it is possible to follow a cycle of owner and lock
relationships back to the current thread, then a lock cycle deadlock is detected.
To detect the latter kind of deadlock is much easier and straightforward. A condition
deadlock occurs when the algorithm runs out of enabled threads, i.e. the Enabled Set is
empty at a certain checkpoint. A deadlock cannot be reported if there are delayed threads
that cannot be scheduled due to the used algorithm but would be runnable in reality.


37
2.8.5 Usability
The algorithm Exitblock and its implementation is directly targeted to the Java platform. It
is able to detect dependences errors and deadlocks. Moreover, it uses Eraser tool to detect
race conditions as a result of no convenient uses of synchronizations issues. The main
advantage of ExitBlock algorithm usage is its ability to test all possible schedules for given
input data in one run and the fact that it needs no formal model but uses a real program
compiled to Java bytecode.
On the contrary, must be used a special virtual machine The Rivet virtual machine. Also,
ExitBlock is not usable for reactive processes, infinite from their nature, due to the
requirements for terminating threads.

2.9 Java PathFinder 2 Executable Models of the Java Virtual
Machine
Java PathFinder is an explicit state model checker for Java programs that is built on top
of custom made virtual machine. It is itself written in Java. JPF2 works directly with Java
Bytecodes, not with source code, as its predecessor.
Currently, it can only check deadlocks and invariants. An invariant is specified as a Java
method that returns a boolean value. Boths the invariant and the program to be checked are
converted into bytecode and given as input to the model checker. The checker consists of
two parts: the MC-JVM that executes the bytecode and the depth first search algorithm
that does the traversal of the state space graph of the program. The algorithm can tell the
MC-JVM to:

- Move forward one step,
- Move backward one step,
- Evaluate the current invariant.

The MC-JVM keeps track of visited states; also the current path of states is stored on the
stack which allows easy backtracking. The output of the model checker is whether or not
the invariants hold the program is deadlock free. If a deadlock is found, a
counterexample is provided which can be fed back to the MC-JM in a simulation mode in
order to recreate the error.
The most important features of JPF2 are as follows:
- Canonical Heap representation. Regardless of the order of instructions, dynamic
and static memory is always allocated in the same memory locations as they were
allocated in previous run. This reduces the size of the state space.
- Garbage Collection. The MC-JVM has its own garbage collection scheme to
prevent the state space from growing indefinitely.
- Nondeterminism. The MC JVM supports nondeterminism by trapping calls to
Verify.Random(int) and Verufy.RandomBool().
- Atomicity. The level of atomicity can be set to one bytecode instruction, to one
Java instruction to one line of Java code or to independent Java blocks.

38
- Structured State. Each state of the program can be highly structured, since it
consists of a number of different Java objects.

2.9.1 Abstraction
A so called abstraction is provided by PF which converts a java program to an abstract
program with respect to user specified abstraction criteria. The user can specify
abstractions by removing variables or adding new variables to the abstract program. The
new variables typically depend on the already existing variables that can (but need not) be
removed. The inter calls abstraction is also possible. In such case, a new abstract variable
depends on old variables form several classes.

Abstraction can be applied to components of the whole program only, if it is too
complicated to apply abstraction globally.

2.9.2 Static Analysis
JPF uses static analysis to compute information to perform partial order reduction during
model checking. The static analyzer uses program dependencies to identify safe programs
blocks. A safe block is a block of consecutive Java statements that can be executed by the
virtual machine without worrying about interleaving, e.g. a sequence of statements using
only local variables.
JPF uses static analysis to alleviate the state explosion problem during model checking.

2.9.3 Runtime Analysis
Runtime analysis is based on the idea of executing the program just once to extract various
kinds of information. This information can be used to predict whether other different
execution traces may violate some properties of our interest. The algorithm is able to detect
even those violations that did not happen during the one run of the program but would
potentially happen in another run with different schedule. However, it is not guaranteed
that all violations are found and t is not certain that all found violations are not false.
An example of runtime analysis is the data race detection algorithm Eraser, implemented in
PathFinder. Or the locking order analysis, looking for potential deadlocks.
Runtime analysis can be used in two modes. First, it can be used stand alone in
simulation ode. Second, runtime analysis can be used to guide the model checker.
Pathfinder can generate a so-called race windows consisting of the threads involved in a
race condition. The model checker is then launched, focusing only on the race windows by
forcing the scheduler always can be extended with threads that write to objects read by the
threads in the original window.


39
2.9.4 Usability
JPF2 is intensively used by NASA. It is an efficient tool for finding deadlocks in software
called the Remote Agent in 1999, when it deadlocked in space in the middle of operation.
A little disadvantage is that false violations can be reported and, on the other hand, not all
real violations are guaranteed to be discovered.
2.10 Temporized Graphs and TCTL
In this chapter we introduce the temporized graphs that allow describing real-time systems,
and logic TCTL, used like language of specification of temporary properties. Also, we
analyzed a discretization of the inherent continuous temporary dominion to the considered
graphs and the logic, on the basis of which we obtain an alternative semantics that we will
assume in the rest of this work.

2.10.1 Temporized Graphs (Automaton)
The temporized graphs constitute a mathematician-computer model in which they can
imagine of formal way, simple, clear and modular many problems of the real world where
there are temporary restrictions that interfere with discreet transitions, which they represent
action or events. Several similar definitions of graphs (robots) temporized have been
proposed, as it is the case of [42], [43], [44], [45], [46].
A temporized graph is an extended automaton with a finite set of real variables, calls
clocks, whose values are increased uniformly over the years. These clocks are used to
measure, for example, the time passed between two events, the time of delay or the delay
of a communication. Inherent temporary restrictions to the actions of the system are
expressed binding conditions of activation to each one of the transitions of the automaton.
A transition is qualified, that is to say can be crossed, when its associate condition is
satisfied by the values of the clocks. A clock can be put to zero in any transition. To all
moment, the value of a clock is equal to the time passed from the last time in which it was
put to zero [42], [47].
Definition 3.1. Let be A a set (global) of labels, that we will assume fixed in this chapter.
A temporized graph (automaton) is a set of five elements

, where:
- L is a finite set of nodes called locations.
- X is a finite set of clocks. An evaluation of clocks is a function that assigns a
value to each v(x)e3
+
clock xeX, where 3
+
are the non-negative real numbers. V
denotes the set of evaluations. We write v+t as vevaluation like v(x) = v(x) + t for
all clocks x eX.
- E is a finite set of arcs called transitions. Each transition is a set of five elements e
= (l, o,
X
,
X
, l) that consist of an original location l eL, an target location leL, a
label o eA, a condition
X
and a set
X
_ X of clocks that are reset to zero
simultaneously with the transition.

40
t

A condition is a Boolean combination of atoms of the form x c, where x e X,
is a binary relation in the set {<, s, =, >, >} and c is an integer positive constant.
We denote +
X
as a predicate set
X
definable over X.
The transition e = (l, o,
X
,
X
, l) is qualified into the state (l, v) if v satisfies the
condition
X
. We will write v[
X
:= 0] as the evaluation vsuch as v(x) = 0 if x e
X

and v(x) = v(x) on the contrary.
- l
0
is the initial location. The initial state of the system is (l
0
, v
0
), with v
0
(x) = 0 for
all xeX, it is said, the initial location with all the clocks put in zero.
- I is the invariant set of the locations of the graph. For each leL, I
l
e+
X
is the
location invariant. When the system is in a state (l, v), it can stay in the location l
leaving the time go, while the current evaluation of the clocks satisfies the invariant
I
l
.

Observations
- The temporized graphs can be alternatively defined as a set of six elements; in
addition to them a set of labels instead of considering a global set A. [46].
- Each transition is labeled with a single label. Nevertheless, some works consider
transitions labeled with sets of labels (for example, [46]).
- In some definitions of temporized graphs an initial state is not distinguished.
In the rest of this work we will use indifferently the terms temporized graph and
temporized automaton.

2.10.2 Formal Semantics
The semantics of a temporized graph may be defined in function of a system of labeled
transitions [45], where the states are a pair (l, v) e LV and the transitions are of two types:
- Temporary. The nodes of the graph represent a continuous activity, given by the
passage of time. The passage of time t is represented a transition labeled with t.
- Discrete (instantaneous). The arcs of the graph represent discrete actions. The
execution of the action o is a transition labeled with o.

Definition 3.2. The model of a temporized graph G = (L, X, E, l
0
, I) is the transition
system labeled T = (Q, ), where:
- Q = {(l, v) | leL, veV, I
l
[v]} is a set of states. I
l
[v] mean that I
l
is true for the
evaluation v of the clocks. The states of the Q will be called valid states of the
system (they satisfy the local invariants). For q = (l, v) e Q, Loc(q) denotes the
location l.
- _ Q(A3
+
)Q is the transition relation, defined by the followings rules:

I
l
|v + t| 0 s ts t

(l, v) ( l, v + t)


41
t
i

o
1

o
0

t
0

t
i

oi
o
1

o
0

t
0

lab

t1
It is a temporal transition over the location l. The system can stay in that location while the
clocks value satisfies Il. The state (l, v+t) is a temporal successor of the state (l, v).

o

This is a discrete transition from l to l by the action o, when v satisfies the restriction

.
The state (l, v[
X
:= 0]) is the discrete successor of the state (l, v) by a. The condition I
l
(v)
. I
l
(v[
X
:= 0]) is implicitly in the former rule, because of the transition relationship is
defined between valid states, it is said (l, v) e Q and (l , v[
X
:= 0]) e Q.

Annotation. We write q q instead of (q, lab, q' ) e , for lab e A3
+
.
Observations

- The time happens only in the leases (temporary transitions).

- For each state q there is a transition to the same state which takes zero time.

- To cross an edge does not consume time (instantaneous transitions).

- The values of the clocks grow uniformly with time.

- With respect to the temporary transitions, the system is deterministic, but with
respect to the instantaneous transitions, the system is not it in the general case [45].

2.10.3 Execution Traces
An execution of temporized graph G (execution trace) is a states sequence

q
0
q
0
q
1
q
1
q
2
..., where q
i
q
i
represents a
temporal transition, q
i
q
i+1
is a discrete transition or a temporal transition with
zero time, and q
0
is the initial state of the execution. We denote R
G
as a set of all
executions of G and R
G
(q
0
) those which begin with the state q
0
.
We can observe that a transition q
i
q
i
conceptually represents those infinite states
of the form q
i
+ t', with t' s t
i
, and the definition of given execution allows that two or more
discrete events happen consecutively in the time, assuming intermediate transitions
temporary in null time. We notice in addition that two or more consecutive temporary
transitions can be represented by a unique one whose temporary value is given by the sum
of the values corresponding to the individual steps or putting in a temporary transition in
time zero.
Let be r an execution q
0
q
0
q
1
q
1
q
2
..... of R
G
(q
0
), a
position t of r is a pair (i, t) e Z 3
+
, with 0 s t s t
i
. We write o
r
(t) to denote the state (l,
v+t) with q
i
= (l, v), and o
r
(t) for the time E
j < i
t
j
+ t passed from the beginning of the
execution r. We call H(r) the set of all positions of r.

42
t
1

An execution r eR
G
diverges if for each t e3
+
exists a position t of r for that o
r
(t)>t .
The divergent executions are those in which the time advances beyond any limit (it
diverges); in literature they are denominated non-Zeno [48]. A
G
denote to the set of the
divergent sequences of execution of G and A
G
(q
0
) to which own beginning q
0
. We are
interested, like in previous works, in real-time systems temporized graphs in which all
finite prefix of an execution in R
G
is prefix of a sequence in A
G
. We will call them well
temporized systems. The behavior of the well temporized systems -each trace of
execution- can be generated, as it was described in the beginning, transition to transition,
beginning in an initial state and choosing between increasing the time (while the invariant
conditions are not violated) and to make a transition discrete (if this one is habilitated). In
these systems all the traces of execution must be necessarily infinite sequences.
Nevertheless, this is not a sufficient condition to assure non-Zeno (for example, a system
whose traces of execution are all infinite sequences that repeat always the same state, with
null temporary transitions, or that alternate consecutively in cyclical form one or more
states through discrete transitions, it does not fulfill non-Zeno).

2.11 Parallel Composition of Temporized Graphs
In order to facilitate the modular description of the systems the parallel composition of
temporized graphs is used. The parallel composition of two temporized graphs is the
product of both where the transitions that share labels must synchronize, that is to say, the
corresponding actions must execute themselves simultaneously. By each pair of these
transitions the global system will have a unique transition like the label is the same, the
condition is the conjunction of the conditions and the set of clocks to reset is the union of
the corresponding sets.

2.11.1 Definition of Composition
The parallel composition of two temporized graphs G
1
y G
2
, synchronizing the labels of
A _ A (common to G
1
and G
2
) is noted G1|[A]|G2 and is defined as follow. Let be G
1
=
(L
1
, X
1
, E
1
, l
1
0
, I
1
) and G
2
= (L
2
, X
2
, E
2
, l
2
0
, I
2
) like X
1
X
2
= C, G
1
|[A]|G
2
is the graph G =
(L, X, E, l
0
, I), where:

- X = X
1
X
2

- L _ L
1
L
2

- ((l
1
, l
2
), o,
X
,
X
, (l
1
' , l
2
' )) e E if and only if:
1. (l
1
, o,
X
,
X
, l
1
' ) eE
1
. o eA . l
2
= l
2
'
2. (l
2
, o,
X
,
X
, l
2
' ) eE
2
. o eA . l
1
= l
1
'
3. (l
i
, o,
iX
,
iX
, l
i
' ) eE
i
. o eA .
X
= (
1X
.
2X
) .
X
= (
1X

2X
)
- I ((l
1
, l
2
)) = I
1
(l
1
) . I
2
(l
2
)
- l
0
= ( l
1
0
, l
2
0
)


43
2.11.2 Semantics
The behavior of the graph G = G
1
|[A]|G
2
is it is bound to the behaviors of G
1
and G
2
. Let
T
1
= (Q
1
,
1
) y T
2
= (Q
2
,
2
) models of G
1
and G
2
respectively. The model of G is (Q
1
Q
2
,
),where is the smallest relationship that satisfies the rules related in the following
statements.

- Temporal Transitions. The temporary evolution of the system composed in a state
is conditional to the one of each component. If each component allows the passage
of a time t, the compound system can then advance t units. This determines that the
clocks of the compound system grow uniformly with time. Formally,
t t
q
1
1 q
1
q
2
2 q
2



t
(q1 , q2) ( q1 , q2 )

- Discrete Transitions (instantaneous). In this case exists two possibilities:
1. If from each component of a compound state q there is a transition labeled
with o then there is a transition with o from q to the state formed by the
states destinies of each component. Formally,

o o
q
1
1 q
1
q
2
2 q
2



o
(q1 , q2) ( q1 , q2 )

2. If from one of the component states there is a transition labeled with o and
o is not of synchronization (oeA), then there is a discrete transition with o
in the compound system that allows to advance only this component.
Formally,

o o
q
1
1 q
1
o e A
and
q
2
2 q
2
o e A



o

o


(q1 , q2) ( q1 , q2 ) (q1 , q2) ( q1 , q2 )



2.12 TCTL: Timed Computation Tree Logic
Many important properties of the systems find a natural expression in temporary logic [49].
The real-time temporal logic TCTL (Timed Computation Tree Logic) [42], [48], [43]
extends the temporal operators - ( exits one execution) and ( for all
executions) of CTL (Computation Tree Logic) [50], [2] with temporal restrictions that
permits a quantitative reasoning of the time. Although CTL is a suitable temporary logic
for reactive systems, this one allows qualitative reasoning of the time based on the notion
of sequence in the executions, but it is not possible to express in her quantitative temporary
restrictions. In CTL can be expressed properties like inevitably event e will happen or

44
property p is satisfied continuously in all the executions of the system. TCTL formulas
allow to express, in addition, properties such as inevitably before a time t the event e will
happen or property p continuously satisfies between the times t
i
and t
f
for all the
executions of the system.
The TCTL formulas are interpreted on the states of a real-time system and they are defined
from a set of basic predicates (atomic proposals) on the states. The set P of predicates on
the states of a temporized graph is defined in [45] as follows,

where l e L, xi, xj eX, c e Z, d e 9 y e {<, s, =, >, >}. In addition they used to be
considered the following basic predicates: init, enable(e) and after(e) [45].
Informally, init defines the initial state, enable(e) the set of states which have a habilitated
transition labeled with e and, after(e) the set of the states that they are reached about a
transition labeled with e.
Also, @ = l defines the set of the states whose location is l. The formal semantics will be
described in the next section.
The TCTL formulas are defined by the following grammar:

:= p |
1
|
1
.
2
|
1
-
I

2
|
1

I

2

Where p eP and I is an interval with positive integer ends (I can be open and close, limited
or not limited).
Intuitively
1
-
I

2
it means that an execution (divergent) of the system like
2
is fulfilled
in the same state, in a time t within an interval I and
1
is satisfied continuously in the
previous states.
1

2
expresses that for all the executions the previous property is
fulfilled.

2.12.1 TCTL Semantics
TCTL is a logic that considers time graft and is interpreted on a trees structure of states.
Each tree represents a reactive system, whose possible sequences of execution correspond
to ways in the tree, generated from the root.

Definition 3.3. For a transition labeled system T = (Q, ) corresponds to the temporized
graph G, a state q = (l, v) e Q and formula of TCTL, the relationship of the ability to be
satisfied q |= is defined by the induction in as follows [42], [45]:
q |= @= l if and only if, Loc(q) = l
q |= xi c if and only if, v(xi) c
q |= xi - xj d if and only if v(xi) - v(xj) d
q |= if and only if q |=
q |= 1 .2 if and only if q |= 1 y q |= 2
q |= 1-I2 if and only if -reAG(q).
-teH(r).or(t) |= 2
. or(t)eI .

45
t t. or(t ) |= 1

q |= 1I2 if and only if, reAG(q).
-teH(r).or(t) |= 2
. or(t)eI .
t t. or(t ) |= 1


Where, the relation between positions of an execution is defined as the lexicographic
order of pairs ((i,t) (i' ,t' ) if and only if: i < i' , i = i' and t < t' ).

2.12.2 Some Abbreviations
- We write - and for I=[0, ); -sc for -[0,c] and sc for [0,c].
- -^I (possible ) in the place of true-I2.
- ^I (inevitable ) in the place of trueI2.
- -I in the place of ^I.
- I (always) in the place of -^I.

According to the given abbreviations, -^I is satisfied by all states
from which it is possible to reach a state that verifies the formula , within the
interval I. Thus specifying the bounded reachability problems. ^I
states that is inevitable. A state q satisfies this formula if and only if,
from each execution with initial state q there exists a state that within the range I,
satisfies . The formula ^sc expresses the property of real-time response time
bounded, in which an event must occur before a certain time bounded c. I
specifies that is an invariant. That is, a state q satisfies I if and only if,
every execution which commences in q satisfies continually , within the interval I.
Finally, I characterizes the set of states from which there is an execution that
continually satisfies , within the interval I.

2.13 Models Verification: Temporized Graphs and TCTL
Given a timed graph G, which describes a real-time system T (a system of
labeled transitions), and a formula of TCTL, which specifies a requirement, the
problem of deciding, algorithmically, if T satisfies is an instance of the problem
verification of models ( "model-checking problem"). In this instance the problem was
solved by Alur, Courcoubetis and Dill [42]. His solution is based on the
explicit construction, from the graph of infinite state transitions T, of a graph
finite quotient, called the region graph. The regions are
determined by an equivalence relation on the set X (clocks of a
unifying graph) that unifies settings of the clocks from which the future behaviors

46
are essentially identical. That is, two clocks x1 and x2 are equivalent if the
same sequences of discrete transitions are possible from x1 and x2.

The construction of the graph of regions leads to a verification algorithm
models that is exponential in number of input clocks and the size of the constant G very
big. However, in practice it is often unnecessary to build the graph of whole regions. May
represent only the set of states required to solve a specific problem (for a given sentence )
and can symbolically represent sets of states as predicates of states. In other
words, instead of listing all regions, a verification algorithm symbolic models (symbolic
model-checking algorithm) computes the regions selectively and symbolically. The
algorithm proposed in [43] uses predicate transformers for computing the set of successors
analysis forward analysis or predecessors back analysis "backward analysis" set of
states. The characteristic set |[]| is a formula computed as a fixed point defined in terms
of downstream predicates. A detailed explanation of the method of symbolic model
checking can be found in [43], [51]. Other algorithms are described, for example, in [52],
[53], [ 54].

2.14 Time Discretization

2.14.1 Continuous Time vs. Discrete Time
The continuous time is usually represented using real or rational numbers.
They provide all the possibilities of a rich mathematics that is generally
needed to treat many kinds of problems. The real numbers have two main properties which
differentiate integers and rational numbers: the density and completeness. The density
property states that between any two time points there is always another, the property of
completeness, if a series of points is bounded above then there is a point that is the least
upper bound of the series. The density distinguishes the real and the rational integers; the
completeness distinguishes the real from the others.
The main advantage of this representation is that the real (and rational) are numbers
generally used in physics to represent time. This makes it more theories based on simple
physical laws and represent continuous change. Also, real (and rational) are a superset of
the integers, so they are more general and appropriate than the latter to represent time, but
they also have some disadvantages. It is difficult to make based on actual theories, partly
due to property density, which introduces the concept of "infinity" even in a bounded
interval. Another disadvantage is in their representation, especially in computers, the way
usually to represent them is through floating point numbers, which are only
approximation. Then problems arise, for example, to determine whether two numbers are
equal or not (they may differ about the same number).
The discrete time is usually represented using whole numbers and more precisely
natural numbers. The main advantage of this representation is that a theory
based on integers is easier to make and use. Similarly, the integers are Direct and
accurate representation in computers is not necessary to work with

47
approximations. The main disadvantage of integers is due to lack of expressiveness,
especially when we want to represent continuous change. For example, integer cannot
represent the solution of a system of equations if the solution is fractional. However, there
are several approaches that can represent continuous change (i.e., continuous functions)
using discrete time. For example, approaches based on the concepts of "errors" and
"granularity" [55], [56], [57], [58].

2.14.2 A Discrete Time Model
In this paper we are interested in analyzing real-time systems for a discrete time domain
and particularly in the context of temporized graphs. Numerous previous works consider
discrete time models using the natural numbers to model time [59], [60], [61], [62], [63],
[64], [65], [66]. This model is appropriate for, say, certain kinds of synchronous digital
circuits, where events occur at precise values increase time of a global clock.
In cases where it does not, the approach may be equally valid and requires the continuous
time is approximated by the choice of a particular granularity: the smallest time unit in the
system able to be referenced. The idea is that choosing a small enough granularity to verify
certain properties where lower time values are indistinguishable to the process of
verification [59], [42].
In the fictitious clock approach transitions (events) may occur in continuous time but are
recorded by a global clock, in discrete time. In this model a transition is generally
introduced special time tick and the time increases a unity with each tick (see, for example,
[60], [61], [64], [65], [66]).
With the fictitious clock semantics, if several events occur between two consecutive
instants time (two ticks) they can be distinguished only by the laws temporary, not the real
value of time.

For temporized graphs semantics-based there is an alternative based on a discrete time
(taking values in Z), which has been discussed in previous works (see, for example,
[62]). According to this view, temporary steps are multiples of a constant (ticks of a global
clock), and every moment the automaton can choose between increasing time or make a
discrete transition. Consider the fragment of an temporized automaton with 2 watches,
Figure 2.1 (a). The automaton can stay in the state letting time (i.e., the values of x
1
and x
2

increased simultaneously)
while x
1
s u. Also, when x
1
reaches a value k (assuming k s u) the automaton
can make a transition to another state and x
1
reset to zero. Restricting the domain
Z time to the conditions of stay in each state (invariants of the locations) can be replaced-
interpreted-by tick transitions as shown in Figure 2.1 (b).







48
x
1
< u
x
1
:= x
1
+ 1
x
2
:= x
2
+ 1

x
1
s u
x
1
> k x
1
> k


x
1
:= 0

x
1
:= 0


(a) (b)


Fig. 2.1: A Temporized Automaton and his interpretation on Discrete Time

Under this interpretation the clocks are simply nonnegative integer variables bounded,
whose values are increased simultaneously by temporal transitions and some of them reset
to zero by discrete transitions. In particular, any representation scheme for a dense
semantics, based on inequalities of clocks, can be specialized for discrete semantics
[67]. Since, on an order discrete, any inequality of the form x
i
<c can be written as the
inequality is not strict x
i
s c-1, the discrete regions may be expressed using only
non-strict inequalities. This observation has been used to improve efficiency of model
checking algorithms (see, for example, [67]) is considered with particular interest in this
work and that enhances that discretization of time "not much is lost" [64], [68], [69], [70],
[67]. In particular, [68] constructs two discretizations of automata timing of which
generate the same language "is not temporized" than their dense versions meet the same
set of TCTL properties.
With a discretization, a discrete implementation can be a slight variation some of the
dense executions that she represents, where some transitions are be taken simultaneously
while in a dense implementation transitions are separated by a small amount of time.

2.14.3 Algorithmic Interpretation of Temporized Graphs
Given a timed graph G = ( L, X = {x1, , xn}, E, l0, I ) and its transition system
labeled T = (Q, ), an algorithmic interpretation of a time domain system
can be seen as a discreet loop without termination bound - with initialization, in an
imperative language Small [71]. Time and discrete transitions are
performed by commands stored in a Do cycle. The guards are not
disjointed and necessarily assume a non-deterministic choice for them in the
execution, the Do is not deterministic. The algorithm takes as a precondition: the state
initial system is valid (satisfies the invariant of the initial location). Figure 2.2
describes the algorithmic interpretation of the graph G.


state
G
: L; // variable type of the program
state
G
:= l
0
; // initialization of the state
x
1
:= 0; ; x
n
:= 0 // initiaization of the clocks
{precondition: I
l
0
(x
1
, , x
n
) = true } // precondition: initial state is valid

49
Do // cycle Do

1
(x
1
, , x
n
) . state
G
= l
1
. I
l1
((update
X
(x
1
,
1
), , update
X
(x
n
,

1
))


o1
state
G
:= l
1
;

x
1
:= update
X
(x
1
,
1
); ; x
n
:= update
X
(x
n
,

1
)

m
(x
1
, , x
n
) . state
G
= l
m
. I
lm
((update
X
(x
1
,
m
), , update
X
(x
n
,

m
))

o
m
state
G
:= l
m
;

x
1
:= update
X
(x
1
,
m
); ; x
n
:= update
X
(x
n
,

m
)

I
stateG
(x
1
- o, ... , x
n
+ o)

tic
k
x
1
:= x
1
+ o; ...; x
n
:= x
n
+ o
EndDo
Fig. 3.2: Graphical Interpretation of a Temporized Graph

Each of the first m commands stored and labeled with labels oi e A (with A the
tag set of the system) corresponds to a transition (li, oi, i, i, li ) e E;
where update
X
(xj, i) = 0, if xj ei update
X
(xj , i) = xj, otherwise (each sign oi would be
interpreted as a statement that inspects the occurrence of event oi). The
last guarded command is a global clock tick, which is reflected in the
increase of each clock in X with o, the value of granularity chosen for the system. A value
o = 1/M, with M > |X| is sufficient to ensure that each inequality
form 0 < x1 < < xn < 1 has at least one possible assignment (a solution, xj = j-o). This
way we ensure that every possible state of the system has at least one
representative, an element in each equivalence class of graph of regions
that characterizes the system. Choose a o = 1/M is equivalent to assuming a Z as temporal
domain and multiplies the scale of the problem, i.e. constant, by M -both the graph and in
the properties to verify. This allows working with arithmetic Z.

The basic primitives of clocks considered are 4: initialization, reset,
growth and inspection (consultation). The first two correspond to an allocation to
zero, the increase is with o y inspection of a watch is its value.
An equivalent to the previous version that makes explicit the use of a unique global
clock that is obtained with slight variations. It incorporates a global clock to the
environment and initializes each x
j
clock of the system represented by the graph G with the
value of clock. The conditions i (x1, , xn) and Iloc (vx1, , vxn) the body of the Do are
replaced by i (clock - x1,, clock - xn) and Iloc (clock - vx1, , clock - vxn) . update
X
(xj,
i) is redefined as update
X
(xj, i) = clock, if xj ei and update
X
(xj, i) = xj, on the

50
contrary. The last guarded command (tick) only increases the global clock with o (xj are
not modified). This version emphasizes the existence of a single clock systems clock
- regulating the passage of time and that it is never reset. Each xj is actually a stopwatch
that measures the time elapsed since the last time it was reset. Consequently, the four basic
primitives of the system clocks xj are set for this version as follows. The initialization and
reset primitives correspond to the allocation xj := clock; the increase is implicit for each xj
(only increases explicitly global clock) and, inspection of the clock is the value clock - xj.
Each execution of a program Do is a valid execution trace of graph G,
from T, and the set of all executions is captured by the non-determinism
of the program.
The parallel composition of two programs Do -as in Figure 2.2- is a
program Do that composing the actions of initialization of each component and where each
guarded command is the result of the composition of the corresponding transitions.
That is, if oi is for synchronization then generates a guarded command that makes
in conjunction with the guards and ";" commands. For each oi that is not
for synchronization, the stored command Do component is included in the Do of
the composition. The commands stored for a temporary increase (tick) receive the
same treatment that synchronization transitions labeled as a temporary step is the same in
each component.
Verify that a predicate P is an invariant of a program Do
corresponds to test the following two conditions:
- Init P
- P . Bk wp(Sk, P), for each command Bk alab Sk, with lab e A {tick}
where Init is a predicate characterizing the initial state and wp (weakest precondition)
predicate transformer is proposed by Dijkstra in [72]. In calculating wp, a S program
terminates in a state verifying a predicate q, when the performance is commenced in a state
that satisfies the predicate wp (S, q).
Note that if it is proved that P is invariant for any choice of non-determinism, P is
continuously.
There are recent extensions of wp calculation that define new processors
predicates to work in the context of concurrent programs, with properties
of security and stability of properties in a process - safety - , the invariance
of predicates in the computations -to-always- and progress properties,
such as reachability of a state (predicate) from another -leads-to. Some of
these works are: [73], [74], [75], [76], and [77]. Application areas considered in practice so
far restricted to the analysis of data stream
deterministic networks, fault-tolerant systems and simple communication protocols
[77]. However, the considerable complexity of the approach in the extensions, the low state
of development, the unavailability of computer-based
attendance and lack of temporal notions considerations make this approach
be, firstly, unsatisfactory for the specification of systems requirements
temporary, the other a promising direction for further work
research.

51
2.15 Tools
In this subsection we present a compendium of tools used, basically for the simulation of
the experimental model. Tools like J Sim, J SourceMorph, JiJ are described
extensively in [101]. For the sake of brevity we will only mention the fundamentals of each
tool.
Would be appropriate to mention that all the three tools were developed at the University
of West Bohemia in the Department of Computer Science. All of them are open source and
available for free.

2.15.1 J Sim.
J Sim is an object oriented library for discrete time process oriented simulation. Its
main application area is queueing network simulation, however, the range of its use can be
very wide almost any system where object states change in a discrete manner can be
modeled using J Sim. J Sim is a simula like simulation environment written in Java.
2.15.2 The Simulation Library J-Sim
J-Sim was developed in the Computer Science Department of the University of West
Bohemia in Plzen. This library is intended for a discrete process-oriented simulation.
Typical areas of use J-Sim is a test of the distributed, parallel and FT (fault-
tolerant) programs and systems. J-Sim library is inspired by the programming
Simula language (object-oriented language, used for simulation calculations).
Of the user point of view it is an alternative to the C-Sim library written in C language.

J-Sim library is completely written in Java, which brings certain advantages: object-
oriented language, easy portability between different platforms, use of threads and
synchronization methods wait() and notify() are part of this language.

2.15.2.1 The Main Principles of Discrete Simulation
Basic concepts
Before an explanation of the principle of discrete simulation is a good idea to give some
basic concepts:
- Model assigned contruction for imitation of real objects. During construction
model is used for:
o Simplification - it takes into account only those properties of the object,
which are significant in relation to the purposes of developing the model.
o Generalization - only concrete real object is not modelled, but the whole
class of real objects that have similar properties.
Simplification and generalization iare usually described as an abstraction.
- System - Assigned defined set of elements, between which there is definite
ties. Define system over the real object requires both sooner
these simplifications and generalizations, the precise description of the element
properties and links between them.

52
- Modeling - process of construction and operation of the model. This activity leads
to obtain information about the real object through the system model.
- Simulation Model - program carried out in real time on a computer to imitate the
real object. Simulation program can create either a transcript of a mathematical
model for numerical programming language, or by direct modeling of temporal
variations of the structure and properties of the system components in model time.
- Simulation - research method, its goal is to replace the analyzed system with the
simulation model.With the simulation model we can perform experiments aimed to
obtain information of the originall studied system.
- Discrete Simulation - changes in the model occurs only in discrete
time points.

The Process of Calculating Discrete Simulation
To control during the calculation of discrete simulation is mainly used two methods:
- Method of interpreting events - all events which may occur in the future
development of the model are stored in a list called calendar event. This list is
sorted by ascending values of the model time of the appeareance of the event. This
interpretation takes place in discrete point (time of apperearance of the event) and
is implemented by calling subroutine, which belongs to a given type of event.
Interpretive subroutine carried out in the amendment to the model of the event and
then this event is removed from the calendar. If some event causes the emergence
of other events in the (future) model time, will be scheduled a new event (the event
will be added to the calendar).
- Method of pseudo-parallel processes - is based on object decomposition of the
control algorithm simulation calculation. The individual parts are encapsulated in
the computation of object classes, which acquire the character of separate own
computing process (have their own "life"). These computational processes are
performed in pseudo-parallel fashion their performace change in the time model
(at each point of real-time is at most one active process). Organizational data
structure is again used to calculate the calendar. Calendar events are arranged in
ascending order of value of activation time events. Each event also includes a link
to the process. Control loop computation process starts gradually in order of the
calendar entries.

Library J-Sim is founded on the method pseudo-parallel processes.

Discrete event simulation is divided into steps. One step is always done in one point (not
interval) of simulation time. This step can be performed arbitrarily long interval in real
time. At one point, the simulation time is can happen even more simulation steps.

Performed a simulation step can not be interrupted external influences the means that the
running process after the completion of its frequent calculation Sam surrenders control in
favor of another process. Between two consecutive simulation steps can be arbitrarily large
interval of simulation time - in real time, this pause skipped.
States in the simulation process
Every process in the simulation created using J-Sim simulation at any time located in one
of the following states:

53
- New - The process is found in this state, if already created, but has not yet been
scheduled.
- Passive - The process is passive, if it had already started out, but has no event in the
calendar. If not planned, has already run.
- Active - The process is active, if currently running.
- Planned - The process is not running, but has a scheduled event in the calendar. It
can therefore run in a future simulation step.
- Termination - The process ran to the end of his program and his life was ended.
This process has never run.
2.15.2.2 Structure J-Sim Library
J-Sim library consists of several classes in Java. All class includes the package (package)
cz.zcu.fav.kiv.jsim. Specified package have to import In any simulation program that uses
the library services.
The following text is a brief description of the major classes libraries J-Sim.
Class JSimSimulation
JSimSimulation class represents the theoretical simulation model, which contains other
objects: processes and queues. Each simulation object contains one instance of
JSimCalendar, which includes events for all processes involved in the simulation. During
one simulation step is taken in the calendar is always one event that, after completing step
removed from the calendar.
JSimSimulation class offers a method step () - one to invoke this method will always one
step simulation. The main simulation program, therefore usually contains cycle, which
calls the method of step (a) either to achieve the desired number of steps simulation and the
required time limit of the simulation.
Class JSimProcess
JSimProcess class is intended to represent the process, that is some activity in the
simulation model. Simulation user should always inherit this class and prekyt life method
(), which contains the code of life "process. Method of Life () is not a user called directly,
it is automatically called core of the J-Sim library of methods run () fibers process. Kod
process can be virtually arbitrary (even infinite, eg while (true)), the process is the
execution of part of its calculation of surrendering control of himself. To do this hold
method () and passivate () (explanation will follow) - to call one of these methods of
winding up the current simulation step. If the program reached the end of the process
Methods Life () means the end of life process (current and current simulation step) and this
process (this instance) is under simulation nepobez.V constructor classes derived from
JSimProcess (such a class constructor must exist, because JSimSimulation has only one
constructor, which has two parameters), it should first call the constructor of superclass
and pass him the name of the process and a link to a valid instance of JSimSimulation (eg
super (name, simulation)).
JSimProcess class inherits from class java.lang.Thread and enjoy the benefits of fiber
Java. Method run () class JSimProcess not be sealed (it is marked final) not be called
directly - it is called automatically from the method start () of the fibers (This is because
threads implementation in Java). Method start () is called by the Kernel Libraries J-Sim
prispousten new process. Method run () calls first (private) method getready (), then life
method (). More detailed description can be found in the documentation for J-Sim.

54
Class provides these methods for the planning process (they are marked as final, so it can
be overlaid):
- activate (When) - activation process. It is used in the event that a process you have
to schedule another process (this method can not process used on itself). Process
must be planned in a passive state. When parameter indicates the simulation time at
which the process will be scheduled (no time past).
- cancel () - the abolition planned. It is used when a process wants to cancel a
scheduled another process. Method can be applied "externally" to another process
that is planned in the state (can not use it on himself). After calling this method will
be deleted from the Calendar event concerned.
- hold (delta) - suspend activity for a specified period. Invoke this method can only
process used on himself. It follows that in the call should be in a state activity. To
the calendar will be adding new events and processes will be suspended. The
process will be "awakened" after delta units of simulation time.
- passivate () - suspend activity for an indefinite period. Invoke this method process
may be used only on itself, so it must be in active state. Performed process is
suspended, the calendar, but does not add any new event. If the calling process is
not rescheduled by another process (or main program), never run.
Class JSimHead
JSimHead class is the equivalent of type HEAD Simula. Represents the head linked list,
which may contain elements of type JSimLink.V class constructor is (besides the list of
names) must be determined by the simulation (class instance JSimSimulation) belong to
the list.
Class method provides access to elements of the list and basic statistical functions:
- empty() returns true if the list is empty (otherwise it returns false).
- cardina() returns the number of elements in the list.
- first() returns the first element of the list.
- last() returns the last element of the list.
- clear() eliminates all the elements in the list.
- getLw() return the value of median queue L
w
.
- getTw() returns the value of median waiting in the queue T
w
.

JSimHead class contains no methods for adding and removing individual elements.
Property "to be a member of the list" are not understood as the ability list, but the ability of
the element to these events provides the necessary methods.
Class JSimLink
JSimLink class represents one item linked list. Ideological origins based on the type LINK
language Simula. Unlike Simula however, is not a list of the common ancestor of
LINKAGE, both classes are derived directly from java.lang.Object.

A new element in the list, use one of two constructors. If you use a constructor without
parameters, however, the separate storage of any user data (later add data not possible).
Favorable, the application constructor with a parameter of type Object type, where the user
can at as a work element insert any data (preferably in the form instances of user-created
class), and later access them by using the method getData (). The advantage of this
implementation element is the fact that you can use it directly JSimLink instance of a class

55
does not need to inherit this class (the user gains the possibility that the class of user data
could inherit from any other class).
Each instance of a class JSimLink may be inserted into a maximum of one list (queue)
JSimHead. Adding to the list of executing some of the following methods:
- into() inserts element into the specified list.
- follows() - inserts the element in other designated element (this must already be
members of some list).
- precede () - inserts an element before other designated element (this must already
be a member a list).
Detractions from the list following the call link.out() for this element, however, not the end
of its existence - can be re-inserted into the (same or different) queue, or used for further
processing. If a user wishes element simulation really "destroy" should be repealed on it all
the links, e.g. link = null;
System exceptions
J-Sim library has its own system of derogations, as used in the presence of error and / or
unusual situations. A brief overview of the most exceptions, of course, more detailed
description can be found in the documentation and / or directly the source codes.
These exceptions are derived from the class JSimException.

- JSimInvalidParametersException - This exception is thrown by the method or
constructor when attempting to use an invalid argument (such as invalid object
reference simulation passed JSimProcess class constructor).

- JSimSimulationAlreadyTerminatedException - is thrown while attempting to add a
new process in the simulation, which is already finished. Simulation is complete
when there are no events scheduled or if there is no process.

- JSimTooManyProcessesException - This exception is thrown if you already J-Sim
simulation can not add more to the new process.

- JSimTooManyHeadsException - is thrown, where it can not J-Sim simulation to
add another queue.

- JSimInvalidProcessStateException - This exception is thrown by the method
setProcessState () while attempting to change unacceptably process status

- JSimSecurityException - is thrown if the user attempts to perform action, its
implementation is in a given situation is prohibited (eg, called in an attempt to
Methods passivate () over the process which is not in active status).


The following exceptions are a descendant of java.lang.RuntimeException

- JSimKernelPanicException - occurs in case of serious errors nucleus of J-Sim.
Should not be captured.


56
- JSimProcessDeath - Internal Exception J-Sim, used in the process killed. It
pioneered the methods hold () and passivate () method over the life of () to run (),
where it is detected. In no case should be detected by user.


2.15.3 JiJ Java in Java Simulation
The JiJ package is an extension of the J Sim libraty for simulation of Java multithreades
programs. It provides a replacement class for java.lang.- Thread and replacement methods
for wait(), notify(), and notifyAll() methods of class Object while keeping the main
properties of classic J Sim simulation: step by step execution on user request and
discrete values of simulation time, one value valid for a whole simulation step.

2.15.4 J SourceMorph
J SourceMorph is a converter of Java source code written in Java. It is based on JavaCC,
a popular parser generator. J SourceMorph was written by Jan Herna as the
implementation of his masters thesis.

2.16 UPPAAL Timed Systems
UPPAAL is being developed jointly by the Basic Research in Computer Science laboratory
at Aalborg University in Denmark and the Department of Computer Systems at Uppsala
University in Sweden, mainly by W. Yi, K. G. Larsen and P. Pettersson. UPPAAL is an
integrated tool environment for modeling, simulating and verifying real - time systems. It
is freely available (for non-profit applications) on the Internet.

2.16.1 What we can do with UPPAAL?
UPPAAL allows one to analyze networks of timed automata with binary synchronization.
It contains three main parts. First, timed processes are described using a graphical editor.
Second, systems can be simulated, viz. we can choose to perform a sequence of transitions,
and have a look at the behavior of the designed system. This is done by a graphical
simulator. Finally reachability properties can be verified (for example is it possible to
reach a state where clock x is greater than 5?, or is it true that for any reachable
configuration, when the train is on the crossing, the gate is closed?). This is done by
verified.

2.16.2 Uppaals Essentials
The friendly graphical user interface makes UPPAAL an excellent tool for modeling and
verifying real time systems.

57
The main drawbacks of UPPAAL are linked to the modeling formalism. First binary
synchronization is a bit restrictive and requires one to use ad hoc mechanisms to describe
other kinds of synchronizations (e.g., broadcast). Second, the specification language
considers only reachability properties and not a full temporal logic; this entails that testing
(or observer) automata are required to express complex properties.
Conclusion. UPPAAL is a very pleasant tool to analyze timed systems. Note that even
though verification is difficult for very big systems due to complexity reasons, simulation
is always possible and gives very useful hints about the system under study.

2.16.3 Modeling Timed Systems with Uppaal
Since September 1999 (version UPPAAL2k), the tool has had its own graphical system
editor which allows one to easily draw networks of timed automata. Note that it is also
possible to use a textual format to describe systems.
The main differences between timed processes used by UPPAAL and classical timed
automata are integer variables, which are permitted in UPPAAL systems and
synchronization between tied processes.
Integer Variables. It is possible to use integer variables in the description of timed systems
in UPPAAL. This makes the modeling process of complex systems easier. Note that such
integer variables and the clocks can be global to the whole system or local to a process;
they can be used in guards of transitions, in the invariant constraints and they can be
updated when a transition is performed.
Synchronization. In UPPAAL, timed automata can communicate using a binary
synchronization function based on the classical message passing model. Given a
communication channel a, an action a! (sending on a channel a) and a action a?
(receiving on a channel a)have to be performed synchronously. This mechanism is
restrictive and, for example, does not allow for a broadcast but this can be modeled by ad
hoc constructions (e.g. committed locations).
Some channels can be defined as urgent channels: when a transition on such a channel a is
possible (i.e. when an action a! and an action a? can be performed by two timed
automata), no delay transition is enabled as long as an urgent communication is possible.
Along the same line, urgent control states exist: when the current state of an automaton has
been defined as urgent location, no delay transition is allowed as long as there is an urgent
location in the configuration. Finally a control state can be defined as committed location:
if the current configuration of the network contains such a control state, only (action)
transitions leaving this state are possible (in particular no delay transition is possible). A
broadcast and more generally any n ary synchronization can be simulated by using such
committed locations.
New features in UPPAAL2k. Bounded integer variables (or arrays of them) can be defined.
Timed processes can be designed by using templates with parameters. Given such a
template, several timed processes can be defined.
This is very useful for systems with several identical components.

58

Figure 3.3: Modeling a railway crossing.

Example: Modeling a railway crossing. Figure xfd depicts a railway crossing involving a
gate, and two sensors App and Exit respectively telling the gate that a train is
approaching and leaving the passageway. This is a classical example of a real time
system, which we will only model coarsely here, assuming that there is only a single train
and the gate.
If the train speed on this railway section and the opening and closing speeds of the gate are
known, then it is possible to model this system with the two timed automata on the figure
sjd. To simplify, we assume the time unit is a minute. Synchronization is performed on the
actions shared by the two automata: App and Exit. The internal transitions (unlabelled)
are not synchronized.
The automaton modeling the train can switch from state far to near by emitting the App
signal and must synchronize with the corresponding transition (also labeled App) in the
automaton modeling the gate. The gate automaton then enters the lower if its state was
up, then the train spends two to five minutes reaching the crossing, etc.


59
Figure 3.4: Model of a Railway Crossing
The gate can be up, down, or in intermediate situations (in the process of going up or
coming down). We assume that it needs between one and two minutes to go up (to go from
the state down to the state up) or to come down: this information is represented by the
guards on the internal transitions. Furthermore, each state of the gate automaton is
equipped with transitions App and Exit corresponding to the reception of the signal
emitted by the train. These signals represent sensors, they are uncontrolled signals and
the gate must be in a position, regardless of its current state, to receive them and to act
accordingly.
This system can be modeled in UPPAAL as q network of timed automata. The integer
variable C in the controller process is used to count the number of trains moving between
the signals App and Exit. Then, the current system can easily be extended to any number
of trains.
The textual description of a system starts with the definition of global clocks, global
integer variables and channels. For the railway crossing example, only the channels are
global:
chan app, exit, GoDown, GoUp // channels
The textual description of the trains template is:

60

Figure 3.5: A template for train processes

The definition of a template for trains starts with the list of control states followed by their
invariant between braces if any (it is true by default). Then the list of transactions is given.
For any transaction, we have the source state and the target state, and three additional
components may appear: the guard of the transition, the synchronization action (a channel
name followed by ! or ?) and an update action over variables and clocks. From this
template, we define several timed processes corresponding to several trains in the model:
Train1 := Train();
Train2 := Train();
Train3 := Train();
Finally the network is defined by an instruction of the form:
system Train1, Train2, Train3, Gate, Controller

61

Figure 3.6: The gate

Figure 3.7: the controller

2.16.4 Simulating a System
Simulating is very useful to validate the model: it allows one to verify on simple cases that
the behavior of the models meets its specification. Clearly the graphical simulator of
UPPAAL is an important help for designing complex systems.
Executions of a system can be investigated in a dynamic way with the simulator. We can
select transitions step-by-step, have a look on the values of variables and clocks, save
executions Moreover it is possible to fire transitions in a random manner: we fix the

62
length of the run and the speed of the simulation, and (at any step) an enabled transition is
randomly selected and performed. This gives an overview of the behavior of the system.
Finally it is possible to get diagnostic traces from the model checking module and such
traces can be played within the simulator.
Note that simulating is not verifying: simulation does not consider the exhaustive behavior
of the system: therefore no safety proof can be given after this step (only a model
checker can prove safety properties), but it often enables one to find bugs in a model.
Correct it and validate it.

2.16.5 Verification
The third part of UPPAAL is the verifier. It implements model checking for reachability
properties over networks of timed automata. Atomic propositions are basic constraints over
control locations of the system and the values of clocks and variables:
- S.r expresses that the current location of automaton S is r;
- t ~ n expresses that the current value of t satisfies the test where t denotes a global
or local variable (or clock), n and ~ {=, <, >, , }.
Given a boolean combination P built from not, and, or and imply operators and atomic
propositions, there are two kinds of reachability properties based on operators AG and EF
of CTL temporal logic:
- AGP: P holds for any reachable configuration is written A[]P in UPPAAL
format. For example in the train crossing, the property when a train is on the
crossing, the gate is down is expressed with the following formula:
A[] ((Train1.on or Train2.on or Train3.on) imply
Gate.close)
- EFP: It is possible to reach a configuration verifying P is written E<>P in
UPPAAL.
Note that nesting operators EF and AG is not allowed.
Remember that the answer given by the model checker deals with all possible executions:
it produces an exhaustive analysis of the behavior of the system. Of course when the
property studied is of the form E<>P, the verifier stops as soon as it finds a configuration
C verifying P; moreover it gives a diagnostic trace leading to C. if the property is of the
form A[]P, UPPAAL needs to consider every reachable configuration except if it finds one
for which P does not hold; in this case, the program stops and gives a diagnostic trace
leading to this configuration.
Different options are available to tune the reachability algorithm: breadth-first or depth-
first search, reductions to save memory space Anyway the theoretical complexity is very
high and it is sometimes impossible to get an answer for a query if the decision procedure
requires to visit too many reachable configurations. Note that this restriction doses not hold
for simulation: it is always possible, even for big system. Using the verifier successfully
depends a lot of on the size of the input model and especially on the number of clocks. If
verification is not feasible, the model has to be simplified by abstraction.
The specification language used for the verifier is too restricted; it contains only simple
reachability properties. In the train crossing example, it would be interesting to express
that the gate is open at most 70 seconds after an exit signal if no train approaches the

63
railroad crossing in between. To verify such a property we need to use the testing
automata technique.

2.16.6 Documentation and case Studies
The paper UPPAAL on a Nutshell [78] available on the web server of UPPAAL is a
good introduction to this tool.
Many applications have been modeled and verified with UPPAAL, among which we can
mention:
- Audio video control of Bangs & Olufsen [79], [80];
- Audio control protocol of Philips [81];
- Analysis of a gear controller [78];
- Verification of a TDMA protocol [82].



64
3 Goals of the Thesis
3.1 Motivation
Testing and verification is an important part of the cycle of development software. When
one works with a sequential program the debugging of this program can be easily proved
that for a certain input is expected another certain output. It is certainly that for more than
one execution (debugging) of a sequential program the same errors can be detected in a
run-time. This situation is no more the same when one works with a concurrent or
distributed program. It is because the behavior of the parts of the distributed program can
execute in an uncertain order of executions. This means that for an execution of distributed
program for two or more runs is not necessary to obtain the same results. Even if the
program works without faults inside the code can be a potential error.
Concurrent program works mainly with a shared memory, this situation is not the same for
the distributed program that have not a shared memory.
As we mentioned above, the main goal of this work is to implement a method based for
testing and verification of the distributed embedded program by simulation before it will
be implemented in a real hardware (e.g. automobile industry).
The work will contain those topics:
1. A general description/analysis of distributed Java program behavior should be
presented. The analysis should identify various entities and describe their behavior
during a program execution, mainly during threading-specific operations.
2. As a result of (1) a method for distributed Java program checking should be
developed. The method should target mainly:
a. The ability to execute a distributed Java program in a managed/simulated
way so that all entries identified in point (1) and operations on them are
properly simulated;
b. The ability to analyze the tested program at runtime in such a way that is
not affected by Java multithreading, i.e. the ability to view the program
from a global point of view in a consistent state in the same way a classic
sequential program can be seen;
c. The ability to discover a faulty behavior, we mean either multithreading-
related incorrectness in the program or a situation when the tested program
is not able to fulfill its task, e.g. then a controlled device to wrong state;

65
d. The ability to test a reactive program within a close to real environment
that supplies events and data to it the environment should provide
program input data that are expected in the target environment and it should
reflect program output data by changing its state appropriately.
3. Tools to fulfill the above requirements should be developed to demonstrate that the
presented theory and solutions based on it are viable.
4. The method and the tools should be demonstrated on a representative example.







66
4 Distributed State Space Model of
Java Distributed Programs
4.1 Introduction

A distributed system consists of a set of processors that are connected by a communication
network. The communication network provides the facility of information exchange among
processors. The communication delay is finite but unpredictable. The processors do not share a
common global memory and communicate solely by passing messages over the communication
network. There is no physical global clock in the system to which processes have instantaneous
access. The communication medium may deliver messages out of order, messages may be lost,
garbled, or duplicated due to timeout and retransmission, processors may fail, and communication
links may go down. The system can be modelled as a directed graph in which vertices represent the
processes and edges represent unidirectional communication channels. A distributed application
runs as a collection of processes on a distributed system. In the next section we present a model of
a distributed computation and introduce several terms, concepts, and notations that will be used in
the subsequent subdivisions of this chapter.

4.2 A Distributed Program
A distributed program is composed of a set of n asynchronous processes p
1
, p
2,
,p
i,
,p
n
that
communicate by message passing over the communication network. Without loss of generality, we
assume that each process is running on a different processor. The processes do not share a global
memory and communicate solely by passing messages. Let C
ij
denote the channel from process p
i

to process p
j
and let m
ij
denote a message sent by p
i
to p
j
. The communication delay is finite and
unpredictable. Also, these processes do not share a global clock that is instantaneously accessible to
these processes. Process execution and message transfer are asynchronous a process may execute
an action spontaneously and a process sending a message does not wait for the delivery of the
message to be complete.

The global state of a distributed computation is composed of the states of the processes and the
communication channels [84]. The state of a process is characterized by the state of its local
memory and depends upon the context. The state of a channel is characterized by the set of
messages in transit in the channel.


67
4.3 A Model of Distributed Executions
The execution of a process consists of a sequential execution of its actions. The actions are atomic
and the actions of a process are modelled as three types of events, namely, internal events, message
send events, and message receive events. Let
x
i
e denote the xth event at process p
i
. Subscripts
and/or superscripts will be dropped when they are irrelevant or are clear from the context. For a
message m, let send(m) and rec(m) denote its send and receive events, respectively.
The occurrence of events changes the states of respective processes and channels, thus causing
transitions in the global system state. An internal event changes the state of the process at which it
occurs. A send event (or a receive event) changes the state of the process that sends (or receives)
the message and the state of the channel on which the message is sent (or received). An internal
event only affects the process at which it occurs.
The events at processes are linearly ordered by their order of occurrence. The execution of process
p
i
produces a sequence of events ,... , ,..., ,
1 2 1 + x
i
x
i i i
e e e e and is denoted by
i
:

i
= (h
i

i
),
Where h
i
is a set of events produced by p
i
and binary relation
i
defines a linear order on these
events. Relation
i
expresses causal dependencies among the events of p
i
.
The send and receive events signify the flow of information between processes and establish causal
dependency from the sender process to the receiver process. A relation
msg
that captures the
causal dependency due to message exchange, is defined as follows. For every message m that is
exchanged between two processes, we have
send(m)
msg
rec(m).

Relation
msg
defines causal dependencies between the pairs of corresponding send and receive
events.
The evolution of a distributed execution is depicted by a state time diagram. Figure 1 shows the
state space diagram of a distributed execution involving three processes.




Figure 4.1: The space-time diagram of a distributed execution

A horizontal line represents the progress of the process; a dot indicates an event; a slant arrow
indicates a message transfer. Generally, the execution of an event takes a finite amount of time;
however, since we assume that an event execution is atomic (hence, indivisible and instantaneous),
it is justifies to denote it as a dot on a process line. In this figure, for process pi, the second event is
a message send event, the third event is an internal event, and the fourth event is a message receive
event.

68

Causal precedence relation
The execution of a distributed application results in a set of distributes evens produced by the
processes. Let H =
i
h
i
denote the set of events executed in a distributed computation. Next, we
define a binary relation on the set H, denoted as , that expresses causal dependencies between
events in the distributed execution.


The causal precedence relation induces an irreflexive partial order on the events of a distributed
computation [87] that is denoted as

= (H,

). Note that the relation is Lamports happens
before relation [86]. For any two events
i
e and
j
e , if
i
e
j
e , then event
j
e is directly or
transitively dependent on event
i
e ; graphically, it means that there exists a path consisting of
message arrows and processes-line segments (along increasing time) in the space-time diagram that
starts at
i
e and ends at
j
e . For example, in Figure 1,

and

. Note that relation

denotes flow of information in a distributed computation and

dictates that all the

information available at

is potentially accessible at

. For example in figure 1, event

has the
knowledge of all other events shown in the figure.
For any two events

and

denotes the fact that event

does not directly or transitively

dependent on event

. That is, event

does not causally affect event

. Event

is not aware of
the execution of

or any event executed after

on the same process. For example, in figure 1,

and

. Note the following two rules:

- For any two events

and

- For any two events

and

.
For any two events

and

, if

and

, then events

and

are said to be concurrent

and the relation is denoted as

. In the execution of figure 1,

and

. Note that
relation is not transitive; that is,

. For example, in figure 1,

and

, however,

.
Note that for any two events

and

in a distributed execution,

or

, or

.

Logical vs. physical concurrency
In a distributed computation, two events are logically concurrent if and only if they do not causally
affect each other. Physical concurrency, on the other hand, has a connotation that the events occur
at the same instant in physical time. Note that two or more events may be logically concurrent even
though they do not occur at the same instant in physical time. For example, in Figure 1, events in
the set { }
3
3
4
2
3
1
, , e e e , are logically concurrent, but they occurred at different instants in physical time.
However, note that if processor speed and message delays had been different, the execution of
these events could have very well coincided in physical time. Whether a set of logically concurrent
events coincide in the physical time or in what order in the physical time they occur does not
change the outcome of the computation.
Therefore, even though a set of logically concurrent events may not have occurred at the same
instant in physical time, for all practical and theoretical purposes, we can assume that these events
occurred at the same instant in physical time.


69
4.4 Models of communication networks
There are several models of the service provided by communication networks, namely, FIFO (first-
in, first-out), non-FIFO, and causal ordering. In the FIFO model, each channel acts as a first-in
first-out message queue and thus, message ordering is preserved by a channel. In the non-FIFO
model, a channel acts like a set in which the sender process adds messages and the receiver process
removes messages from it in a random order. The causal ordering model [83] is based on
Lamports happens before relation. A system that supports the causal ordering model satisfies the
following property:

CO: For any two messages m
ij
and m
kj
, if send(m
ij
) send(m
kj
), then rec(m
ij
) rec(m
kj
).

That is, this property ensures that causally related messages destined to the same destination are
delivered in an order that is consistent with their causality relation. Causally ordered delivery of
messages implies FIFO message delivery. Furthermore, note that CO FIFO Non-FIFO.
Causal ordering model is useful in developing distributed algorithms. Generally, it considerably
simplifies the design of distributed algorithms because it provides a built-in synchronization. For
example, in replicated database systems, it is important that every process responsible for updating
a replica receives the updates in the same order to maintain database consistency. Without causal
ordering, each update must be checked to ensure that database consistency is not being violated.
Causal ordering eliminates the need for such checks.

4.5 Global state of a distributed system
The global state of a distributed system is a collection of the local states of its components, namely,
the processes and the communication channels [84], [85]. The state of a process at any time is
defined by the contents of processor registers, stacks, local memory, etc. and depends on the local
context of the distributed application. The state of a channel is given by the set of messages in
transit in the channel. The occurrence of events changes the states of respective processes and
channels, thus causing transitions in global system state. For example, an internal event changes the
state of the process at which it occurs. A send event (or a receive event) changes the state of the
process that sends (or receives) the message and the state of the channel on which the message is
sent (or received).
Let
x
i
LS denote the state of process
i
p after the occurrence of event
x
i
e and before the event
1 + x
i
e .
0
i
LS denotes the initial state of process of event
i
p .
x
i
LS is a result of the execution of all the
events executed by process
i
p till
x
i
e . Let
x
i
LS m send s ) ( denote the fact that
). ( :: 1 : m send e x y y
y
i
= s s - Likewise, let
x
i
LS m rec s/ ) ( denote that the fact
). ( :: 1 : m rec e x y y
y
i
= s s
The state of channel is difficult to state formally because a channel is a distributed entity and its
state depends upon the states of the processes it connects. Let
y x
ij
SC
,
denote the state of a channel
ij
C defined as follows:
} ) ( ) ( | {
, y
j ij
x
i ij ij
y x
ij
LS m rec LS m send m SC s/ . s =
Thus, channel state
y x
ij
SC
,
denotes all messages that
i
p had not received until event
y
j
e .


70
4.5.1 Global state
The global state of distributed system is a collection of the local states of the processes and
channels. Notationally, the global state GS is defined as
{ }. ,
,
,
k j
i
z y
jk k j
x
i i
SC LS GS =
For a global snapshot to be meaningful, the states of all the components of the distributed system
must be recorded at the same instant. This will be possible if the local clocks at processes were
perfectly synchronized or there was a global system clock that could be instantaneously read by the
processes. However, both are impossible.
However, it turns out that even if the state of all the components in a distributed system has not
been recorded al the same instant, such a state will be meaningful provided every message that is
recorded as received is also recorded as sent. Basic idea is that an effect should not be present
without its cause. A message cannot be received if it was not sent; that is, the state should not
violate causality. Such states are called consistent global states and are meaningful global states.
Inconsistent global states are not meaningful in the sense that a distributed system can never be in
an inconsistent state.
A global state { }
k j
i
z y
jk k j
x
i i
SC LS GS
,
,
, = is a consistent global state iff it satisfies the
following condition:

) ( :
ij ij
m send m ) (
,
ij
y x
ij ij
x
i
m rec SC m LS
i i i
. e
j
y
j
LS .

That is, channel state
k i
z y
ik
SC
,
and process state
k
z
k
SC must not include any message that process p
i

sent after executing event
i
x
i
e . In the distributed execution of figure 2, a global state
1
GS consisting
of local states { }
2
4
3
3
3
2
1
1
, , , LS LS LS LS is inconsistent because the state of p
2
has recorded the receipt
of message m
12
, however, the state of p
1
has not recorded its send. On the contrary, a global state
2
GS consisting of local states { }
2
4
4
3
4
2
2
1
, , , LS LS LS LS is consistent; all the channels are empty
except
21
C that contains message m
12
.

Figure 4.2: The space-time diagram of a distributed execution

A global state { }
k j
i
z y
jk k j
x
i i
SC LS GS
,
,
, = is transitless iff

. :: , 1 : ,
,
| = s s
j i
z y
ij
SC n j i j i


Thus, all channels are recorded as empty in a transitless global state.

71
A global state is strongly consistent iff it is transitless as well as consistent. Note that in figure 2,
the global state consisting of local states { }
2
4
4
3
3
2
2
1
, , , LS LS LS LS is strongly consistent.
Recording the global state of a distributed system is an important paradigm when one is interested
in analyzing, monitoring, testing, or verifying properties of distributed applications, systems, and
algorithms. Design of efficient methods for recording the global state of a distributed system is an
important problem.

4.6 Cuts of a distributed computation
In the spacetime diagram of a distributed computation, a zigzag line joining one arbitrary point on
each process line is termed a cut in the computation. Such a line slices the spacetime diagram, and
thus the set of events in the distributed computation, into a PAST and a FUTURE. The PAST
contains all the events to the left of the cut and the FUTURE contains all the events to the right of
the cut. For a cut C, let PAST(C) and FUTURE(C) denote the set of events in the PAST and
FUTURE of C, respectively. Every cut corresponds to a global state and every global state can be
graphically represented as a cut in the computations spacetime diagram [87].

Definition 2.1 If
) ( _ C PAST Max
i
I
e denotes the latest event at process p
i
that is in the PAST of a cut
C, then the global state represented by the cut is { }
k j
i
z y
jk k j
C PAST Max
i i
SC LS
,
,
) ( _
,

where
{ }. ) ( ) ( ) ( ) ( |
,
C FUTURE m rec C PAST m send m SC
k j
z y
jk
e . e =

A consistent global state corresponds to a cut in which every message received in the PAST of the
cut was sent in the PAST of that cut. Such a cut is known as a consistent cut. All messages that
cross the cut from the PAST to the FUTURE are in transit in the corresponding consistent global
state.
A cut is inconsistent if a message crosses the cut from the FUTURE to the PAST. For example, the
spacetime diagram of Figure 3 shows two cuts, C
1
and C
2
. C
1
is an inconsistent cut, whereas C
2
is
a consistent cut. Note that these two cuts respectively correspond to the two global states GS
1
and
GS
2
, identified in the previous subsection.

Figure 4.3: Illustration of cuts in a distributed execution

Cuts in a state time diagram provide a powerful graphical aid in representing and reasoning about
states of computation.


72
4.7 Past and future cones of an event
In a distributed computation, an event
j
e could have been affected only by all events
i
e such that
i
e

j
e and all the information available at
i
e could be made accessible at
j
e . All such events
i
e
belong to the past of the
j
e [87]. Let ) (
j
e Past denote all events in the past of the
j
e in a
computation (H, ). Then,
{ }
j i i i j
e e H e e e Past e = , | ) (
Figure 4 shows the past of an event
j
e . Let ) (
j i
e Past be the set of all those events of ) (
j
e Past
that are on process p
i.
Clearly ) (
j i
e Past is a totally ordered set, ordered by the relation

, whose
maximal element is denoted by )) ( max(
j i
e Past is the latest event at process p
i
that affected event
i
e (see Figure 4). Note that )) ( max(
j i
e Past is always a message send event.
Let
( )
{ }. )) ( max( ) ( _
j i i j
e Past e Past Max

= ) ( _
j
e Past Max consist of the latest event at every
process that affected event
j
e and is referred to as the surface of the past cone of
j
e [87]. Note that
) ( _
j
e Past Max is a consistent cut [88]. ) (
j
e Paste represents all events on the past light cone that
affect
j
e .
Similar to the past is defined the future of an event. The future of an event
j
e , denoted by
) (
j
e Future , contains all events
i
e that are causally affected by
j
e (see figure 4). In a computation
(H, ), ) (
j
e Future is defined as:
{ }. , | ) (
i j i i i
e e H e e e Future e =
Likewise, we can define ) (
j i
e Future as the set of those events of ) (
j
e Future that are on process p
i

and )) ( min(
j i
e Future as the first event on process p
i
that is affected by
j
e .

Figure 4.4: Illustration of past and future cones in a distributed computation.

Note that )) ( min(
j i
e Future is always a message receive event. Likewise, )) (( _
j
e Past Min ,
defined as

))} ( {min(
) ( j i i
e Future

, consists on the first event at every process that is causally

affected by event
j
e and is referred to as the surface of the future cone of
j
e [87]. It denotes a

73
consistent cut in the computation [88]. ) (
j i
e Future represents all events on the future light cone
that are affected by
j
e .
It is obvious that all events at a process
i
p that occurred after
j
e )) ( max(
j i
e Past but before
)) ( min(
j i
e Future are concurrent with
j
e . Therefore, all and only those events of computation H
that belong to the set H - ) ( ) (
j j
e Future e Paste are concurrent with event
j
e .

4.8 Models of process communications

There are two basic models of process communications [89] synchronous and asynchronous. The
synchronous communication model is a blocking type where on a message send, the sender process
blocks until the message has been received by the receiver process. The sender process resumes
execution only after it learns that the receiver process has accepted the message. Thus, the sender
and the receiver processes must synchronize to exchange a message. On the other hand,
asynchronous communication model is a non-blocking type where the sender and the receiver do
not synchronize to exchange a message. After having sent a message, the sender process does not
wait for the message to be delivered to the receiver process. The message is buffered by the system
and is delivered to the receiver process when it is ready to accept the message. A buffer overflow
may occur if a process sends a large number of messages in a burst to another process. Neither of
the communication models is superior to the other. Asynchronous communication provides higher
parallelism because the sender process can
execute while the message is in transit to the receiver. However, an implementation of
asynchronous communication requires more complex buffer management. In addition, due to
higher degree of parallelism and non-determinism, it is much more difficult to design, verify, and
implement distributed algorithms for asynchronous communications. The state spaces of such
algorithms are likely to be much larger. Synchronous communication is simpler to handle and
implement. However, due to frequent blocking, it is likely to have poor performance and is likely
to be more prone to deadlocks.
The presented state-space model is a theoretical background for the experimental testing method
described in chapter 6. However, as stated above, the testing method does not use the model fully
to avoid problems known from model checkers. As a result, not all incorrectness must always be
found but no false incorrectness can be reported. The state-space model had to be introduced
because it is a theoretical base for the testing method and it is used by the tool presented in section
7.

74
5 Model-Based Development of
Distributed Java Embedded
Systems
In this chapter we will dedicate the use of the theory presented in Chapters 3, and
4. Basically describes how checking of an embedded distributed system program can be
incorporated into the development process and how it can be done to get the maximum
performance at low time expenses. We propose a chain of two methods first how the
system requirements are verifiable with TCTL formalism and second simulation program
utilization based in time serialization of threads.
The area of embedded systems has been chosen because in this field of software
engineering is where you can best show the benefits of the method presented due to
limitations of the testing and debugging of these systems. Another motivation is that
distributed systems are often used as embedded control programs.
In particular, this chapter discusses a development process that involves testing programs
as one of their parties and lists all the important parts to be found in the construction of
these to facilitate the transition from a simulated system to the way production.

5.1 The Proposed Development Process
Part One: Software Requirement Engineering, TCTL and Uppaal.
5.1.1 Requeriments Engineering-Process
Requirements engineering is a subdiscipline of software engineering which is concerned
with determining the goals, functions and constraints of software systems and the
representation of these issues favorably for the modeling and analysis.
The goal is to create a requirements specification to be complete, correct and
understandable for both the user and developers. This last point creates a kind of dilemma,
since it must be clear to users and to developers. In the domain of real-time systems this is
quite complicated due to the representation of time constraints and the performance and
functional requirements more easily applied.

75
The process of requirements engineering starts with a preliminary study. This is an
investigation into the motivation of the project and the nature of the problem. This research
should consist of user perspectives and limitations, determination of project scope and
priorities of the features, in real-time systems, an early analysis of the time constraints
imposed on the system. One of the major deliverables of the preliminary study is a
feasibility report, which can advise disrupt the development of software product. Most
often this is not the case, and preliminary study will be followed by requirements
elicitation.
Requirements elicitation involves gathering requirements through a variety of techniques
that may include stakeholder interviews and questionnaires, focus groups, workshops, and
prototyping. While requirements can be expressed in many forms ranging from standard
text through mathematical formalisms, it is usual for requirements to be represented in the
form of a domain model, that is, a model of the problem domain that may include such
artifacts as use cases, entity-relationship diagrams, or context diagrams.
The next stage is requirements definition. It is important to define, as precisely as possible,
each of the captured requirements so that they can be analyzed for completeness,
noncontradiction, and correctness in the validation stage. The overall outcome of this
process is a requirements document containing a software requirements specification
(SRS), which is a description of the features, behaviors, and constraints of the final system.
Precise software specifications provide the basis for analyzing the requirements, validating
that they are the stakeholders intentions, defining what the designers have to build, and
verifying that they have done so correctly.

5.1.2 Types of Requirements
While there are a number of useful taxonomies of requirements, the most established being
the simple functional versus nonfunctional classification; the standard scheme for real-time
systems is defined by IEEE Standard [IEEE830]. Standard 830 [IEEE98] defines the
following kinds of requirements:
1. Functional
2. External interfaces
3. Performance
4. Logical database
5. Design constraints
a. Standards compliance
b. Software systems attributes
6. Software system attributes
a. Reliability
b. Availability
c. Security
d. Maintainability
e. Portability

Requirements 2 through 6 are considered to be nonfunctional.
Performance requirements include the static and dynamic requirements placed on the
software or on human interaction with the software as a whole. For a real-time system,
static requirements might include the number of simultaneous users to be supported. The
dynamic requirements might include the number of transactions and tasks and the amount

76
of data to be processed within certain time periods for both normal and peak workload
conditions. Logical database requirements include the types of information used by various
functions, such as frequency of use, accessing capabilities, data entities and their
relationships, integrity constraints and data-retention requirements. Design constraint
requirements are related to standards compliance and hardware limitations. Lastly,
software system attribute requirements include reliability, availability,
security, maintainability, and portability. It is worth observing that the conventional
nomenclature for functional versus nonfunctional requirements is unfortunate; however,
because the terms functional/nonfunctional seem inappropriate for real-time systems. A
more logical taxonomy would include a classification of behavior observable via execution
and that which is not observable via execution (e.g., maintainability, portability).

5.1.3 Requirement Specification for Real-Time Systems
Threr appear that there are not specific approaches for specification of real-time
applications. In general there are the following:
1. Top dow process decomposition or structured analysis.
2. Object oriented approaches.
3. Program description languages (PDL) or pseudocode.
4. High level functional specifications that are not further decomposed.
5. Ad hoc techniques, including simple natural language and mathematical
description, and are always included in virtually every system specification.
There are three general classifications of specification techniques; informal, formal, and
semiformal. Formal methods have a rigorous, mathematical basis. A small sampling of
these approaches is discussed in the next section. A requirements specification technique is
informal if it cannot be completely transliterated into a rigorous mathematical notation and
associated rules.
Informal specifications, for example, flowcharting, have little or no underlying
mathematical structure; therefore, they cannot be properly analyzed. All that can be done
with informal specifications is to find counterexamples of where the system fails to meet
the requirements or where there are conflicts. This is simply not good enough for real-time
systems where formal substantiation of performance characteristics of requirements is
necessary. Approaches to requirements specification that defy classification as either
formal or informal are sometimes called semiformal. Semiformal approaches, while not
appearing to be mathematically based, might be. For example, some contend that Unified
Modeling Language (UML) is semiformal because the Statechart is formal and other
metamodeling techniques it employs have a pseudomathematical basis.

5.1.4 Formal Methods in Software Specification
Formal methods attempt to improve requirements formulation and expression by the use
and extension of existing mathematical approaches such as propositional logic, predicate
calculus, and set theory. This approach is attractive because it offers a more scientific way
to requirements specification. Writing formal requirements can often lead to error
discovery in the earliest phases of the software life cycle, where they can be corrected
quickly and at a low cost. By their nature, specifications for most real-time systems usually

77
contain some formality in the mathematical expression of the underlying interactions with
the systems in which they are embedded. While this fact does not justify the claim that
every real-time system specification is fully formalized, it does lead to some optimism that
real-time systems can be made suitable for, at least, partial formalization.
Formal methods, however, are perceived to be difficult to use by even the most expertly
trained and are sometimes error-prone. For these reasons, and because they are often
believed to increase early life-cycle costs and delay projects, formal methods are
frequently avoided. Formal methods attempt to improve requirement formulation and
expression by applying mathematics and logic. Formal methods employ some combination
of predicate calculus (first-order logic), recursive function theory, Lambda calculus,
programming language semantics, discrete mathematics, number theory, abstract algebra,
and so on. One of the primary attractions of formal methods is that they offer a highly
scientific approach to development. Formal requirements offer the possibility of
discovering errors at the earliest phase of development, while the errors can be corrected
quickly and at a low cost. Informal specifications might not achieve this goal, because
while they can be used to refute a specific requirement by counterexample, the
counterexamples might not be obvious because there is no rigorous approach to reasoning
about them. Formal methods are typically not intended to take on an all-encompassing role
in system or software development. Instead, individual techniques are designed to optimize
one or two parts of the development life cycle. There are three general uses for formal
methods:
- Consistensy Checking: this is where system behavioral requirements are described
using a mathematically based notation.
- Model Checking: state machines are used to verify whether a given property is
satisfied under all conditions.
- Theorem Proving: here, axioms of system behavior are used to derive a proof that a
system will behave in a given way.

Formal methods also offer opportunities for reusing requirements. Embedded systems are
often developed as families of similar products, or as incrementeal redesigns of existing
products. For the first situation, formal methods can help identify a consisten set of core
requirements and abstractions for the existing system provides a precise reference for
baseline baseline behavior, and provides a way to analyze proposed changes.
5.1.5 Limitations of Formal Methods
Formal methods have two limitations that are of special interest to real-time system
developers. First, although formalism is often used in pursuit of absolute correctness and
safety, it can guarantee neither. Second, formal techniques do not yet offer good ways to
reason about alternative designs or architectures.
Correctness and safety are two of the original motivating factors driving adoption of
formal methods. Nuclear, defense, and aerospace regulators in several countries now
mandate or strongly suggests use of formal methods for safetycritical systems. Some
researchers emphasize the correctness properties of particular mathematical approaches,
without clarifying that mathematical correctness in the development process might not
translate into real-world correctness in the finished system. After all, it is only the
specification that must be produced and proven at this point, not the software product
itself.

78
Formal software specifications must be converted to a design, and later, to a conventional
implementation language at some point. This translation process is subject to all the
potential pitfalls of any programming effort. For this reason, testing is just as important
when using formal requirement methods as when using traditional ones, though the testing
load can be reduced with formal methods. Formal verification is also subject to many of
the same limitations as traditional testing, namely, that testing cannot prove the absence of
bugs, only their presence. Notation evolution is a slow, but ongoing process in the formal
methods community. It can take many years from when a notation is created until it is
adopted in industry. Possibly the biggest challenge in applying formal methods to real-time
embedded systems is choosing an appropriate technique to match the problem. Still, to
make formal models usable by a wide spectrum of people, requirement documents should
use one or more nonmathematical notations, such as natural language, structured text, or
diagrams.
5.1.6 Finite State Machines
The finite state automaton (FSA), finite state machine (FSM), or state transition diagram
(STD) is a formal mathematical model used in the specification and design of a wide range
of systems. Intuitively, finite state machines rely on the fact that many systems can be
represented by a fixed number of unique states. The system may change state depending on
time or the occurrence of specific events, a fact that is reflected in the automaton.
A finite state machine can be specified in diagrammatic, set-theoretic, and matrix
representations.
Finite state machines are easy to develop, and code can be easily generated using tables to
represent the transitions between states. They are also unambiguous, since they can be
represented with a formal mathematical description. In addition, concurrency can be
depicted by using multiple machines. Because mathematical techniques for reducing the
number of states exist, programs based on FSMs can be formally optimized. A rich theory
surrounds finite state machines, and this can be exploited in the development of system
specifications. On the other hand, the major disadvantage of FSMs is that the internal
aspects or insideness of modules cannot be depicted. That is, there is no way to indicate
how functions can be broken down into subfunctions. In addition, intertask communication
for multiple FSMs is difficult to depict. Finally, depending on the system and alphabet
used, the number of states can grow very large. Both of these problems, however, can be
overcome through the use of statecharts.
5.1.7 Statecharts
Statecharts combine finite state machine with data diagrams and a feature called broadcast
communication in a way that can depict synchronous and asynchronous operations.
Statecharts can be described succinctly as statecharts = FSM + depth + orthogonality +
broadcast communication (figure 5). Here FSM is a finite state machine, depth represents
levels of detail, orthogonality represents the existence of separate tasks, and broadcast
communication is a method for allowing different orthogonal processes to react to the
same event. The statechart resembles a finite state machine where each state can contain its
own FSM that describes its behavior. The various components of the statechart are
depicted as follows:

79
1. The FSM is represented in the usual way, with capital letters or descriptive phrases
used to label the states.
2. Depth is represented by the insideness of states.
3. Broadcast communications are represented by labeled arrows, in the same way as
FSMs.
4. Orthogonality is represented by dashed lines separating states.
5. Symbols a, b,, z represent events that trigger transitions, in the same way that
transitions are represented in FSMs.
6. Small letters within parentheses represent conditions that must be true for the
transitions to occur.
A significant feature of statecharts is the encouragement of top-down design of a module.
For example, for any module (represented like a state in an FSM), increasing detail is
depicted as states internal to it. In Figure 5 the system is composed of states A and B. Each
of these in turn can be decomposed into states A1, A2, and B1 and B2, respectively, which
might represent program modules. Those states can also be decomposed, and so forth. To
the software designer, each nested substate within a state represents a procedure within a
procedure. Orthogonality depicts concurrency in the system for processes that run in
isolation, called AND states. Orthogonality is represented by dividing the orthogonal
components by dashed lines. For example, if state Y consists of AND components.

Figure 4.5 Statechart format where A and B are states, x is an event that causes the
transition marked by the arrow, y is an optional event triggered by x, and e1, . . . , en are
conditions qualifying the event.


80


Figure 5.6 A statechart depicting insideness.

A and D, Y is called the orthogonal product of A and D. If Y is entered from the outside
(without any additional information), then the states A and D are entered simultaneously.
Communication between the AND states can be achieved through global memory, whereas
synchronization can be achieved through a capability of statecharts called broadcast
communication.
Broadcast communication is depicted by the transition of orthogonal states based on the
same event. For example, if the inertial measurement system switches from standby to
ready mode, an event indicated by an interrupt can cause a state change in several
processes. Another unique aspect of broadcast communication is the concept of the chain
reaction; that is, events triggering other events. The implementation follows from the fact
that statecharts can be viewed as an extension of Mealy machines, and output events can be
attached to the triggering event. In contrast with the Mealy machine, however, the output is
not seen by the outside world; instead it affects the behavior of an orthogonal component.
For example, in Figure 4.7 suppose there exists a transition labeled e/f, and if event e
occurs then event f is immediately activated. Event f could, in turn, trigger a transaction
such as f/g. The length of a chain reaction is the number of transitions triggered by the first
event. Chain reactions are assumed to occur instantaneously. In this system a chain
reaction of length 2 will occur when the e/f transition occurs. As a further example, Figure
5 found in the Case Study in Section 4.10 illustrates a statechart corresponding to the
traffic intersection control system.

81


Figure 4.7 Statechart depicting a chain reaction.

Statecharts are excellent for representing embedded systems because they can easily depict
concurrency while preserving modularity. In addition, the concept of broadcast
communication allows for easy intertask.
In summary, the statechart combines the best of data flow diagrams and finite state
machines. Finally, commercial products allow an engineer to graphically design a real-time
system using statecharts, perform detailed simulation analysis, and generate Ada, C or Java
code. Furthermore Statecharts can be used in conjunction with both structured and object-
oriented analysis.
5.1.8 Object-Oriented Anaysis and the Unified Modelling Language
There are various flavors of object-oriented analysis, each using its own toolsets. In the
approach developed here, the system specification begins with the representation of
externally accessible functionality as use cases.
Object-oriented programming uses a structure of collaborating objects, in which each part
performs its specialized processing by reacting to inputs from its immediate neighbors.
The use of object-oriented approaches in real-time systems modeling provides several
advantages including understandability and maintainability, modularity of design,
concurrency, distributivity, and improved management of complexity, enhanced reuse,
increased extensibility, and excellent traceability.
5.1.9 Use Cases
Use cases are an essential artifact in object-oriented analysis and design (OOAD) and are
described graphically using any of several techniques. The use-case diagram can be
considered analogous to the context diagram in structured analysis in that it represents the
interactions of the software system with its external environment. In the specification of an
embedded system this is also where overall time constraints, sampling rates, and deadlines
are specified.
Use cases are represented graphically as ellipses, with the actors involved represented by
stick figures, as can be seen in Figure 5.15.

82


Figure 4.15 Use-case diagram for the inertial measurement system.

The lines drawn from the actor to the use case represent the communication between them.
Each use case is, however, a document that describes scenarios of operation of the system
under consideration as well as pre-and postconditions, and exceptions. In an iterative-
development lifecycle these use cases will become increasingly refined and detailed as the
analysis and design workflows progress. Interaction diagrams are then created to describe
the behaviors defined by each use case.
In the first iteration these diagrams depict the system as a black box, but once domain
modeling has been completed, the black box is transformed into a collaboration of objects,
as will be seen later. As a final example, Figure 3 in the Case Study in Section 4.10
illustrates the use case diagram for the traffic intersection control system.
5.1.10 Class diagram
An analysis class diagram presents the static structure of the system, system abstractions,
and their relationships. It contains classes that represent entities with common
characteristics, including attributes and operations and associations that represent
relationships between classes. The classes are represented by rectangles and the connection
paths represent associations between classes. Classes require a name within the rectangle,
whereas associations may not have an attached name. The diamond attachment represents
an aggregation relationship. If the diamond is filled, it is a dependent aggregation,
otherwise it is independent, that is, the objects so aggregated can exist separately. Figure 4

83
in the Case Study in Section 4.10 illustrates an analysis class diagram for the traffic
intersection control system.
5.1.11 Recommendations on Specification Approach for Real-Time
Systems
The preceding discussions illustrate some of the challenges (in fact, one might consider
them habits) encountered by engineers specifying real-time systems:
- Mixing of operational and descriptive specifications.
- Combining low-level hardware functionality and high-level systems and software
functionality in the same functional level.
- Omission of timing information.
It is risky to prescribe a preferred technique, because it is well known that there is no
silver bullet when it comes to software specification and design, and each system should
be considered on its own merits. Nevertheless, irrespective of the approach, real-time
system modeling should incorporate the following best practices:

- Use consistent modeling approaches and techniques throughout the specification,
for example, a top-down decomposition, structures, or object-oriented approaches.
- Separate operational specification from descriptive behavior.
- Use consistent levels of abstraction within models and conformance between levels
of refinement across models.
- Model nonfunctional requirements as a part of the specification models, in
particular, timing properties.
- Omit hardware and software assignment in the specification (another aspect of
design rather than specification).
5.1.12 Organizing the Requirements Document
There are many ways to organize the SRS, but IEEE Standard 830-1998 is the IEEEs
Recommended Practice for Software Requirements Specifications (SRS) [IEEE98], and
provides a template of what an SRS should look like. The SRS is described as a binding
contract among designers, programmers, customers, and testers, and it encompasses
different design views or paradigms for system design. The recommended design views
include some combination of decomposition, dependency, interface, and detail
descriptions. Together with boilerplate front matter, these form a standard template for
software requirements specifications, which is depicted in Figure 4.16. Sections 1 and 2 are
self-evident; they provide front matter and introductory material for the SRS. The
remainder of the SRS is devoted to the four description sections. The section headings can
be broken down further using a technique such as structured analysis. The IEEE 830
standard provides for several alternative means to represent the requirements
specifications, aside from a function perspective. In particular, the software requirements
can be organized by
- Functional mode (for example, operational, diagnostic, calibration).
- User class (for example, operator, diagnostic).
- Object.
- Feature (what the system provides to the user).
- Stimulus (e.g. sensor 1,2, and so forth).

84
- Functional hierarchy.
- Mixed (combining two or more of the preceding).


















Figure 4.16 Recommended table of contents for an SRS from IEEE Standard 830-1998
[IEEE830].
5.1.13 Organizing and Writing Requirements
The text structure of the SRS can be depicted by the number of statement identifiers at
each hierarchical level. High-level requirements rarely have numbered statements below a
depth of four (e.g., 3.2.1.5). Well-organized documents have a pyramidal structure to the
requirements. Requirements with an hourglass structure mean too many administrative
details. Diamond structured requirements indicate subjects introduced at higher levels were
addressed at different levels of detail (Figure 4.17). Whatever approach is used in
organizing the SRS, the IEEE 830 standard describes the characteristics of good
requirements. That is, good requirements must be

1. Correct: They must correctly describe the system behavior.
2. Unambiguous: The requirements must be clear, not subject to different
interpretations.
3. Complete: There must be no missing requirements. Ordinarily, the note TBD [to be
defined later] is unacceptable in a requirements document. IEEE 830 sets out some
exceptions to this rule.
4. Consistent: One requirement must not contradict another. Consistency can be
checked using formal methods, as illustrated previously.
5. Ranqued for importance and/or stability: Not every requirement is as critical as
another. By ranking the requirements, designers will find guidance in making trade-
off decisions.
6. Verifiable: A requirement that cannot be verified is a requirement that cannot be
shown to have been met.
7. Modifiable: The requirements need to be written in such a way so as to be easy to
change. In many ways, this approach is similar to the information-hiding principle.
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definition and Acronyms
1.4. References
1.5. Overview
2. Overall Description
2.1. Product Perspective
2.2. Product Functions
2.3. User Characteristics
2.4. Cronstraints
2.5. Assumptions and Dependencies
3. Specific Requirements
Appendices
Index

85
8. Traceable: The benefist of traceability cannot be overstated. The requirements
provide the starting point for the traceability chain. Numbering the requirements in
hierarchical fashion can aid in this regard.

Figure 4.17 Triangle-, hourglass-, and diamond-shaped requirements configurations.

To meet these criteria and to write clear requirements documentation, there are several best
practices that the requirements engineer can follow. These are as follows:
- Invent and use a standard format and use it for all requirements.
- Use language in a consistent way.
- Use shall for mandatory requirements.
- Use should for desieable requirements.
- Use text highlighting to identify key parts of the requirement.
- Avoid the use of technical language unless it is warranted.
5.1.14 Requirements Validation and Review
Verification of the software product means ensuring that the software is conforming to the
SRS. Verification is akin to asking the question Am I building the software right? in that
it requires satisfaction of requirements.
Requirements validation, on the other hand, is tantamount to asking the question Am I
building the right software? Too often, software engineers deliver a system that conforms
to the SRS, only to discover that it is not what the customer really wanted.
Performing requirements validation involves checking the following:

1. Validity, that is, does the system provide the functions that best support the
customers needs?
2. Consistency, that is, are there any requirements conflicts?
3. Completeness, in other words, are all functions required by the customer included?
4. Realism, or, can the requirements be implemented given available budget and
technology?
5. Verifiability, that is can requirements be checked?
5.1.15 Requirements Validation Using Model Checking
Model checking is a formal method that can be used to perform analysis of requirements
specifications, even partial ones. The aim, however, is to find errors, not prove correctness.

86
One methodology uses state machines to test for safety and liveness. The first step involves
building a state model of the system, for example, using statecharts.
Once this initial model is obtained, the state space size is estimated in order to assess the
potential for automated validation. Next, the state space is reduced by identifying
equivalence classes and by exploiting symmetries and subclasses. Finally, a symbolic
representation of the main features of the requirements is derived. This representation
represents a behavioral, temporal logic TCTL that emulates the coarse-grain behavior of
the system. To check for fault-tolerance, faults are injected into the live model and this
model is exercised to identify problems. Model checking represents, in some ways, a very
high-level prototype of the requirements.

5.1.16 Formal Verification TCTL, Evaluation of Each Node and
Code Generation
We present a real-time extension of UML statecharts to enable modeling and verification
of real-time constraints. For clarity, we shall consider a reasonable subset of the rich UML
statechart model and extend it with real-time constructs (clocks, timed guards, invariants
and real-time tasks). We have developed a rule-based formal semantics for the obtained
formalism, called hierarchical timed automata (HTA). To use the existing tool UPPAAL
for formal verification, HTA are translated to enriched timed automata model.
We report on an XML based implementation of the translation from HTA to a network of
timed automata and present an example to illustrate our technique and report run-time data
for the formal verification part.
5.1.16.1 Introduction
In this subsection, we briefly discuss two recent developments that are aimed to adopt the
Uppaal tool [93] towards UML statechart compability.
First, we propose a timed version of the UML statecharts model appropriate for high-level
design and analysis of real-time systems. The model has a simple and clear semantics, and
is powerful enough to describe the characteristic features of real-time systems, such as
scheduling algorithms, timers, timeouts, continuous behaviors, etc. We refer to the
formalism as hierarchical timed automata (HTA). HTA are defined from a subset of UML
statecharts extended with clocks, integer variables, and channel synchronizations. In the
next section, we present the chosen UML subset and the real-time extensions. We also
outline the formal syntax and semantics of HTA.

Secondly, we present a model called executable timed automata as an extension of timed
automata allowing code synthesis. Most commercial real-time tools provide a code
generation capability. However the translation is often done process by process without
taking allocated resources such as total CPU utilization into account. For the proposed
model of executable timed automata we are able to synthesize code with predictable timing
behavior.
The overall goal is a uniform framework for modeling, analysis, and code synthesis of real-
time systems. Figure 6.1 illustrates the current position of the Uppaal tool in the context of
UML. The tools exchange data through a XML/XMI interface mechanism. The UML tools

87
need a translation for compatibility with the specific formalism used. Then simulation,
verification, debugging with trace analysis, and ultimately code synthesis are carried out.
5.1.16.2 Hierarchical Timed Automata
Our HTA is essentially a subset of UML statecharts extended with real-time constructs.
States are either basic or composed of state machines themselves. Transitions are guarded,
can entail synchronization, and update local or global variables. For the real-time aspects,
clocks, invariants, and timed guards are added. In the following, we describe in some more
detail, the chosen subset of UML statecharts and the real-time extensions.
UML tool format UPPAAL format

UML Timed
UPPAAL

Model automata
Simulator

XML XML


Translator
Trace Trace
Verifier

Example example

Requirements
Properties
Code generation



Java
Figure 6.1: Modeling, analysis, and code synthesis
framework.


Statecharts Subset. The UML statecharts subset is a hierarchically organized state
machine with XOR states, AND states and basic states. XOR and AND states are the
building blocks of the state hierarchy. They contain other sub states. In XOR states, sub
states are related to each other by exclusive-or", i.e. in an active XOR state exactly one
sub state is active at a time. In an active AND states, all sub states are active, i.e., they run
in parallel. AND states cannot have basic sub states. Note that the set of active states is a
dynamic property of the system.

In HTA we do not allow transitions crossing hierarchy levels as in UML statecharts.
Instead we always use explicit entry and exit points represented as UML stubs. This makes
it easier to give a clear semantics and perform formal analysis. However, this does not
have to hinder designers since a sufficiently advanced editor can provide UML facilities by
keeping the explicit representation internally. Furthermore, since every legal UML model
has a corresponding representation in the HTA notation, we do not restrict the
expressiveness.

HTA include shallow history as a special entry. Deep history is not addressed explicitly,
since it is straight forward to encode deep history using shallow history. Parallel
components communicate via CCS style handshaking synchronizations [94]. The more
general event model of UML can be encoded via broadcast communication which will be
supported in the near future.

Real-Time Extensions. We equip our HTA model with clocks, invariants, and urgency to
capture real-time behavior. Clocks are real-valued variables that increase their values
synchronously (i.e. at the same rate) whenever time elapses. All clocks start with the initial

88
value 0 and may be reset to 0 along transitions. This extension is influenced strongly by the
timed automata model [95] that has been studied thoroughly in the literature and has been
successfully applied in formal verification.

Invariants are boolean expressions that can be associated to states and are used to enforce
progress. They must evaluate to true as long as the state is active, i.e. the state must be left
before the invariant evaluates to false. This notion of progress is expressive enough to
imitate the run-to-completion step concept of UML statecharts.

Urgency is a concept that gives priority to actions over time delay. We propose to use this
as a property of transitions. If urgent transition is enabled, no time delay is possible, i.e.,
the next step is an action step.

Formal Semantics of HTA. The complete formal syntax and semantics are defined in [96].
We give a brief sketch. Semantics is based on the configuration vector that is a
snapshot of the system.

captures the control location. It is a partial version of

gives the valuation of the local integers of a state.

gives
the real valuation of the clocks visible at a given state. reflects the history and has a state
and a variable component.
The semantics is then defined in term of a configuration vector transformation

that performs a join, a transition, and a fork. We give here two of the rules:

action

delay

All the work resides in defining the predicates TransitionEnabled, UrgentEnabled, and Inv
that evaluate when a given transition is enabled with respect to a cascade join-transition-
fork, when urgent transitions are enabled with respect to synchronizations between
transitions, and when invariants are enabled.

5.1.16.3 Case Study: Traffic Light Controller
We have implemented a translator from HTA to UPPAAL timed automata to experiment
with formal verification of HTA and to compare the sizes between a HTA and its
corresponding representation as timed automata. The modeled system is the Traffic Light
Controller (for more details see chapter 7). Using the implemented translation, we have
been able to check a number of safety and liveness properties of the system, indicating that
formal verification of HTA is indeed feasible.

5.1.16.4 Code Generation
We are approaching a situation where the UPPAAL tool can manage imported UML
statechart models represented as HTA. Code generation from UPPAAL models by means
of higher level concepts is work in progress. This opens a way to perform code generation
and formal verification in the same framework. Preliminary experiments are encouraging.

89

Part Two: Distributed Simulation Based in the HLA Standard for
use with the J-Sim Simulation Library
5.1.17 Requirements to Solution
The main requirement to implement support for the library HLA J-Sim is the emergence
such a system, which is the maximum compatible with earlier versions of the library non -
distributed J-Sim.

Another requirement is that library users of J-Sim were able to propose Distributed
simulation even if they have no deep knowledge about the HLA. Practically, this means
that the use of distributed simulation may be too complicated. This requirement should be
met not only for the design of the "new" distributed simulation, but also for the possible
change of non-distributed simulation to a distributed (and vice versa).

It is also worth mentioning that support HLA already been implemented in the simulation
library of C-Sim. Apparently it would be advisable that the solutions for J-Sim user
externally offered the same opportunities and conditions as previously implemented
solutions for the C-Sim, although it is clear that implementation will be quite significant
differences.
5.1.18 Principle solutions
Each discrete simulation drafted using J-Sim simulation requires the existence of an object
- instance of a class JSimSimulation. All processes (and similarly the queue), that
participate in this simulation, must have as its parent reference to the simulation object. In
one program, typically there is one simulation object that "lives its own life and not
cooperate with other simulation objects.

Distributed simulation technology cooperates between the different simulations, which are
simultaneously performed on multiple processors or computer. These computers are for
cooperation interconnected by computer network. Individual computers on which
simulation is running can be located in geographically different locations.

Distributed simulation with a simulation library using J-Sim, therefore means that there are
more instances (generally located on multiple computers) Class-JSim Simulation, which
are able to work together certain ways. Necessary condition for ensuring cooperation of
individual participants is the ability of interaction between the individual simulations.
Practically, this means that every J-Sim simulations involved in distributed simulation,
should be able to work not only with their own processes (ie processes, on which are
created simulations indicated that, like their parents), but also with other simulation
processes Objects in distributed simulation. Besides the process should be able to similarly
work with queues (or with other objects) of other participants distributed simulation.

90
From the perspective of HLA distributed simulation can be regarded as a Federation.
Members this federation, individual J-Sim simulation, which will be distributed simulation
participate. Everyone simulacnmu building will therefore be assigned to just one member
of the Federation. The members of the Federation, before the start of simulation can join a
federation, during a simulation to communicate with other members of the Federation and
after the simulation leaves the federation. HLA Standard requires members of a federation
together did not respond directly but only through the services of Runtime Infrastructure
(RTI).

Each simulation object during the simulation are still responsible for his custom objects
(processes, queues). These objects will be referred to as local objects. Objects that are
located in another member of the Federation (and therefore have as their parent in any
other simulation object) are called as remote objects (remote objects).

If some local building needs to take some action over other local objects (eg scheduled
argument in another process simulation), their co-operation is performed the same way as
nedistribuovane simulation. From the perspective of the Java programming language is
merely the method called in another object.

Another situation occurs when that local object to cooperate with the object,
who is from the perspective of the first object to remote object. An example of such a
situation it may be scheduled on a remote process. Such a requirement is necessary to
deliver the first member of the Federation, in which the building is like a local.
Requirements to recipient then sends the original response object, which contains
information on compliance with its requirements (or information about the error occurred).
To send and take all the communication should be used the services in RTI.

Clearly, the members of the federation to occur in the moment when one member of the
Federation of operations required to be performed with the object of another member of the
Federation. It means that the simulation can be used event-driven. , To guarantee the
causality every event bear a time stamp. Individual members of the federation can not
move the simulation time arbitrary, but always with the consent of RTI. According to HLA
One of the conservative Federation synchronized.
5.1.19 Communication protocol members of the Federation
Proposal for a communication protocol based on the Federation sets library services J-Sim,
which you can call the remote object. On a per-call services of the remote object is
generally regarded as a requirement. According to the type of requirement may be,
together with the identification requirements passed a number of arguments. An example
could be to require scheduled remote process, where the argument is the time to plan
requirements process.is the time to plan the process.

Some of the services J-Sim Returns the result of definite data type, other service returned
no data (relevant method has a return type of void). Since the method of service will be

91
called a member of the Federation, calling members of the Federation needs to acquire at
least, whether the services can take place properly or whether there has been an error
(exception occurred). This implies that communication between members of the
Federation, any service J-Sim must return any result. This result can be considered answers
that are required. The proposed protocol therefore typically will use a schema request -
response.

Overview of all services J-Sim (including the data request and response) that use the
communication protocol members of the Federation, is given below:

Class Service Data required Data responce
JsimProcess activate
cancel
getState
isIdle
double
-
-
-
-
-
int
boolean
JsimHead empty
cardinal
first
last
getLw
getTw
getTwForAllLinks

-
-
-
-
-
-
-
boolean
long
JSimLink
JSimLink
double
double
double
JSimLink into JSimLink -

The table does not set dates, which are common to all the requirements (Or answers). This
is particularly the object name (eg name of the process)over which the requested service is
performed and some additional information needed to identify the request (response). This
data will be included in the request header (or answers). Structure of the request header and
the answers will be described in the following paragraph.
5.1.19.1 Design FED file for RTI
Each Federation is described FED file, which is common to all members Federation.
Implementation of RTI requires this file for the federation. FED file contains definitions of
object classes and interactions, which are used by individual members of the federation to
communicate.
Members of the Federation of J-Sim for service request and response exploiting classes
interactions (similar to the solutions for the C-Sim). Every interaction may include
parameters. Specifications Fed renders it impossible to set the data type parameter,
interpretation of the parameter depends on the simulation programmer. Each class of
interaction can propose different ways. One option is to establish for each type of queries
(answers) a separate class of interaction with the parameters that correspond to the date of
queries (responses). Such a FED file would contain a relatively large number of classes to
interact with different parameters. Another option is to partition requirements (responses)
into several categories

92
Criteria for the distribution requirements in the category may be a data type parameter or
type of service requirement is performed (this proposal uses the solution for the C-Sim).
For J-Sim also offers the possibility of sharing requirements according to the class, the
requirement that works. This would suggest a class of interaction for the requirements of
the process, another for the front and the front elements. Another class of interaction would
be incurred for responding to.

When designing a solution for J-Sim was finally chosen other variant, which allowed Use
fewer interaction classes. This implies some simplification FED file and also a smaller
number of classes, which members of J-Sim Federation has ordered (subscribe) and
publish (publish). FED file defines only three new interaction classes:

- JSimRequest requirement. Has two parameters: the header (request header) and
data (data requirements).

- JSimResponse response to a request. Requirement is similar to two parameters:
the header (response header) and data (data response).

- JSimEndOfSimulation report of the end of the simulation.

Request header is required - this means that when a request is to be completed. Header
contains the following data: identification of the sender (handle member federation), the
object name (eg name of the process) and identify the service (eg scheduled process). Type
of data requirements depend on whether they are having the desired services related to an
argument and what type they are. If the desired services are not linked to any arguments,
the data requirements to be left blank.

Response header is required and contains the sender identification requirements identify
the sender and the finding of answers service. Data type answers depends on what data is
returned to the called service. For example for identifying features such as length cardinal()
queue returns type long. If calling service does not return a value reply data will remain
unfilled.

The following listing contains part of the draft FED file for J-Sim (listing is truncated only
the part that defines a class of interaction for the J-Sim):

(class JSimRequest reliable timestamp
(parameter header)
(parameter data)
)
(class JSimResponse reliable timestamp
(parameter header)
(parameter data)
)
(class JSimEndOfSimulation reliable timestamp
(parameter data)
)
Interaction of the J-Sim is defined as a reliable, which means that the RTI guarantee receipt
of each interaction and at the same time as the timestamp, which allows delivered in the
order of interaction time stamps. Designed FED file remains same for all distributed J-Sim

93
simulation. FED file format supports all products RTI that implements the HLA 1.3.
interface specification. J-Sim library are working with the implementation of the
Extensible Runtime Infrastructure (XRTI), which instead of the FED file to use files FDD.
Design FDD file will be described in the following paragraph.
5.1.19.2 Design FDD file for XRTI
XRTI implementation, which is used with J-Sim implements the HLA Interface
specification 1516.1. This version is replaced by the previously used HLA FED format
standard XML format. Files with the federation object model in XML format are referred
to as FDD (FOM Document Data). FDD file is in a subdirectory of the distribution
resources XRTI.
XRTI allows the use of data type for an attribute of object class parameter of interaction in
the FDD file. Interpretation of the parameter at the discretion of programmer, of course,
remains unchanged - the interaction parameter is sufficient to note datatype =
"HLAopaqueData.
FDD file for J-Sim can be created by overwriting the FED file to XML. FDD proposal was
set for the J-Sim is listed in the following listing:

<?xml version="1.0"?>
<objectModel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="HLA.xsd"
DTDversion="1516.2"
name="JSim Object Model"
type="FOM"
version="1.0">

<objects>
<objectClass name="HLAobjectRoot"
sharing="Neither">
...
</objectClass>
</objects>

<interactions>
<interactionClass name="HLAinteractionRoot"
sharing="Neither"
dimensions="NA"
transportation="HLAreliable"
order="Receive">

<!-- Interaction classes for J-Sim -->

<interactionClass name="JSimRequest"
sharing="PublishSubscribe"
dimensions="NA"
transportation="HLAreliable"
order="TimeStamp"
semantics="JSim Request">
<parameter name="header"
dataType="HLAopaqueData"
semantics=""/>
<parameter name="data"

94
dataType="HLAopaqueData"
semantics=""/>
</interactionClass> <!-- JSimRequest -->
...
</interactionClass>
</interactions>

Statement has been reduced significantly. The complete document can be found in the file
JSimObjectModel.xml directory of resources / en / ZCU / fav / KIV / jsim distribution
XRTI.
5.1.20 Implementation of the Solution
5.1.20.1 Class JSimHLASimulation
Trida JSimHLASimulation floor to the newly created package cz.zcu.fav.kiv.jsim.hla. Is
derived from the class JSimSimulation and extends the capabilities of the superclass the
possibility of using distributed simulation. Constructor of this class a simulation, named
after the value parameter name (as in ancestor classes). In addition to the parameter name
has a constructor two other parameters:

public JSimHLASimulation(String name,
Properties configurationRTI,
int numberOfFederates)
throws JSimInvalidParametersException

parameter configurationRTI allows you to enter configuration parameters for the
implementation RTI. For most simulations can only be given new Properties () out of the
box, which means that it uses the default values. Integer numberOfFederates parameter
indicates the number of members of the Federation who will participate in distributed
simulation. Rameter less than two makes no sense, and attempts to enter such values will
thrown exceptions.
When specifying the number of members of the Federation is important to note that setting
this values can be done only by a member federation that created the federation. This
member federations will then wait for a connection specified number of members of the
Federation. Perhaps attempts to enter different values for the federation is no longer on the
federation no influence. Given that the code of individual members of the Federation can
be run simultaneously on multiple computers, you can not be determined in advance which
member Federation of the value actually set. For this reason, that for all participants of the
distributed simulation was given the same value.

In addition to set the name and number of members simulation federation still full of
constructor two important tasks. The first one is to set the attribute value simulationHLA
true. This attribute affects the behavior of the method step() when using distributed
simulation. The second task is to create class instance JSimHLAConnection. This class
provide interconnection between the J-Sim and RTI.

JSimHLASimulation class provides the user with two important methods:

- beginFederationExecution() - Federation launches performed for the J-Sim.
Must be called after creating all local and remote simulation facility and before the

95
first call to a method step (). The method merely calls the method
beginFederationExecution () class instance JSimHLAConnection.

- endFederationExecution() - Ends pursued Federation for J-Sim. Must be called
after the last call to a method step (). The method merely calls the method
endFederationExecution () class instance JSimHLAConnection.

JSimHLASimulation class contains a few more methods that the user simulation
not need to call directly. The significance of such methods will be explained in the
description of classes that call these methods. If these methods are called only from
other classes like-packages are marked as protected. However, certain methods must be
accessible from other packages (eg for class JSimSimulation), and therefore they are
marked as public, although he never had to call the user. The user is warned that the
documentary commentary method.
5.1.20.2 Class JSimHLARemoteProcess
JSimHLARemoteProcess class represents a distant process. This process exists as an
instance of a class JSimProcess (or instance of a descendant of JSimProcess) in the
simulation program, another member of the Federation.

public JSimHLARemoteProcess(String name, JSimHLASimulation
parent)
throws JSimInvalidParametersException,
JSimSimulationAlreadyTerminatedException

JSimHLARemoteProcess class constructor requires you to enter the same parameters
JSimProcess a class constructor. The difference is in the data type parameter, parent, that
requires a reference to an instance of class instead JSimHLASimulation JSim-Simulation.

Each remote process automatically when you create the index with its parent process
distant object simulation. To do this method addProcess() class instance
JSimHLASimulation.

Class instance JSimHLARemoteProcess offers users the following methods:

- actvate() - distant scheduling process to the desired time.
- cancel() - cancel any pending remote process.
- isIdel() - determine whether distant process can be scheduled.
- getState() - determine the status of a remote process.

Methods distant process returns the same result as the method of local processes. In case of
error also throws the same exception. Use all of the above methods from a user's
perspective is exactly the same as using the same class method named JSimProcess.
5.1.20.3 Calss JSimHLARemoteHead
JSimHLARemoteHead class represents a remote queue. This queue exists as an instance of
a class in the simulation program JSimHead another member of the federation.


96
JSimHLARemoteHead class constructor requires the same parameters as the constructor
JSimHead class. The only difference is the parent parameter, which is the type of place
JSimHLASimulation JSimSimulation.

Similarly as a remote process remotely queue automatically when you create the index
distant front of their parent object of the simulation. To do this method addQueue () class
instance JSimHLASimulation.
Class instance JSimHLARemoteHead offers users the following methods:
- empty() test whether the remote queue is empty.
- cardinal() returns the number of elements in the remote queue.
- first() returns the first element of the distant front.
- last() returns the last element of the distant front.
- getLw() returns expectancy distant front.
- getTw() returns mean time waiting in a remote queue for all elements, which
were removed from the queue.
- getTwAllLinks() returns the mean time waiting in the remote queue for all
elements that were inserted into the queue.

All methods distant queue returns the same result as the method of ordinary (local) queues.
Simulation user can thus use those methods in the same way as it has used the same class
method named JSimHead.
5.1.20.4 Classes JSimHLArequest, JSimHLARequestHeader
JSimHLARequest class represents a requirement which class JSimHLAConnection used to
communicate with the RTI. Each requirement consists of the mandatory header type
JSimHLARequestHeader and data requirements of type Object. JSimHLARequestHeader
class attributes are deliberately marked as public, because the class is used only as an
analogy to the type of record (or structure, such as struct in C). Header each requirement
shall include the following:
- int requestSender integer handle member federation, which sent the requirement.
- String objectName J-Sim name of the object. Medium: J-Sim will be done on an
object with that name.
- int serviceCode Code J-Sim services (eg scheduled process). This service will be
performed by the above mentioned object.

Data sent with the request (with answers) can be generally different types. This means that
before sending the data requirement should be adequately "Wrap" Upon receipt
requirements and translate them into original shape. For this purpose, can use a mechanism
called object serialization, which is directly supported by Java. Object class, which will be
serialized must implement interface java.io.Serializable. It must also support the
serialization of all non-static objects, which class reference. Implementation of Serializable
interface does not represent complex because the interface contains no methods. One is
called marked interface (tag interface), the methods of implementing serialization only
indicates that hinder serialization. Or trying to serialize object, which does not support this
interface, end up throwing exceptions NotSerializableException.

When serialized object will automatically store the value of any attributes that are declared
as primitive data types (eg int). Interfaces Serializable is also implemented in classes that
wraps the primitive data types (eg double) and the class String. Object serialization can be

97
done by calling methods writeObject () class ObjectOutputStream. The method has one
argument type Object. Serialization process illustrated by the following code snippet:

byte[] values = null;

ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);

oos.writeObject(object);
oos.close();

values = baos.toByteArray();

After the execution of this code is the content object stored in an array of type byte [].
Obtained fields can be used as a parameter interaction, sent sendInteraction method ().
Upon delivery of the interaction from a field to regain the original object (after proper
casting).

To submit an inquiry would be advantageous to allow serializable header and possible data
requirements. From the above mentioned types of class attributes JSimHLARequestHeader
is obvious that the heads can serialize (Of course, it is necessary noted that the class
implements the Serializable interface). It therefore remains to solve the serialization of data
requirements. Looking at the table of the communication protocol with members of the
Federation can make sure that all of the data and answers floor between the data types that
can be serialized.
5.1.20.5 Classes JSimHLAresponse, JSimHLARespenseHeader
JSimHLAResponse class represents a reply, used for communication between
JSimHLAConnection class and RTI. Requirement similar to the response consists from
mandatory header type JSimHLAResponseHeader and give an answer of type Object.
Response header must contain the following:

- int requestSender integer handle member federation, which sent the requirement.
Members of the Federation, who is waiting for a reply, you must compare the value
with the value you noted in your request. If this was not matched implemented,
could result as the operation be taken replies was intended for another member of
the Federation.

- int responseSender integer handle members of the federation, who sent a reply.

- int errorCode result of the operation. If the service was performed without an
error occurs, it returns a value JSIM_RESULT_OK, otherwise
JSIM_RESULT_EXCEPTION.

According to the type of class attributes JSimHLAResponseHeader is obvious that header
can serialize (of course it should be noted that the class implements an interface
Serializable). Similar to the data requirement can serialize data and answers.

98
5.1.20.6 Class JSimHLAReceivedInteractionCallback
JSimHLAReceivedInteractionCallback class encapsulates the data on the interaction of
receipt price from RTI. Instances of this class is created on each call methods
receiveInteraction () class instance JSimHLAConnection. Subsequently stored queue type
JSimHLACallbackQueue to await further processing.
5.1.20.7 Class JSimHLACallbackQueue
This class serves as a front for the service interaction. One is a FIFO queue, which easy to
implement you use the java.util.LinkedList class. Methods for handling with elements of
the queue are marked as synchronized, which provides a safe access to the front in case of
concurrent access from multiple threads. Elements of this queue
JSimHLAReceivedInteractionCallback are instances of the class.
5.1.20.8 Class JSimHLABarrier
JSimHLABarrier class used to create a barrier that can be used at the moment which is
another activity program occurrences of a conditioned event that may be served with other
fibers of the program. Typical uses barrier occurs when calling HLA services, its
implementation has to be confirmed delivery callback from the RTI.

To use the barriers are the most important methods await () and lower (). The first of these
methods starts waiting for an object barrier. The second method will be attained ("throw")
barriers. The implementation of barrier methods are being used to synchronize threads,
which are available for each object in the Java language (as declared in the class Object).
Method await () repeatedly calls the method wait (), which causes the current thread and
waiting for his "awakening". To awaken waiting threads is using notifyAll () is called the
method of lower () in achieving barrier.
5.1.20.9 Class JSimHLAFederateAmbassador
This class implements an interface hla.rti.FederateAmbassador. This interface is part of a
standard HLA and have to be implemented by each member federation, which will use the
services of the HLA. Class implements this interface for the reception of messages from
the RTI callback. An example callback method can be receiveInteraction (), which serves
to receive interactions sent by another member of the Federation. Methods which are
necessary for the ongoing communication from RTI toward J-Sim, just call a class method
named JSimHLAConnection. Other methods are in terms of J-Sim unused and therefore do
not contain any code, but must nevertheless be the class of that code.
5.1.20.10 Class JSimHLAConnection
JSimHLAConnection class provides a link between the J-Sim and RTI. When you create
HLA simulation automatically creates a class instance JSimHLAConnection. User
simulation not need to create instances of this class, either directly call its methods.

Most of the class method is marked JSimHLAConnection access specifier protected
because they are called in chief of the classes and JSimHLASimulation
JSimHLAFederateAmbassador, which is in the same package.

In chapter 5.4.1 it was noted that the method beginFederationExecution () and
endFederationExecution () class instance JSimHLASimulation only just calling a class

99
method named JSimHLAConnection. The first of these task methods is to establish a
connection between the J-Sim and RTI and preparation to carry out the federation.
Second method is terminated for the correct federation and the subsequent closure
connection between the J-Sim and RTI. Activities of these methods will now be described
in detail.
Starting Performed Federation
Method beginFederationExecution () gradually steer several methods that are necessary to
establish a connection between the J-Sim and RTI and prepare to carry out the federation.
All these methods are private because they are used only within his own class.

Method initRTIAmbassador () creates an instance of XRTIAmbassador. This class
implements the interface hla.rti.RTIambassador, that is part of HLA interface. Instances of
this class, named rtiAmbassador will continue used to calling service RTI. After the
successful creation of an object rtiAmbassador is followed by creating a class instance
JSimHLAFederateAmbassador. Instance this class is used for accepting callback from the
RTI. If an instance of rtiAmbassador fail to create, this means that an error has occurred
while initializing RTI interface and implementation of further action is pointless. This error
usually the fact that it failed to establish a network connection application XRTIExecutive,
which serves as a central server for distributed simulation (Or at all, this application is not
running).

Method createFederationExecution () tries to create a federation of J-Sim. Here you must
enter the name Federation and Federation Object Model:

rtiAmbassador.createFederationExecution(
JSIM_FEDERATION_EXECUTION_NAME,
getClass().getResource(JSIM_OBJECT_MODEL)
);
Failure to methods do not necessarily indicate an error. If it is thrown (and subsequently
recorded) FederationExecutionAlreadyExists exception, this means that the Federation has
already established by another member federation and the startup process can proceed. At
this point, the administrator also decides Federation. If you manage to create a federation,
flag isFederationManager will be set to true, otherwise it will be false. Federation Manager
has over other members of the federation in addition certain obligations (and rear right).
Mainly it is the responsibility of the initial collision Federation.

Seeing the J-Sim Federation needs to send and receive TSO messages must be a current
temporary (time constrained) and time-regulating (Time Regulating). Members of the
Federation is a federation or subscribing to regulate or reduced.

This means that services need to call the RTI, which switch on these switches. While the
HLA does not provide a binding order in which they must be surgery done, yet their
implementation, there is some recommendations ([Kuh00] p. 98). This recommendation
says it is on these switches is appropriate to carry out before making publications and
subscribe to the interaction of object classes and attributes. Setting these switches
implementing private methods enableTimeConstrained () and enableTimeRegulation ()
that call the same method on an object named rtiAmbassador.


100
RtiAmbassador.enableTimeConstrained calling services () does not require any arguments.
It remains to be seen to service callback timeConstrained- Enabled (), which confirms that
the time constraints members of the Federation has been activated. While waiting for a
callback from the RTI uses the barrier.

Switches for switching time-regulating, it is necessary to specify lookahead. As previously
mentioned, the members of J-Sim Federation communicate with each way demand - the
answer. Members of the Federation after sending messages with TSO requirements are
always waiting for the delivery of TSO messages with the answers. All members of J-Sim
Federation therefore use a null value lookaheadu and enter the allocation of time calling
services nextMessageRequestAvailable () to be able to send a response to the with the
same timestamp as the one described for adopted requirements. Switched time-regulation
must be upheld RTI callback timeRegulation-Enabled ().

lookahead = new DoubleValuedLogicalTimeInterval(0.0); // zero
lookahead
rtiAmbassador.enableTimeRegulation(lookahead);

PublishAndSubscribe method () will publish and subscribe to interaction classes that were
defined in the object model J-Sim Federation. To use the services of the RTI
publishInteractionClass () and subscribeInteractionClass ().

Members of the Federation, who successfully complete all previous steps it is prepared the
simulation. User simulation thus seemingly nothing to prevent the call to step ().
Distributed simulation technology, however, collaborative simulation and can therefore
begin only after reaching the point at which they are implementing the simulation ready all
members of the Federation. This means that the federation must be connected specified
number of members of the federations and these members must make some way clear of
are ready to start simulation. For this purpose, the mechanism introductory synchronization
Federation.

Members of the Federation, which became manager Federation, because first he is waiting
to mount the required number of members of the Federation. To check the current number
of members monitor Review HLAfederate class object. Update these attributes carried RTI
call callbackove reflectAttributeValues methods (). Federation Manager For each update
class object HLAfederate puts the name into a set of instances (use sets like-occupied
double counting of members of the Federation repeated the update you can not be
excluded). For each update, the program checks whether the number of element sets
reached numberOfFederates. After completion This condition is located in the Federation
required number of members of the Federation, but still can not be assumed that all
members of Federation had already made all the steps needed to start simulation.

Manager Federation subsequently requests the RTI registered synchronization point the
symbolic designation (synchronization point label) start simulation. Them noted that the
synchronization point, although you can sign up before connecting the required number of
members of the Federation, but the initial collision problem can be solved in this way. In
accordance with the HLA RTI announces namely, synchronization points only members of
the federation, which is already connected to the federation, which means that the
subsequently connected to a member of such a notification might be missed.


101
Termination Performed Federation
EndFederationExecution task method () is correct the simulation, unsubscribe members of
the Federation and have finished working with RTI. If the current simulation before it is
finished, the method sendEndOfSimulation () sent to all members of the Federation report
on the simulation.
Called rtiAmbassador.resignFederationExecution () will opt out of the Federation. To be
closed by the federation (which is recommended), the ox also services
destroyFederationExecution (). According to HLA, however, can not cancel the federation
to which they are already connected members. The actual disposal Federation made a
member of the Federation who is logged off last.

Send Request
If members of the federations need to perform the action of the remote object, it must
requirement to deliver member of the Federation, in which the object is as locally. Means
of transmission requirements will be explained in the context, which made a scheduled
remote process.

JSimHLARemoteProcess process3
= new JSimHLARemoteProcess("Process 3", simulation);
...
process3.activate(2.5);

The method activate () remote process, the following code:

public void activate(double when)
throws JSimSecurityException, JSimInvalidParametersException
{
...
response = myParent.getJSimHLAConnection().
sendRequestProcessActivate(myName, when);
responseHeader = response.getHeader();
...

sendRequestProcessActivate() method take the request and make its "wrapped" in class
instance JSimHLARequestHeader. Planned requirement process has one parameter of type
double, which should be transferred to an instance of Double, so that it can pass class
constructor JSimHLARequest, who expects the data type Object. Crafted request is passed
sendRequest() method.

protected JSimHLAResponse sendRequestProcessActivate(
String processName, double when)
{
JSimHLARequestHeader header = new
JSimHLARequestHeader(
federateHandle, processName,
JSIM_PROCESS_ACTIVATE);
Double data = new Double(when);
JSimHLAResponse response = sendRequest(

102
new JSimHLARequest(header, data));
return response;
}

SendRequest method () will serialize request parameter and inserts the parameters (Header
and data) to map the type ParameterHandleValueMap. This map will be transmitted
sendInteraction method () to make outgoing interactions:

rtiAmbassador.sendInteraction(theInteraction,suppliedParamete
rs,new byte[0], logicalTime);

After dispatch to call the waitForResponse (), which is waiting to receive answers to
odeslanemu requirements.

Receipt of the Request
All interactions (and thus the response) are delivered in the form receiveInteraction
callback () instance of JSimHLAFederateAmbassador. Date of service interactions are
subsequently be referred receiveInteraction method () JSimHLAConnection class instance,
which is placed in a queue for further processing. Queue type is
JSimHLAReceivedInteractionCallback.

Processed with the method of interaction delivered processReceived-Interactions (). Order
that the interactions take place as soon as they delivery (otherwise they would a member of
the federation had to wait to answer), it should be called the method of moments, which
follows delivery for possible interactions. Because TSO messages are member of the
Federation delivered only in advancing the state of time (ie prior to the granting of time by
RTI) set this moment after each allocation time from the RTI. Therefore, J-Sim call
method processReceivedInteractions() always after the call-nextMessage
RequestAvailable().

Method processReceivedInteractions () gradually collect interaction from the stack and
performs a simple classification. If the interaction contains a requirement receiveRequest
method is called (). If a response is receiveResponse method call () and to report on the
simulation method receiveEndOfSimulation ().

if (interactionClass.equals(ichJSimRequest))
{
receiveRequest(theParameters);
continue;
}

Method receiveRequest () knows what classes are listed requirement applies and
accordingly it shall be referred for further processing. For example, for a scheduled process
will call a method receiveRequestProcessActivate (). Every request header contains the
name of the object, which is the requirement pertains. For the fulfillment of requirements
must be obtained from such names link to their home object over which the service will be
conducted. To this end, the class JSimHLASimulation following methods:


103
protected JSimProcess getLocalProcessByName(String name)
protected JSimHead getLocalHeadByName(String name)

The first method passes a list of local processes and in the case of finding the process
named to the desired returns a reference to this process. The second method works the
same way over a list of local queues. If the object in that Member Federation does not
exist, it should return NULL (this does not mean a mistake, because object can exist in
another member of the Federation). When it returned a valid link back to their home
destination, can be over such object, call the service requested J-Sim. In the event the
scheduled process is therefore carried out:

process.activate(when);

To complete the remaining processing your request reply. This will be explained below.
Reply Request
If you were at the request of another member federation services performed J-Sim which
returns some data, the data must be returned as part of the responses are sent. To date this
has been possible to easily transfer the parameters of interaction, will use the object
serialization.

If the services performed J-Sim runs successfully, it will be as the result of services
(Attribute ErrorCode response headers) return value JSIM_RESULT_OK. Almost each
service on J-Sim, however, may give an exception. Because the impulse fired The
exceptions were the original request of the remote object, makes no sense thrown
exception in the program members of the Federation, who was a truly executed. An
exception would be advisable to first capture and subsequent information on the incidence
exceptions appropriately send the first member of the Federation, who was an error
informs the user simulation.

One of the way to send information about the thrown exception occurred is the
establishment code
for all exemptions, which can be services of J-Sim fired Results Settings blown answers to
the code of additional exemptions and exception information to date answers. Recipient
answers would subsequently fired such an exception, the code would read out the response
headers. Finally, it was implemented solution using the fact that Java is not possible to
serialize an instance of "Normal" classes, but also exceptions. Serialization exceptions do
not necessitate any changes to the code exceptions to the J-Sim, because interface
Serializable is already implemented class java.lang.Throwable, the common ancestors of
all Java exceptions. J-Sim exceptions are then captured and sent to catch the command as
part of an answer. Thrown exceptions, members of the Federation made the service of the
remote object raised.
Collect Responces
After the request is made in a method sendRequest call:

response = waitForResponse(request);


104
WaitForResponse task method is to wait until delivered to respond to the request
specfikovany parameter. For receipt of responses is necessary to repeatedly enter the RTI
to grant time to the subsequent processing of received interaction:

nextMessageRequestAvailable(logicalTime);
processReceivedInteractions();

Given piece of code is enclosed in a section of synchronized (requestLock). This
guaranteed that the members of the Federation can not send an additional requirement
without delivering the answer to your earlier call. Synchronized to the section has access to
only one thread that is but the "job" waiting for an answer. When calling a method
nextMessageRequestAvailable () to avoid continually communication between federation
and RTI is in a cycle, repeated the call to wait () on object requestLock. If the fibers
delivered while waiting for a reply, the waiting thread "Awakening" call
requestLock.notify ().

Request for Increasing the Time
If a member of J-Sim Federation needs to apply for an allocation of time, call the
nextMessageRequestAvailable () class instance JSimHLAConnection. This method same
name to call a method on an object rtiAmbassador. This member of the Federation in a
state of advancing time in which he delivered to TSO and RO messages from RTI. In this
state, members of the Federation remain until it reaches timeAdvanceGrant callback () that
can tell him now assign a new simulation time. While waiting for the assigned time is used
by instances of the class JSimHLABarrier.

5.1.20.11 Method step() for Distributed Simulation
For proper function of a distributed simulation is necessary to partially modify the
behavior the step() method declared in class JSimSimulation. These modifications must be
made understandable in order to preserve the proper function non distributed simulation.
The step() method can not be covered with a child class JSimHLASimulation, because we
declared it as final. Possible removal keyword final But would not solve the problem too
elegant way, since a substantial part of (rather longer) code method step () would have to
be duplicated in the child class.

For this reason, the class JSimSimulation add attributes simulationHLA A Boolean whose
value affects the behavior of the method step (). The value of this attribute when using
non-distributed simulation is always false, set to true place in the class constructor
JSimHLASimulation.

If the attribute is simulationHLA true, this means that the method step () determine the
behavior change process at startup. This change will be the moment when the calendar is
not empty, which when nedistribuovane simulation gives rise to a first calendar event and
subsequent startup process, which includes this event. And yet set the displacement of
simulation time. When distributed discrete simulation under the HLA is not possible to
move the time any way, but it is necessary to allocate the required time will first ask the
RTI service call nextMessageRequestAvailable (). Argument, this service will be the first
time process in the calendar (the following code stored in a variable-firstProcess Time). In

105
order to pass the time as an argument HLA services, it must be convert to an instance of
type DoubleValuedLogicalTime. Because in actual fact the local time members of the
Federation, this variable called localtime, while time allocated from RTI will be stored in a
variable grantedTime. It is necessary to realize two important facts. Firstly, if another
member federation generates event with timestamp smaller than the required time will be
delivered This event and allocated time will be less than the required time. This means that
members of the Federation in this moment the process started first in the calendar.
Secondly, served event may be a requirement to plan the process over time that is smaller
than the first time yet in the calendar process. In such cases, therefore, change the time of
the first event in the calendar, a process which belongs to this planned events (each process
has no more than one events on the calendar). This process can then be started, as might be
scheduled in the normal way (local member of the Federation). The principle of adaptation
of the method step () illustrates the following section code:

// HLA support code begin
if (simulationHLA)
{
double firstProcessTime;

// grantedTime is the time granted from RTI
DoubleValuedLogicalTime grantedTime;

// localTime is the time of the first event of the
//calendar
DoubleValuedLogicalTime localTime;
grantedTime = (DoubleValuedLogicalTime)
jSimHLAConnection.getLogicalTime();

firstProcessTime = calendar.getFirstProcessTime();
localTime = new DoubleValuedLogicalTime(firstProcessTime);

while (grantedTime.compareTo(localTime) < 0)
{
// We have to ask RTI to advance our logical time.
jSimHLAConnection.nextMessageRequestAvailable(localTime);

// We have to process all events received from other
//federate(s).
jSimHLAConnection.processReceivedInteractions();

grantedTime = (DoubleValuedLogicalTime)
jSimHLAConnection.getLogicalTime();

firstProcessTime = calendar.getFirstProcessTime();
localTime = new DoubleValuedLogicalTime(firstProcessTime);
} // while

// Time of the first process in calendar might have
//changed!!!
//

106
} // if (simulationHLA)
// HLA support code end

time = calendar.getFirstProcessTime();
process = calendar.getFirstProcess();
...

5.1.20.12 Improvement of the classes JsimProcess and JsimHead
That it is possible in the design of distributed simulations can easily change their home
places on the remote (and vice versa), was designed interface and JSimHLAProcess
JSimHLAHead. The user can design simulation processes necessary to declare the stack as
a variable of type interface and subsequently apply irrespective of whether these are local
or remote objects. Transferred to a remote local object can then make a code change only
the location of calls the constructor of the object. JSimProcess calling class constructor (or
a descendant of this class) simply replace the call class constructor
JSimHLARemoteProcess (the process must, of course there is a remote member of the
Federation). The procedure is analogous to the queue.

JSimHLAProcess interface includes methods that may be in the same way for both local
and remote processes. These methods are listed in the methods JSimHLARemoteProcess
class. JSimHLARemoteProcess class already implements the interface JSimHLAProcess.
It therefore remains to ensure that the interface JSim-HLAProcess was implemented still
JSimProcess class. Analogous procedure applies for the class and interface JSimHead
JSimHLAHead. Code editing existing classrooms J-Sim are the following:

JSimProcess implements JSimDisplayable, Comparable,
JSimHLAProcess
...
JSimHead implements JSimDisplayable, Comparable, JSimHLAHead
...

5.1.20.13 Improvement class JSimLink
Class does not support serialization JSimLink, which means that the function J-Sim, which
instance of this class are used as an argument (Into Method ()) or as a return value (the
method first () and last ()), it would be impossible to use for distributed simulation. Were
possible to instantiate this class to serialize, shall be class adding the following code:

JSimLink implements Serializable

In order to include an element to a remote queue, it still needs to overload method into (). It
can follow these steps:

public final void into(JSimHLARemoteHead queue)
throws JSimSecurityException
{
if (myQueue != null)
throw new JSimSecurityException(

107
"JSimLink.into(): Already in a queue.");

queue.linkIntoRemoteHead(this);
} // into
It is obvious that overloads Into () class method only ox-JSimHLARemote Head, who will
take care of delivery to the queue object is located in another member of the Federation.
The team is made necessary adjustments JSimLink classes and features front who seem
nothing to prevent the use of distributed simulation. The problem could arise in case the
user when you create a simulation instance of a class specifies JSimLink so-called user
data. For this purpose, overload the constructor with a parameter type Object. If the class
of user data (or at least one data folder this class) implements Serializable interface, the run
will be distributed simulation (in the first attempt to insert an element into the remote
queue) thrown exception because such an object fails to serialize. Practically, this means
that user data to be used with remote queues, must allow serialization.

Part Three: Modification of software XRTI

XRTI Structure
Before describing the adjustments made XRTI software will be provided information about
major classes of this product. This information is necessary for understanding such
adjustments, as described below. All of the explanations are very brief in any case not
designed to replace documentation XRTI ([Kap03]). It is further noted that a precondition
for understanding XRTI function is not only studied the documentation, but also
thoroughly familiar with the source code ([XRTI]).
5.1.20.14 Class XRTIAmbasador
XRTIAmbassador class is the largest and most important class XRTI. Class implements
the interface hla.rti.RTIambassador, which is part of the HLA interface specification for
Java. To members of the Federation to participate in federation, must create and initialize
an instance of this class. Subsequently, this instance employed for the calling service RTI,
ie, for communication with the members of the Federation of RTI.

Besides creating an instance of class XRTIAmbassador serves also as a superclass for two
important classes: ExecutiveClientAmbassador and FederationExecutionAmbassador.

An important class properties XRTIAmbassador be able to communicate Application
XRTIExecutive. Communication takes place in both directions between instances
XRTIAmbassador class and instance ExecutiveClientAmbassador, which represents a
distant counterpart of every member of the Federation. Crucial importance for this
communication to interact. Interactive classes are used not only in XRTI for sending and
receiving interactions within the meaning of the HLA interaction classes, but as for all
services of the HLA, the performance of which demands the individual members of
federations including all callback, sent from RTI toward a member of the Federation.

Using the interaction of all communication with obvious consequences for the sender and
receiver. For the sender it means that every call services HLA yet of seemingly did not

108
relate to the interactions must first passes the interaction of a particular class and then
transported sendInteraction call (), one of the channels of communication. These channels
exist for each direction of the two: one is designed for reliable messaging (Reliable), types
of message transfer with "Best effort".

To the payee are both channels gradually selected message delivery. Reading from a
channel implementing separate thread. If a message available to be transferred
interpretReceivedMessage method (). All messages are packed into "Shells", this is clearly
defined format. A kind of envelope is established range HLAbootstrapInteractionPayload.
Method interpretReceivedMessage () method call then conduct receiveInteraction () over
the object proxyAmbassador. This object before interacting further processing so as to
ensure the assignment of interaction the original message.

All reports are forwarded for further processing almost immediately after their arrival.
Messaging to occur in the order in which the emails. Such advice can make it be different
from the order of their departure (which is not significantly) and also from the order
timestamps (time stamp), if these stamps (which is substantial). This behavior is correct
RTI only if the members of Federation are not regulating or time (Time Regulating)
limited in time (time constrained) and all reports from the type Receive Order (RO). Type
of use for Time Stamp Order (TSO) should be a mechanism for message delivery XRTI
revised.

5.1.20.15 Class ExecutiveClientAmbassador
ExecutiveClientAmbassador instance of a class represents a distant counterpart instance
XRTIAmbassador class. At each instance XRTIAmbassador already initialized and started
communicating with RTI, falls just one instance of a class ExecutiveClientAmbassador.
Class instance ExecutiveClientAmbassador always exists on the server side (ie applications
XRTIExecutive), not on page clients (members of the Federation). Instance of a class of
ExecutiveClientAmbassador class XRTIExecutive after establishing network
communication with members of the Federation RTI.

5.1.20.16 Class FedereationExecutionAmbasador

FederationExecutionAmbassador class exists (similar to Class
ExecutiveClientAmbassador) always on the server side. One instance of this ONE class
represents the federation. Instance of a class-FederationExecution Ambassador is when
class receives ExecutiveClientAmbassador message that preceded the call to
createFederationExecution () some of the members of the Federation.

FederationExecutionAmbassador class maintains a list of instance
ExecutiveClientAmbassador, corresponding to the members of this Federation. Items in
this list are added using register ExecutiveClientAmbassador () after receipt of the report
prior to calling joinFederationExecution (). After logout members of the Federation calls
resign FederationExecution () (and the related report) is a method call
deregisterExecutiveClientAmbassador (), each member federation of the list removed. If a
member of this federation will generate news for other members of the Federation (sent
interaction, update attribute values, create or remove instances of object class), it is

109
delivered to the corresponding ExecutiveClientAmbassador object, which report to the
Federation Object ExecutionAmbassador. This object then conduct circulated a message to
all Federation members (except the sender).

5.1.20.17 Class XTRIExecutive
XRTIExecutive class contains the method main (), which means that it can run as a
standalone application. This application serves as a central server for HLA distributed
simulation. XRTIExecutive instance of a class starts, the thread channelAcceptorThread,
which handles requests to connect new members Federation. Every time you connect
members of the Federation is a new class instance ExecutiveClientAmbassador.

5.1.20.18 Class ProxyAmbassador
ProxyAmbassador class implements an interface hla.rti.FederateAmbassador.
ProxyAmbassador instance of a class are created when initializing the object
XRTIAmbassador class serves as the "root" the beneficiary of all callback zprav from the
RTI. This instance maintains its own list of registered instances of type
FederateAmbassador. One of the registered instances will then link for instance
FederateAmbassador type that is passed during a method call joinFederationExecution ().
All callback messages from the RTI are then mailed to the registered instances
FederateAmbassador.
Among the registered instances of the type is registered FederateAmbassador Board of
classes that are descendant of ProxyAmbassador. Name of these classes ending with the
words ProxyAmbassador such ManagementProxyAmbassador or
MetaFederationProxyAmbassador. These classes are not explicitly written by the
programmer XRTI, but are automatically generated in the translation tool of
ProxyCompiler XRTI. MetaFederationProxyAmbassador example, a class is generated
from a file MetaFederationObjectModel.xml.

The aim of auto-generated classes is definitely an effort to streamline this process sending
and receiving all messages in communication between the member federations and RTI.
Standard HLA contains a wide range of services with many different parameters, but does
not define any protocol for exchanging messages between the member federations and
RTI. As already mentioned, XRTI for all communication uses interaction. HLA standard is
too rugged and difficult, which is reflected inter alia, the removal of each interaction
(which is quite elementary operations) requires the execution sequence of several
operations. Among these operations include especially the need for obtaining all necessary
integer identifier (handle) interaction for a particular class and for individual interaction
parameters. It is also necessary to bring all the services required parameter to an instance
of HLA ParameterHandleValueMap. Automatically generated classes that are descended
ProxyAmbassador class, are capable of successful execution of such transactions to ensure
Which means that the programmer of the "low level" issues of practical do not worry.

Examples of such communication can be a situation that occurs after simulation participant
is required to establish a new federation and thus call the method
createFederationExecution () of class A buildings XRTIAmbassador. Sent requirements to
ensure that RTI following code:

110
public void createFederationExecution(String
federationExecutionName,URL fdd)

throws FederationExecutionAlreadyExists,
CouldNotOpenFDD, ErrorReadingFDD,
RTIinternalError
{
...
metaFederationProxyAmbassador.sendHLAcreateFederationExecutio
n(federationExecutionName,encodedFDD, new byte[0]);

...
}
The payee is receiveInteraction method () to compare the delivery handle interactions with
all known identifiers, and accordingly call the appropriate method. For example the
creation of federation is a beneficiary of such an event ExecutiveClientAmbassador class
that implements an automatically generated interface and must implement
MetaFederationInteractionListener receiveHLAcreateFederationExecution method ().
Time Implementation for double type
HLA standard does not determine specific data type to be used for entertainment
simulation time. HLA interface specification for Java provides an interface
hla.rti.LogicalTime. This interface must be implemented data type who was used by
members of Federation (and also RTI) for a specific simulation. All methods
RTIambassador FederateAmbassador interface and working with a logical time, they have
in their declarations given the right type LogicalTime.
LogicalTime interface contains a variety of methods, most important of which are listed In
the following list:

- add() reads at a specified interval to a given logical time.
- compareTo() - compare the logical time to another time. Particularly importantfor
all the services which enter the allocation of logical time.
- equals() - test for equality with another logical course of time.
- encode() - converts a value of logical time in a field of type byte []. This field can
be used for communication between RTI and the member federations (such as the
interaction parameter).

To create an instance of a logical time is usually not used a constructor, but some of the
methods of instances of classes that implement an interface LogicalTimeFactory. To create
a default logical time can use a method makeInitial () call define an instance of the factory.
When implementing a new type of logical Time is also necessary to implement this
interface.

The interface is also closely linked LogicalTime LogicalTimeInterval interface, which
serves primarily as a data type for the value lookaheadu. Of the important methods this
interface is necessary to mention at least isZero method () which returns true if it has a
logical time interval zero length. This method has significance for members of the
federations that use a null value lookaheadu. Other methods have similar importance as the

111
interface methods LogicalTime. K-Logical interface TimeInterval there is also the
interface LogicalTimeIntervalFactory.
In general, therefore we can say that a proposed new type of logical time is always
necessary to create four new class that implements the interface package hla.rti.
Simulation library uses the J-Sim simulation time for a double. Implementation XRTI
simulation provides the programmer types and LongValuedLogicalTime
LongValuedLogicalTimeInterval, which (as the name suggests), working with an long. To
use the simulation library J-Sim is therefore necessary to write new classes that will use a
double. All classes XRTI for Working with time org.npsnet.xrti.utilities are part of the
package.
5.1.20.19 Class DoubleValuedLogicalTime,
DoubleValuedLogicalTimeFactory

DoubleValuedLogicalTime class is very similar classes LongValuedLogicalTime. To
program a new class of seemingly simply copy the code original class and replace the
necessary throughout the type long double type. It reasoning is of course right, but it needs
to realize that a double represents a decimal number, which can be sources of problems in
the mutual compared numbers, whose values differ only slightly. Practically, this means
that the method compareTo () and equals () tests for equality compare the value of a
double, but a value of type long, which can be obtained by calling doubleToLongBits ()
(static method of class Double).

5.1.20.20 Class DoubleValuedLogicalTimeInterval,
DoubleValuedLogicalTimeIntervalFactory
DoubleValuedLogicalTimeInterval class represents a logical interval for lookahead. To
implement this class, including the relevant factory is as rules as for class
DoubleValuedLogicalTime.

5.1.20.21 Amend the class XRTIExecutive
When you connect to the federation members of the Federation must be a method
joinFederationExecution () Apart from the name requested federation and reference to an
instance of the type transmitted by FederateAmbassador hla.rti.MobileFederateServices
class instance. This class used to carry an instance of the type and LogicalTimeFactory
LogicalTimeIntervalFactory. When you connect to the federation must be given so that It
was clear as a representation of a logical time to the member federations to use it.
Eventually, with the logic does not work only member of the Federation, but also the RTI.
In one case XRTI XRTIExecutive the application, which means that it is necessary to
make some adjustments to the same class.

As previously mentioned, when you connect a new member of Federation of instances
ExecutiveClientAmbassador class. Constructor of this class has two parameters. The first
is a reference to XRTIExecutive instance, in the second parameter of type
MessageChannel be forwarded a link to a newly connected communication channel
member Federation. Instance of a class to be able to correctly interpret
ExecutiveClientAmbassador logical values of time, that sends the respective member

112
federation must also be informed about the implementation of logical time, which, under
the Federation uses. Therefore, it was during the introduction of support for time
management in class constructor XRTI ExecutiveClientAmbassador features a third
parameter type hla.rti.MobileFederateServices used for disclosure of this information.
Add XRTIExecutive should of course not limited to the use of a single type of logical time
that is used for the library right J-Sim.
Particular implementation of logical time can therefore be determined as a configuration
parameter for XRTIExecutive. As the default value is used particularly
DoubleValuedLogicalTimeFactory:

Class logicalTimeFactoryClass = Class.forName(
configuration.getProperty(
"LogicalTimeFactory",
"org.npsnet.xrti.utilities.DoubleValuedLogicalTimeFacto
ry"
)
);
logicalTimeFactory = (LogicalTimeFactory)
logicalTimeFactoryClass.newInstance();
Implementation of time management services group
The current version of XRTI does not support any services group time management.
XRTIAmbassador class does include all interface methods hla.rti.RTIambassador, methods
of time management services group, however, not carried out almost no (in some cases
none at all) code. Boot These services were necessary to adapt the existing classrooms
XRTI and also design and program some new classes. Modifications of existing classes in
particular concern XRTIAmbassador classes, and ExecutiveClientAmbassador
FederationExecutionAmbassador. Because of those adjustments is not trivial, will now set
a more detailed explanation.
5.1.20.22 enableTimeRegulation() Service
If a member federation to call a method enableTimeRegulation () is the corresponding
instance of ExecutiveClientAmbassador, called receiveHLAenableTimeRegulation()
method.
Before programming this method it is necessary to solve two problems. The first one is to
calculate a new time for members of the Federation. This time must be calculated to ensure
that regulate members of the Federation will be able to send TSO message with time stamp
which would be smaller than the current logical time of a temporary member of the
Federation. In other words we can say that there must be a situation where some time-
limited members of the Federation receives messages from your past. Consequently, the
algorithm for calculating this time must take into account the time constraints members of
the Federation. Where in the federation any time limits for members of the Federation is
not, this means that as time to turn time-control can be attributed to time members of the
Federation.

From the perspective of a temporary member of the Federation must be a logical time
value, for it is certain that members of the Federation no longer receive any message with a
timestamp that is smaller than this value. This value is called Greatest Available Logical
Time (GALT). GALT value exists for all members of the federation, however, has
significance only for members of the Federation, are limited. These members are not

113
allowed to move the Federation, its logical time for this value (hence the term time
constrained).

GALT calculation method implemented computeGalt (). If the rear Members of the
Federation is not time regulating, GALT value is not defined (or for other members of the
Federation). If you are located in the Federation of time-regulating members, the value can
be calculated as the minimum GALT from an effective logical time of these members of
the Federation. Efficient logical time is defined as the value minimum time stamps that can
time-regulating members of the Federation to send. If such a member state federation of
time granted, the effective logical Time is the sum of the value of its current time and its
value lookaheadu. Time in a state of advancing the effective logical time is calculated by
combining values the time required and its value lookaheadu. If members of the Federation
asked the switch on time-control, this means that TSO will be able to send news, and
therefore it is necessary to prevent the possible sent timestamp, which would be less than
the minimum values of GALT from the other members of the Federation. This means that
New logical time that members of the Federation shall be equal to the minimum value of
GALT other members of the Federation or its current logical time, if this time or greater in
GALT is not defined.
The second problem is sent to the callback timeRegulationEnabled ().

Auto-generated proxy classes namely, posted or any income of this interaction Type
impossible. Consequently, it is necessary to modify some files of which the proxy class
generated. In this case, the expanded set BootstrapObjectModel.xml. In this file has been
accompanied by the following definition of interaction classes:

<interactionClass name="HLAtimeRegulationEnabled"
sharing="PublishSubscribe"
transportation="HLAreliable"
order="Receive"
semantics="Notifies the federate that time
regulation
has been enabled.">
<parameter name="time"
dataType="HLAlogicalTime"
semantics="the current logical time"/>
</interactionClass>

<interactionClass name="HLAtimeConstrainedEnabled"
sharing="PublishSubscribe"
transportation="HLAreliable"
order="Receive"
semantics="Notifies the federate that time-
constrained
mode has been enabled.">
<parameter name="time"
dataType="HLAlogicalTime"
semantics="the current logical time"/>
</interactionClass>


114
After those adjustments, and translation is possible in XRTI methods
receiveHLAenableTimeRegulation () use this code:

bootstrapProxyAmbassador.sendHLAtimeRegulationEnabled(
encodedTime, new byte[0]);

Beneficiary of this interaction is a class instance RTIAmbassador. This class must contain
receiveHLAtimeRegulationEnabled method () which will carry the following code:

requestForTimeRegulationPending = false;
timeRegulationEnabled = true;
try
{
LogicalTime decodedTime = decodeLogicalTime(time);
proxyAmbassador.timeRegulationEnabled(decodedTime);
logicalTime = decodedTime;
}
catch (RTIexception rtie)
{
throw new FederateInternalError(rtie.toString());
}
...
Only after calling the method timeRegulationEnabled () on an object-proxy Ambassador is
a time-control members of the Federation, and switched members of the Federation can
send TSO reports.
Implementations disableTimeRegulation () is quite simple, because the regulation does not
require time-OFF sent confirmation callback.
Federation member ceases to be time regulating immediately after calling this service.
5.1.20.23 enableTimeConstrained() Service
On to a time limit to carry out call services enableTimeConstrained () and must be
confirmed timeConstrainedEnabled callback (). In addition to calculating new time
members of the Federation was to implement this service and the relevant callback
implemented in a way similar was described in the preceding paragraph.
Federation member ceases to be of limited immediately after calling the method
disableTimeConstrained (). Front TSO and RO messages on page, however, RTI may
contain messages that are not yet members of Federation of emails. For this reason, an
instance of a class ExecutiveClientAmbassador receive a message
receiveHLAdisableTimeConstrained () the relevant queue empty. Because already
members of the Federation is no time limit, will give all the reports from both the front
delivered as RO.
5.1.20.24 nextMessageRequestAvailable() Service
For distributed discrete simulation, it is necessary to program a particular service for the
allocation of simulation time. For use with J-Sim library one
nextMessageRequestAvailable the service (). Invoke this service on page Class
ExecutiveClientAmbassador speech calling receiveHLAnextMessageRequestAvailable ().
In the implementation of this service is important to note that a call for the allocation of
service time usually does not trigger immediately dispatched callback timeAdvanceGrant

115
() to the member federations, who demanded that allocation of time. RTI can time-limited
member of the Federation be assigned a logical time until the moment when the value of
the time required will be smaller (or less than or equal to) the value GALT of the members
of the Federation. major factor for the computation of GALT is a logical value of an
efficient time-regulating members of the Federation. For conservative federation of
synchronized, which are all members of Federation of regulating the current time
constraints of the previous sentence implies that no member federation can not move the
simulation time without the cooperation of other members of the Federation. Members of
the Federation, therefore, remain in the state time and advancing to the time when its value
will be increased GALT so as to fulfill the above conditions. GALT, the value increases,
the moment the time of behind-regulating members of the Federation. Such a request may
cause timeAdvanceGrant sent callback () for another member (or members) federation.

As all requirements to the allocation of time have a number of common characteristics
after delivery is an instance of passed ExecutiveClientAmbassador methods
handleTimeRequest (). The parameters of this method are the time required to identify and
required services. This method Sets inTimeAdvancingState to true, decodes the desired
logical time in case of using zero lookaheadu Set the necessary flags restrictions on zero
lookahead. Method handleTimeRequest () follow the same method forwards the request
instances FederationExecutionAmbassador classes, which reflect the current Federation:

protected synchronized void handleTimeRequest(
ExecutiveClientAmbassador eca)
throws FederateInternalError
{
computeAllGaltValues(eca);
sendAllPossibleTimeAdvanceGrants(eca);
} // handleTimeRequest

From this code it is obvious that after each request to put the time members of the
Federation are scaled values of all members of the Federation of GALT. If any value (or
values) GALT elevated, and the respective member (or members) are in a state of
advancing time, it can for such member federation entails allocating a logical time. The
time is always less or equal to the required time, which depends on the value of the time
required and the type of services required.

Method computeAllGaltValues () passes a list of current members of the Federation and of
each member of the Federation (including the sender's request) method call computeGalt
(). Subsequently passes the same list sendAllPossibleTimeAdvanceGrants method () and
for each member federation call the sendTimeAdvanceGrantIfPossible (). The operations
of this method deserves further explanation:


protected void sendTimeAdvanceGrantIfPossible()
throws FederateInternalError
{
if (!inTimeAdvancingState)
{
return;
}

116
if (requestedTimeService == SERVICE_FLUSH_QUEUE_REQUEST)
{
sendReceiveOrderMessages();
sendTimeStampMessagesAll();
sendTimeAdvanceGrant(requestedLogicalTime);
return;
}
...

First, verify that members of the Federation is in a state of advancing time. Provided this
condition is not met, action methods immediately cease. If required serving to
flushQueueRequest (), are members of the Federation immediately (ie, regardless of the
GALT) to deliver all RO and TSO messages that are located in their respective fronts.

...
if (requestedTimeService == SERVICE_NEXT_MESSAGE_REQUEST
|| requestedTimeService ==
SERVICE_NEXT_MESSAGE_REQUEST_AVAILABLE)
{
LogicalTime headTimeStamp =
timeStampQueue.getHeadTimeStamp();
if (headTimeStamp != null
&& headTimeStamp.compareTo(requestedLogicalTime) <=
0)
{
requestedLogicalTime = headTimeStamp;
}
}
if (canSendTimeAdvanceGrant())
{
sendReceiveOrderMessages();
sendTimeStampMessages(requestedLogicalTime);
sendTimeAdvanceGrant(requestedLogicalTime);
}
} // sendTimeAdvanceGrantIfPossible

When using the service nextMessageRequest () or nextMessageRequestAvailable () value
depends on the contents of the allocated time TSO queue reporting and worth required
time. If the TSO queue is not empty and the value of a timestamp first message in this
queue is less than the required time will assigned this value. Otherwise, the value assigned
by the member Federation introduced as a parameter required services. Deciding whether it
is possible be assigned simulation time, with the method canSendTimeAdvanceGrant ().
This method can safely return true if the value of time required member of the Federation
strictly less than the current value of the GALT. In the event that value of the time required
is equal to the value of GALT is deciding rather complex. The result depends on the
workload imposed by each members of the Federation and used lookaheadu. Details can be
found in the source code method canSendTimeAdvanceGrant ().

117
5.1.20.25 Asynchronous message delivery
Time-limited members of the Federation sett TSO and RO messages to the state time
advancing. For RO reports, however, may be the so-called asynchronous message delivery
that allows the immediate delivery. If a member federation enables asynchronous service
that will give RO messages are delivered in time advancing the state of the time granted.
On TSO messages not delivered asynchronously. Switched asynchronous service is
performing the service enableAsynchronousDelivery(), disable the
isableAsynchronousDelivery (). Naprograman for these services is necessary to change
the class XRTIAmbassador specifier to an attribute asynchronousDeliveryEnabled from
private to protected. The value attribute needs is working class child-ExecutiveClient
Ambassador, which decides whether the RO report will be queued or immediately
dispatched to the member federations.
New Classes for time management
In the preceding text explained how services are programmed to turn (Or off) time-
regulation also affects members of the Federation. Programmed into these services require
multiple adjustments XRTI existing classrooms. Besides these modifications were must
also design and program some new classes. A brief description will be shown in the
following paragraphs.

5.1.20.26 Class HLAMessage
HLAMessage class represents a general message that you can receive time-limited to
members of the Federation. From the right is when members of the Federation to call any
of the following services:
- sendInteraction() - sent interactions. On the part of the recipient of this report
corresponds to the right receiveInteraction ().
- updateAttributeValues() - updated attribute values. On the beneficiary side this
report should reflectAttributeValues right ().
- deleteObjectInstance() - remove instances of the object. On the beneficiary side of
this report should removeObjectInstance from the right ().

HLAMessage class is abstract and serves as the common ancestor of the class which
represent three types of reports referred to above. Among the most important attributes
class HLAMessage floor:

- sentOrdering - This information indicates whether the message was sent as a TSO
or RO.
- logicalTime - timestamp message when the message was sent as a TSO.
- transportationType - species transmission of the report: Reliable and Best Effort.

HLAMessage class implements an interface Comparable. The method compareTo () is
programmed to compare an attribute value logicalTime, which enables sorting messages in
the TSO queue according to values of time stamps.
5.1.20.27 Class HLAMessageSendInteraction
HLAMessageSendInteraction class is a descendant of HLAMessage. As the name
suggests, instances of this class are used to store messages that arises when members of the

118
Federation sends the interaction. Besides the attribute of the superclass contains attributes
InteractionClassHandle type identifier for the storage of class interaction and
ParameterHandleValueMap to hold parameters of interaction.
5.1.20.28 Class HLAMessageUpdateAttributeValues,
HLAMessageDeleteObjectInstance
These classes serve to messages that arise in connection with services
updateAttributeValues () and deleteObjectInstance (). Both classes are programmed any,
even though the timestamps support for these services is not complete.
5.1.20.29 Class TimeStampQueue
TimeStampQueue class serves as a front for TSO reports. It is a priority queue, sorted
according to timestamps, the value of the queue items. Items queue are the type
HLAMessage. To save items to take advantage of class LinkedList.
Class provides the following methods:

- enqueue(HLAMessage message) - inclusion of elements in the queue. After
inserting the element queue is sorted by calling the static method sort () Class
Collections.
- dequeue() - if the queue is empty, removes the first element of front and back its
value. If the queue is empty, returns null.
- getHeadTimeStamp() - returns the timestamp of the first report in the queue. Do not
delete this message from the queue. The method is used when the use of services
nextMessageRequestAvailable () and nextMessageRequest (). For the empty queue
is returned null.
- isEmpty() - Returns TRUE if the queue is empty.

All these methods are marked as synchronized, which provides secure access from
multiple threads.
5.1.20.30 Class ReceiveOrderQueue
ReceiveOrderQueue class serves as a front for RO news. The class is as simple
programmable FIFO queue, using the LinkedList class. Class provides the same methods
as the class TimeStampQueue. The difference is that ReceiveOrderQueue always add
elements to the queue method addLast () and this order of elements is maintained.

Support for timestamps for interaction
In order to send and receive interactions as TSO messages must be removed barriers to the
use of timestamps. The first of these barriers is HLAbootstrapInteractionPayload structure,
which is in communication used as an "envelope" for all interact. This structure does not
enable the imposition of a time stamp and a way to send information interaction (RO or
TSO).
The second problem is the implementation of the method sendInteraction () with a time
stamp to interact not even send:

public MessageRetractionReturn sendInteraction(

119
InteractionClassHandle
theInteraction,
ParameterHandleValueMap
theParameters,
byte[] userSuppliedTag,
LogicalTime theTime)
throws ...
{
verifyFederateIsExecutionMember();
verifyNoSaveInProgress();
verifyNoRestoreInProgress();
return null;
}
The last problem that must be resolved is to ensure the correct reception of interaction
time-stamped on by members of the federation, which was delivered to the interaction.
5.1.20.31 Struture Correction of HLAbootstrapInteractionPayload
HLAbootstrapInteractionPayload class is used as a cover interaction in communication
between the member federations and XRTI. Class contains attributes that are common to
all interactions:
- federationExecutionHandle - integer identifier carried Federation.
- userSuppliedTag - byte type field. May contain any values that were set
when it is sent interactions.
- interactionClassHandle - integer identifier interaction class.
- parameterHandleValuePairList - interaction parameter list. Parameter
contains a handle and a pair of parameter value.

To allow interactions to use when sent timestamp, this class is necessary to provide added
two attributes:
- sentOrdering - This information indicates whether the interaction was sent
as a TSO or RO.
- theTime - timestamp in the event that the interaction was sent as a TSO.
When using the RO has no meaning.

The addition of these attributes can make source code changes classes, because Class
HLAbootstrapInteractionPayload (like some other classes, is automatically generated
during translation XRTI. HLAbootstrapInteractionPayload necessary changes to the
structure must therefore be performed directly in the file BootstrapObjectModel.xml

In order to add parameters and sentOrdering theTime must first be specified data types of
the two parameters:

<enumeratedDataTypes>
...
<enumeratedData name="HLAorderType"
representation="HLAinteger32BE"
semantics="Order type to be used for sending
attributes or interactions.">
<enumerator name="Receive"
values="0"/>

120
<enumerator name="TimeStamp"
values="1"/>
</enumeratedData>
...
<arrayDataTypes>
...
<arrayData name="HLAlogicalTime"
dataType="HLAbyte"
cardinality="Dynamic"
encoding="HLAvariableArray"
semantics="An encoded logical time. An empty array
shall indicate that the values is not defined."/>

Now it's nothing to prevent extension of the structure HLAbootstrapInteractionPayload
two new parameters:

<fixedRecordDataTypes>
<fixedRecordData name="HLAbootstrapInteractionPayload"
encoding="HLAfixedRecord"
semantics="The payload of the bootstrap
interaction.">
...
<field name="sentOrdering"
dataType="HLAorderType"
semantics=""/>
<field name="theTime"
dataType="HLAlogicalTime"
semantics=""/>
</fixedRecordData>

After translation XRTI you can see the source code, class HLAbootstrap
InteractionPayload already contains all the necessary attributes.
5.1.20.32 Amend the class XRTIAmbassador
For each interaction, to be sent by calling the method sendInteraction () (Irrespective of the
time stamp), applies one of two ways transfer: Reliable and Best Effort. Transmission
method for a particular class of interaction Dan is a federation model. Because the method
sendInteraction () class instance XRTIAmbassador must respect the mode of transmission,
the ox is always one of the following methods:
- sendInteractionReliable() - send an interaction using reliable forms of
transmission.
- sendInteractionBestEffort() - send an interaction using transmission Best
Effort.
Both methods are marked as protected because they are not intended for the called user
class XRTIAmbassador same time be available in class child ExecutiveClientAmbassador.

It is clear that that method needs to be called as well as methods sendInteraction () that
allow the use of a timestamp. Both methods therefore must be extended to the same
parameters as the structure-HLAbootstrap InteractionPayload. Enlargement methods

121
sendInteractionReliable () is shown in the following section of code (method
sendInteractionBestEffort () was adjusted in an analogous fashion):

protected void sendInteractionReliable(
InteractionClassHandle theInteraction,
ParameterHandleValueMap theParameters,
byte[] userSuppliedTag,
OrderType sentOrdering,
LogicalTime theTime)
throws ...
{
...
if (sentOrdering.equals(OrderType.RECEIVE))
{
hlaSentOrdering = HLAorderType.Receive;
encodedTime = new byte[0];
}
else // sentOrdering.equals(OrderType.TIMESTAMP)
{
hlaSentOrdering = HLAorderType.TimeStamp;
encodedTime = new byte[ theTime.encodedLength() ];
theTime.encode(encodedTime, 0);
}
HLAbootstrapInteractionPayload payload =
new HLAbootstrapInteractionPayload(
joinedFederationExecutionHandle,
userSuppliedTag,
((XRTIInteractionClassHandle)theInteraction).getIdentifier(),
parameterHandleValuePairs,
hlaSentOrdering,
encodedTime
);
try
{
HLAEncodingOutputStream hlaeos = new HLAEncodingOutputStream(
channel.getOutputStream()
);
synchronized(channel)
{
hlaeos.writeHLAinteger32BE(MAGIC_NUMBER);
hlaeos.writeHLAinteger32BE(bootstrapObjectModelVersion);
payload.encode(hlaeos);
hlaeos.flush();
}
}
...
}

SendInteraction() adjusted method does not use the time stamp, taken as a parameter value
sentOrdering OrderType.RECEIVE time stamp blank:

public void sendInteraction(InteractionClassHandle theInteraction,
ParameterHandleValueMap theParameters,

122
byte[] userSuppliedTag)
throws ...
{
...
if(icd.getTransportation().equals(TransportationType.HLA_RELIABLE))
{
sendInteractionReliable(
theInteraction,
theParameters,
userSuppliedTag,
OrderType.RECEIVE,
null
);
}
else // icd.getTransportation().equals(TransportationType.HLA_BEST_EFFORT)
{
sendInteractionBestEffort(
theInteraction,
theParameters,
userSuppliedTag,
OrderType.RECEIVE,
null
);
}
...

It remains to be programmed overloads sendInteraction () with a time stamp. Before
sending the interaction must verify the validity of a timestamp, which will
verifyTimeStampIsValid method () which when broken InvalidLogicalTime stamp benefit
from the exemption. In order to send a TSO interaction must have a class to model a stated
consultation TimeStamp Federation and member of the Federation shall be time-
regulating. If these conditions are met, will be transferred to the interaction of RO and
timestamp will be ignored.

public MessageRetractionReturn sendInteraction(
InteractionClassHandle theInteraction,
ParameterHandleValueMap theParameters,
byte[] userSuppliedTag,
LogicalTime theTime)
throws ...
{
...
verifyTimeStampIsValid(theTime);
OrderType sentOrdering;
if (timeRegulationEnabled
&& icd.getOrder().equals(OrderType.TIMESTAMP))
sentOrdering = OrderType.TIMESTAMP;
else
sentOrdering = OrderType.RECEIVE;
try
{
if(icd.getTransportation().equals(TransportationType.HLA_RELIABLE))
{

123
sendInteractionReliable(theInteraction,
theParameters, userSuppliedTag,
sentOrdering, theTime
);
}
else
// icd.getTransportation().equals(TransportationType.HLA_BEST_EFFORT)
{
sendInteractionBestEffort(theInteraction,
theParameters, userSuppliedTag,
sentOrdering, theTime
);
}
}

In order to ensure proper implementation of interaction with a time stamp, must be
partially change the behavior of methods interpretReceivedMessage () XRTIAmbassador
class. This method is declared as private and after delivery interaction ox
receiveInteraction direct method () on an object proxyAmbassador. This behavior without
changing the method of child class inherits ExecutiveClientAmbassador. For the
implementation of the services Time management is necessary, however, that the classes
and XRTIAmbassador ExecutiveClientAmbassador When I receive interactions behave
quite differently, which does not allow this solution. For this reason, the "prime" method
call receiveInteraction () replaced by Call the newly created method, having the following
header:

protected void proxyAmbassador_receiveInteraction(
InteractionClassHandle interactionClass,
ParameterHandleValueMap theParameters,
byte[] userSuppliedTag,
OrderType sentOrdering,
TransportationType theTransport,
LogicalTime theTime,
OrderType receivedOrdering)

This method can be in a class descendant ExecutiveClientAmbassador overlap. Although
the method interpretReceivedMessage () remains private, the fly will always call "proper"
method for accepting interaction.

In class, this method XRTIAmbassador must be programmed manner, which ensures that
the following conditions: members of the Federation may receive TSO message only when
the message was sent as a TSO and at the same time, the beneficiary news time limited.
Failure to meet these conditions will be right (here, interaction) delivered as a right-RO.
Solution is shown in the following code snippet:

if (sentOrdering.equals(OrderType.TIMESTAMP) && timeConstrainedEnabled)
{
proxyAmbassador.receiveInteraction(interactionClass,
theParameters, userSuppliedTag,
sentOrdering, theTransport,
theTime,
OrderType.TIMESTAMP);
}

124
else
{
proxyAmbassador.receiveInteraction(interactionClass,
theParameters, userSuppliedTag,
sentOrdering, theTransport);
}

5.1.20.33 Amend the Class ExecutiveClientAmbassador
Every interaction, the members of the Federation sent by instances of the class
XRTIAmbassador will reverse one of the channels of communication with the related
instance of ExecutiveClientAmbassador. This instance is responsible for the delivery of the
interaction of all Members of the Federation, have stepped forward for collecting taxes
interaction class. The introduction of time management services is determined by the
interaction of the temporary members of the Federation may already RTI Deliver
immediately, but must carry out their inclusion in the TSO queue or RO messages. In
addition to setting a time limit of individual members of the Federation must RTI also take
into account perhaps the asynchronous message delivery. Generally It is true that various
members of the Federation may have in one moment, these switches setting different ways,
which means it can be situations where the same interaction will be a member of the
Federation entered into the queue, while another procedure member of the Federation shall
immediately upon receipt.

Following the adoption of the method of interaction
proxyAmbassador_receiveInteraction() interactions to get an instance of
FederationExecutionAmbassador, which represents the current federation. Because the
representatives of Federation maintains a list of current members of the Federation, the
interaction can be communicated to the other members of the Federation except the sender.
This interaction gets to all registered instances of the class ExecutiveClientAmbassador.
Forwarded to other members of the interaction Federation carries out the methods
sendInteractionReliable () and sendInteractionBestEffort (), which for that purpose in the
classroom ExecutiveClientAmbassador overlap. Kod sendInteractionReliable method () is
shown in the following excerpt:

protected void sendInteractionReliable(
InteractionClassHandle theInteraction,
ParameterHandleValueMap theParameters,
byte[] userSuppliedTag,
OrderType sentOrdering,
LogicalTime theTime)
throws ...
{
if(subscribedInteractionClasses.contains(theInteraction))
{
boolean b1 = descriptorManager.isBootstrapHandle(theInteraction);
boolean b2 = sentOrdering.equals(OrderType.RECEIVE)
&& asynchronousDeliveryEnabled;
boolean asynchronous = b1 || b2;

First, check whether members of the Federation subscribed to the interaction class. If not,
the end of the activity method. If the members of the Federation is limited and the

125
interaction not to be delivered in an asynchronous way (ie immediately) to be created class
instance HLAMessageSendInteraction (see 6.4.2) that will be loaded into the appropriate
queue according to values sentOrdering:

if (timeConstrainedEnabled && !asynchronous)
{
// enqueue message into the queue
HLAMessageSendInteraction message =
new HLAMessageSendInteraction(
theInteraction,
theParameters, userSuppliedTag,
sentOrdering,
TransportationType.HLA_RELIABLE,
theTime);
if (sentOrdering.equals(OrderType.TIMESTAMP))
{
timeStampQueue.enqueue(message);
}
else // (sentOrdering.equals(OrderType.RECEIVE)
{
receiveOrderQueue.enqueue(message);
}
}
Otherwise, the interaction is sent immediately without using the queue. Outbox interaction
method is called an ancestor sendInteractionReliable (), which interact registration in the
relevant channel.

else // (!timeConstrainedEnabled || asynchronous)
{
// send message immediately without using a queue
super.sendInteractionReliable(theInteraction,
theParameters,
userSuppliedTag,
sentOrdering, theTime);
}
}
} // sendInteractionReliable

Cod sendInteractionBestEffort method () is analogous.

Others XRTIs Functions
Yet described adjusting software XRTI related exclusively to the service group time
management and related issues timestamps. In addition to these services to produce added
XRTI were still some other features:
- Synchronization Services Federation - These services include the management
group of the Federation. The original version XRTI not support these services.
- Graphical user interface - Graphical user interface applications XRTIExecutive. As
the original version XRTI run only in text mode, and all information about the
work of the applications were printed only on the standard (or standard error)
output, it was proposed a simple graphical user interface (GUI). The main window
displays a list of currently connected Federation, including members of the

126
Federation, you can also see a window with information on activities of the
application (debug window). To use the GUI is necessary when you run
XRTIExecutive specify on the command line option-gui (otherwise the application
will run in text mode).

5.1.20.34 The Simulation Process
The Principle
The principle of this model is depicted in the figure 6.6. It is based on time serialization of
threads of the control program, which is accomplished with the J-Serializer. The model of
the surrounding environment is modeled using the J-Sim library. Serialized threads of the
control program are executed by special scheduler, a part of J-Serializer, which tightly
cooperates with the J-Sim part of the whole simulation. The information necessary for
scheduling is gathered from the control program and the model of the environment at
runtime. The proposed method uses two kind of computer-environment: control interface,
between a computer node and its part of controlled device; and network interface, a serial
bus interface. The model of the network is inspired in the message-passing paradigm,
asynchronous message passing without blocking.


127

Figure 6.6: The Principle of the Model-Based Development


Model Version of the Network
In figure 6.7 we consider a physical medium Ethernet which are connected a bunch of
nodes. Each node communicates throughout the CNI (Communication Network Interface) .

128

Figure 6.7: Communication Controller of N Nodes.

Model Version of a Node
In the figure showed below, we present the structure of a node of the distributed embedded
simulation.
As we said before, we need two kinds of interface connection (IC). One of them, between
the node and hardware (registers) that is achieved through the Java Native Interface (JNI),
which read/write data from/to controlled hardware, registers. (e.g. tank, pumps and
sensors). The second one is used to communicate to the network, for that purpose we take
into account the medium and buffers. It is important to take into account that we have two
kinds of nodes, 1-node for the main tank and N-nodes for the stations. (See figure 6.8).


A
B



Application


(Java + JiJ)
Network
Model
(medium +
buffers)

Hardware
Model
(registers)

Model
Controlled
Environment
(tank, pumps,
sensors)
A
B
IC to
Network
IC to HW
computer
Network

129
Figure 6.8: The model of a node in the network The model form
This is the model of a node for our distributed simulation.
- The application is developed in Java over the use of Java in Java (JIJ) which is a
sub package J-Sim library (Java Simulator).
- The application has two interfaces (CI) one for the network and one for the
computer hardware.
- The network model will contain the medium and the buffers.
The model will contain environmental control system elements.
In addition, there are two types of one master n slave nodes.

The Implementation
Master Slave Network Protocol
Master Slave protocol, is a strategy for node communication in where a single
master device allots time slots for all the other nodes on the network to transmit, and
schedules these time slots so that multiple nodes cannot collide. The master device
addresses each node by name, one at a time, letting that node talk for a certain amount of
time. When it is finished, the master addresses the next node, and so on, and so on.
In this contest the master node might have the following functions:
- Sender(sendDatagram), master sends a message to all the nodes e.g. if all the nodes
are working correctly (e.g. the level of water is not under or above the limits, or if
are there at least K working bombs, etc.) see Case Study.
- Receiver(recvDatagram), all nodes answering to the send message of the master
node. Master node evaluates all the responses and does the correction if it is
necessary (e.g. turn the pump off/on in order to control the water level in each
water station).
Each node will have the following functions:
- Acknowledge(respDatagram), message was received without troubles.
- Response(acknDatagram), send message to the master node, responding for the
claimed task.

Multi Master Network Protocol
Multi Master protocol, where each node gets a turn to talk (one at a time), and
then grants permission for the next node to talk when it is done. Permission to talk is
passed around from node to node as each one hands off the "token" to the next in
sequential order. The token itself is not a physical thing: it is a series of binary 1's and 0's
broadcast on the network, carrying a specific address of the next node permitted to talk.
Although token-passing protocol is often associated with ring-topology networks, it is not
restricted to any topology in particular. Moreover, when this protocol is implemented in a
ring network, the sequence of token passing does not have to follow the physical
connection sequence of the ring.
In the Multi-master model the communication among the nodes will be achievable
through message passing paradigm. There are two types of this paradigm, synchronous and
asynchronous. We well explain the advantages and disadvantages of each one, concluding
that in our proposed model the asynchronous one suit better our model.

Synchronous Message Passing

130
The program that initiates the send (receive) waits until the send (receive) is
complete. This waiting is called blocking. Completion of a send only means that the
message buffer can be reused and does not imply that the message has been received.
ssend() and srecv() are the synchronous send and receive system calls. This model
suits better in a tightly coupled computer environment where there is a multiprocessor
system sharing memory. But in the distributed setting synchronous external calls seem less
satisfactory; at best resulting in inefficient use of processor capacity, at worst resulting in
deadlock. Furthermore, it is difficult to combine active and passive behavior in concurrent
objects. It is clearly less suitable in a distributed setting with loosely coupled components.

Asynchronous Message Passing
In the other hand, asynchronous message passing gives better control and
efficiency, but lacks the structure and discipline inherent in method calls. The integration
of the message concept in the object-oriented setting is unsettled, especially with respect to
inheritance and redefinition. An object offers methods to its environment, specified
through a number of interfaces and co-interfaces. All interaction with an object happens
through method calls. In the asynchronous setting method, calls can always be emitted,
because the receiving object cannot block communication. Method overtaking is allowed:
if methods offered by an object are invoked in one order, the object may start the method
instances in another order. A method instance is, roughly speaking, program code with
nested processor release points, evaluated in the context of local variables. Due to the
possible interleaving of different method executions, the values of an objects program
variables are not entirely controlled by a method instance, which suspends itself before
completion. A method may have local variables supplementing the object variables. In
particular, the values of formal parameters are stored locally, but other local variables may
also been created. asend() and areceive() are the asynchronous send and receive system
calls. An asynchronous send or receive does not block. It returns a unique message id,
which can be used later to check for completion of the message.
Implementation of Asynchronous Message Passing
In order to follow the development of this method; we have to take into account several
conditions:

Conditions

- Tested media is a serial bus.
- We will use an asynchronous message passing. In this case there are two
alternatives: blocked and unblocked asend(), areceive() functions. For the
simplicity let get the unblocked situation.
- Node addresses are integer numbers in the interval 1 to n.
- We transmit a frame of fixed length of 256 bytes (for example).(see figure 6.9)
- Each node has one unlimited buffer for sending and one for receiving.
- Multiple access (M.A.) is implemented in the same way as in Ethernet it is
when a medium is occupied then the station is randomly waiting for a period of
time.

Program solution

131

We build an abstract class NetworkInterface (Java IC) in that two functions are built.
Figure 6.10.

asend( adrNode, frame) - adrNode = 0, broadcast.
- adrNode = 0, accept each message.
frame areceive(adrNode)



- return null = nothing is incoming.


Figure 6.9: Architecture of a Frame

Implementation (model) (5 classes)
- Frame sent message
- sendBuffer passive object is composed by:
message queue for sending
reference to sending thread SendThread
Implementation of asend(). Put one frame to buffer (queue) and
awakes the thread.
Function (method) transmitFrame(RecBuffer buf) uses sending
thread to own transfer message.

Implementation of SendThread and ReceiveBuffer
SendThread . This is a thread that sends message (J-Sim process), contains:
- Reference to own buffer of type SendBuffer.
- Reference to shared objects serial bus.
- Method run() (J-Sim), which follows algorithm:
Index connection
Address 1-n
256 bytes of data
Type Frame

132

Figure 6.10. Model Interfaces

1. Takes a message from sendBuffer. ( if there arent then passivate() ) (J-sim).
2. Test serialBus, if bus is free then gives the address (reference) from receive
buffer then 3, else 4
3. Hold(sending time), transmitFrame(receiveBuffer), free seriaBus release()
goto 1
4. If not free then hold(randomize time) then goto 2
ReceiveBuffer. Receiving buffer (analogous like SendBuffer)
SerialBus. (One for the entire network model). Serial bus model is passive and has:
- Attribute occupied bus, type Boolean
- Reference array to receiving buffers
- Method RecBufferTestBus( int adrNode) (returns either null or occupied, or
reference to buffer, then we can start sending).
- Method releaseBus() release bus when transmission ends. See figure 4.
Connections are done by Java references that is showed in the figure 5.

Simulation for two nodes:

Figure 6.11. Model for two nodes

Application 2

1 SendBuffer

1 ReceiveBuffer

1 SendThread
Application 1

Network IC
HW IC
HW IC
Network IC
1 SendBuffer

1 ReceiveBuffer

1 SendThread
S
E
R
I
A
L

B
U
S

Network
model
Application


Network
Interface


Network
model
A B

133
The first prototype was theoretically and practically developed in [99]. Here we
concentrate our effort in the distributed embedded application form. Then we have to use
two kinds of computer-environment interface control interface (i.e. between a computer
node and its part of controlled device) as well as network interface (i.e. a serial bus
interface). Obviously, the model complexity will arise fast, because the model should
include all the nodes of distributed system and a sub-model of communication protocol as
well [100].

Simulation for N nodes

Figure 6.12: Model for N-nodes

In this case the communication for n-nodes will arise as well as the amount of operations
into the commutation controller.

Simulation for a distributed system with n nodes with CAN protocol
In the case of simulation of the whole system each instance of simulation can be as
described in the figure 6.13. The number or messages between the instances arise
exponentially. Each instance of simulation can be a set of nodes intercommunicated by a
CAN protocol.

n

Application
Communication
Controller
Model


Network IC
Network Model
Connection
Network Model
Communication
Controller
Model
Communication
Controller
Model

134

Figure 6.13: Simulation of the Entire Distributed Embedded System

After we have the requirements verified through TCTL formalism using UPPAAL tool we
can write the application in Java for the proposed embedded device and test it in a pc
clone.
We can reach this goal writing the proposed model and the tested application. Those, the
model and the application are merged together. In figure 3 shows the main differences
between the normal operation mode in a device and the testing mode on a pc clone. Figure
6.14.


135


Figure 6.14: The proposed Process part two: Developing a Distributes Java Application for
Embedded Devices.


In the place of the original application, its modified version is put together with the model
of the device and these two components are tested together. The modification of the
application is performed automatically by the J-Serializer Converter which links it with the
J-Serializer Runtime (after compilation). However, the model of the device has to be
created manually. It is presumed that the model of the device and the environment are built
up over J-Sim.

Architecture overview

After we have the requirements verified through TCTL formalism using UPPAAL tool we
can write the application in Java for the proposed embedded device and test it in a pc
clone.
We can reach this goal writing the proposed model and the tested application. Those, the
model and the application are merged together. In figure 3 shows the main differences
between the normal operation mode in a device and the testing mode on a pc clone.

136

Figure 6.15: Layers Present During Normal Operation and During Testing

In the figure showed above represents the basic idea of a node of the network in a
distributed embedded system. This shows the main differences between the normal
operation mode in a device and the testing mode on a pc clone.
The main differences are: the embedded device is replaced with a pc, the operating systems
used differ but their functionality stays the same. In embedded devices, the SE JVM is not
usually used due to its resource requirements. In its place there is a ME equivalent (KVM
or CVM). Some JVM functionality is missing and dome is added (e.g. the packages
javax.microedition.*). And finally the original application is replaced with it modified
version, running on top of the J-Serializer Runtime. The model of the environment running
on top of J-Sim must also be added to the system. Since the original application
communicates with the environment, all this communication must be replaced with calls to
some parts of the model responsible for this. There must be a layer superior to both the
tested application and the model in order to synchronize the simulation times in both
subsystems.


137
6 Case Study
The following example is a traffic intersection control system. It provides a fully
development example of an object oriented approach to requirements specification of a
complex real time system. The second part is the simulation of the entire distributed
system.
Part one the software engineering approach
6.1 Introduction
Traffic controllers currently in use comprise simple timers that follow a fixed cycle to
allow vehicle/pedestrian passage for a pre-determined amount of time regardless of
demand, actuated traffic controllers that allow passage by means of vehicle/pedestrian
detection, and adaptive traffic controllers that determine traffic conditions in real-time by
means of vehicle/pedestrian detection and respond accordingly in order to maintain the
highest reasonable level of efficiency under varying conditions. The traffic controller
described in this specification is capable of operating in all three of these modes.

6.1.1 Purpuse
This specification defines the software design requirements for an intersection control
system for simple, four-way pedestrian/vehicular traffic intersections. The specification is
intended for use by end users as well as software developers.

6.1.2 Scope
This software package is part of a control system for pedestrian/vehicular traffic
intersections that allows for (1) a fixed cycle mode, (2) an actuated mode, (3) a fully
adaptive automatic mode, (4) a locally controlled manual mode, (5) a remotely controlled
manual mode and (6) an emergency preempt mode. In the fully adaptive automatic mode, a
volume detection feature has been included so that the system is aware of changes in traffic
patterns. Pushbutton fixtures are also included so the system can account for and respond
to pedestrian traffic. The cycle is controlled by an adaptive algorithm that uses data from
many inputs to achieve maximum throughput and acceptable wait-times for both

138
pedestrians and motorists. A preempting feature allows emergency vehicles to pass through
the intersection in a safe and timely manner by altering the state of the signals and the
cycle time.
6.1.3 Definitions, Acronyms, Abbreviations
The following is a list and their definitions as used in this document.
6.1.3.1 10-Base T
Physical connection formed by a twisated pair as described in IEEE 802.3. networking
connection designed to transfer up 10 10 megabits per second.
6.1.3.2 ADA
American with Desabilities Act.
6.1.3.3 API
Aplication program interface

6.1.3.4 Approach
Any one of the routes allowing access to an intersection.
6.1.3.5 Arterial Road
A major traffic route or route used to gain access to a highway.
6.1.3.6 Aspect
The physical appearance of an illuminated traffic standard.
6.1.3.7 Attribute
Property of a class.
6.1.3.8 Cycle Time
The time required to complete an entire rotation (cycle) of traffic signals at any one
intersection.
6.1.3.9 Direct Route
A route directly through the intersection that does not require the vehicle to turn.
6.1.3.10 DOT
Department of Transportation.
6.1.3.11 Downstream
The normal travel direction for vehicles.
6.1.3.12 Ethernet
The most commonly used local area networking method as described in IEEE 802.3.

139
6.1.3.13 Intersection
A system, including hardware and software, that regulates vehicle and pedestrian
traffic where two or more major roads traverse. The class of intersection considered
in this specification has only two roads.
6.1.3.14 Manual Override
A device located at and physically connected to each intersection control system
that allows traffic regulatory personnel to control the intersection manually.

6.1.3.15 Method
Procedure within a class exhibiting an aspect of class behavior.
6.1.3.16 Message
An event thrown from one code unit and caught by another.
6.1.3.17 Occupancy Loop
A device used to detect the presence of vehicles in an approach or to count the
passage of vehicles using an approach.
6.1.3.18 Offset
The time difference between cycle start times at adjacent intersections. Applies only
to coordinated intersection control, which is not covered by this specification.
6.1.3.19 Orthogonal Route
A route through an intersection that requires a vehicle to turn.
6.1.3.20 Pedestrian Presence Detector
A button console located on the corner of an intersection which gives pedestrians
who wish to cross a street the ability to alert the intersection control system to
their presence.
6.1.3.21 Pedestrian Traffic Standard
Signals facing in the direction of pedestrian cross walks which have lighted indicators
marked Walk and Dont Walk.
6.1.3.22 Phase
The state of an intersection. A particular period of the regulatory traffic pattern.
6.1.3.23 Remote Override
A computer host that includes a software interface allowing a remote administrator
to control the intersection remotely.
6.1.3.24 RTOS
Real-Time Operating System.

140
6.1.3.25 Secondary Road
A route that does not typically support high traffic volume or experiences less usage
relative to another route.
6.1.3.26 SNMP (Simple Network Management Protocol)
The de facto standard for inter-network management, defined by RFC 1157.
6.1.3.27 Split
The duty cycle for a given phase, expressed as a decimal or percentage.
6.1.3.28 Vehicle Traffic Standard
A traditional traffic signal with red, yellow, and green indicators.
6.1.3.29 Upstream
Direction opposite to the normal direction of vehicle travel.
6.1.3.30 Vehicle Presence Detector
See Occupancy Loop.
6.1.3.31 WAN
Wide Area Network.

6.2 Overall Description
6.2.1 Intersection Overview
This intersection class to be controlled is depicted in Figure 8.1.
The target class of intersection has the following characteristics:
1. Four way crossing.
2. Roadway gradients and curvatures are small enough to be neglected.
3. No right turn or left turn lanes or right turn and left turn signals (note,
however, that the intersection is wide enough to allow vehicles passing directly
through to pass to the right of vehicles turning left).
4. Intersecting roads of different priorities (e.g., one road may be an arterial while the
other may be a secondary road) or of equal priority.
5. Two vehicle traffic standards per approach: one suspended by overhead cable, the
other mounted on the pedestal.
6. One pedestrian crosswalk per approach.
7. Pedestrian traffic standards, pedestal mounted, on each side of each crosswalk.
8. Pedestrian presence detectors (pushbuttons) on each side of each crosswalk.
9. Stop line vehicle presence detectors (loop detectors) in all approaches (one per
approach) for detecting vehicle presence and for counting vehicles passing through
the intersection.

141

Figure 8.1: Intersection Topography

6.2.2 Product Perspective
6.2.2.1 System Interfaces
These are described in detail in the sections below.
6.2.2.2 User Interfaces
6.2.2.2.1 Pedestrians
Pedestrians pushes button, generating service request to software and receives, in time, the
Walk signal.
6.2.2.2.2 Motor Vehicles
In ACTUATED mode, vehicle enters the inteersection, generating service request to
software and receives, in time, the Okay to Proceed signal.
In ADAPTIVE mode, vehicle passes over the loop detector, increasing the vehicle count,
which, in turn, causes an adjustment in intersection timings.
6.2.2.2.3 Emergency Vehicle
Emergency vehicle operator activates the emergency vehicle override signal, generating
priority service request to software and receives, in a preemtive time, the Okay to
proceed signal.
6.2.2.2.4 Traffic Regulatory Personnel

142
Traffic regulatory personnel will remove the manual override device from the control box
and press buttons to control the intersection manualy.
6.2.2.2.5 Remote Operator
Remote operator uses a software control panel either to control the state of the intersection
directly or to observe and manipulate the parameters and state of a specific intersection
control system.
6.2.2.2.6 Maintainer
Maintainer accesses system through
6.2.2.3 Hardware interfaces
The Intersection Control System hardware interfaces are summarized in Figure 8.2 on the
following page.
6.2.2.3.1 Major Hardware Components Summary
Table 1 Major intersection control system hardware components
Item Description Quantity
1 Intersection Controller Enclosure 1
1.1 Input Circuit Breaker 1
1.2 Input Transformer 1
1.3 Input Power Supply with UPS 1
1.4 Intersection Controller 1
1.5 Lamp Driver 20
1.6 Lamp Current Sensor 40
1.7 Green Signal Safety Relay 1
1.8 Manual Override Console 1
1.9 Vehicle Presence Detector Interface Unit (not shown in 8.2) 4
1.10 Pedestrian Request Detector Interface Unit (not shown in 8.2) 8
1.11 RJ-45 Ethernet Connector DOT Network 1
1.12 RJ-45 Ethernet Connector Maintenance 1
1.13 Enclosure Wiring A/R
2 Vehicle Traffic Standard Suspended 4
3 Vehicle Traffic Standard Pole Mounted 4
4 Pedestrian Traffic Standard 8
5 Pedestrian Request Detector 8
6 Vehicle Presence Detector 4
7 Emergency Vehicle Transponder 1
10 Field Wiring A/R






143


Figure 8.2. Intersection Controller (not all details and interconnection shown).

6.2.2.3.2 Wired Interfaces Internal
Hard-wired connections between the intersection controller and the following hardware
components within the intersection controller enclosure are provided:
1. Traffic Standard Lamp Drivers (20)
2. Traffic Standard Lamp Current Sensors (40)
3. Vehicle Presence Detector Interface Units (4)
4. Pedestrian Presence Detector Interface Units (4)
5. Green Signal Safety Relay (1)
6. Manual Override Console (1)
7. Maintenance Connector (2; 10-base T twisted pair)
6.2.2.3.3 Wired Interfaces External
Hard-wired connections between the intersection control enclosure and the following
external hardware components are provided:
1. Pedestrian Presence Detector
2. Pedestrian Traffic Standard
3. Vehicle Presence Detector
4. Vehicle Traffic Standard
5. Emergency Vehicle Transponder
6. DOT Wide-Area Network (WAN)
6.2.2.3.4 Emergency Vehicle Transponder

144
The emergency vehicle transponder is a radio frequency link between the intersection
control system and the emergency vehicle override controller.
6.2.2.3.5 Ethernet Connection to DOT WAN
Interaction between the software system and the remote operator console is conducted
over a standard 10 base-T local area network. Each intersection control system is identified
with a unique, statically assigned IP address.
6.2.2.4 Software Interfaces
6.2.2.4.1 Operating System
The intersection controller interfaces to the RTOS via standard OS API calls.
6.2.2.4.2 Resource Managers
Interfaces to hardware are handled by resource managers not specified in this SRS.
Resource managers are assumed to have direct access to the object model defined here.
6.2.2.4.3 Software Control Panel
The intersection control system must be able to interact with the software control panel to
allow remote user access. This interface provides a remote user the ability to modify
system parameters, perform maintenance functions, or assume manual control of the
intersection. The standard protocol for this communication will be SNMP version 1.
6.2.2.5 Communications Interfaces
The system will utilize TCP/IPs SNMP interface for inter-system communication.
6.2.2.6 Memory Constraints
6.2.2.6.1 Flash Memory
Flash memory will be the memory media of choice for the system. The software will
require no more than 32 MB of flash memory for RTOS, application program, and data.
6.2.2.6.2 RAM
RAM will be used for application execution. The system shall not require more than 32
MB of RAM. Upon boot, the RTOS, application program and static data needed for
execution will be copied from flash into the RAM.
6.2.2.7 Operations
1. Automatic, unattended operation (normal operation)
2. Local manual operation (through override console)
3. Remote manual operation (through WAN port)
4. Local observed operation (through maintenance port)
5. Remote observed operation (through WAN port)
6. Remote coordinated operation (option; through WAN port)
6.2.2.8 Site Adaptation Requirements
This is summarized in Section 8.3, above.

145
6.2.3 Product Functions
The Intersection Control System provides the following functions:
1. Control of the intersection vehicle traffic standards.
2. Control of the intersection pedestrian traffic standards.
3. Collection and processing of traffic history from all approaches.
4. Adaptive control of intersection timings in response to traffic flow.
5. Actuated control of intersection in response to vehicle presence.
6. Timed control of intersection in response to a fixed scheme.
7. Handling of pedestrian crossing requests.
8. Handling of emergency vehicle pre-emption.
9. Intersection control in response to manual override commands.
10. Intersection control in response to remote override commands.
11. Management of traffic history and incident log databases.
12. Handling of maintenance access requests from the maintenance port.
13. Handling of maintenance access requests from the DOT WAN.
6.2.4 User Characteristics
6.2.4.1 Pedestrians
General population, including persons with disabilities.
6.2.4.2 Motor Vehicle
Automobiles and trucks, depending on roadway use limitations.
6.2.4.3 Traffic Regulatory Personnel
Authorized DOT, police, or other personnel trained in use of the Manual Override
console. Must have key to the system enclosure.
6.2.4.4 System Administrators
Authorized DOT personnel with training in the use of this system.

6.2.5 Constraints
System Constraints include the following:
1. Regulatory policy (e.g., ADA).
2. DOT specifications.
3. Local ordinances.
4. Hardware limitations.
5. Minimum time for pedestrian to cross.
6. Minimum stopping distance for vehicles.
7. Momentary power droops/outages.
8. Interfaces to other applications.
9. Audit functions.
10. Higher-order language requirements (OO language supported by RTOS
required).
11. Network protocols (e.g., SNMP).

146
12. Reliability requirements.
13. Criticality of the application.
14. Security considerations.
15. Safety considerations.
6.2.6 Assumptions and Dependencies
1. SI units are used for all physical quantities.
2. Commercially available RTOS is used.
3. Hardware interfaces have resource managers (drivers) already developed and available
for integration with the software system specified here.
4. DOT WAN will use SNMP to communicate with intersection control system.
5. Watchdog circuitry forces safe default intersection state through hardware.
6.3 Specific Requirements (funcional requirements)
This section describes the basic functional elements of the intersection control system. In
particular, the software object model is described in detail, with attributes and methods
enumerated. External interfaces to users, hardware, and other software elements are
described, and background on the adaptive algorithm to be used is provided.


147
6.3.1 User Interfaces

Figure 8.3: Top-level use-case diagram

1. Vehicle Presence Detector User: Motor Vehicle
2. Pedestrian Presence Detector User: Pedestrian
3. Emergency Vehicle Override User: Emergency Vehicle
4. Manual Override User: Traffic Control Officer
5. Remote Override User: DOT Officer
6. Maintenance Interface User: Maintainer
6.3.2 Hardware Interfaces
1. Vehicle
2. Pedestrian crossing pushbutton
3. Traffic standard
4. Walk signal
5. Hardware watchdog
6. Uninterruptible power supply

148
6.3.3 Software Interfaces
1. RTOS API calls.
2. Hardware resource manager interfaces.
6.3.4 Communications Interfaces
1. Interface to RTOS TCP/IP stack.
6.4 Classes/Objects
Figure 8.4 depicts the classes constituting the intersection control system software
application.


Figure 8.4: Preliminary intersection controller class diagram

6.4.1 Intersection Controller
The Intersection Controller is responsible for managing the following functions:
1. Initialization.
2. Instantiation of contained objects.
3. Control of the intersection vehicle traffic standards.
4. Control of the intersection pedestrian traffic standards.
5. Collection and processing of traffic history from all approaches.
6. Adaptive control of intersection timings in response to traffic flow.
7. Actuated control of intersection in response to vehicle presence.

149
8. Timed control of intersection in response to a fixed scheme.
9. Handling of pedestrian crossing requests.
10. Handling of emergency vehicle pre-emption.
11. Intersection control in response to manual override commands.
12. Intersection control in response to remote override commands.
13. Management of traffic history and incident log databases.
14. Handling of maintenance access requests from the maintenance port.
15. Handling of maintenance access requests from the DOT WAN (wide area network).
Table 2 below illustrates the attributes, methods, and events of the Interface
Controller class and Figure 8.5 illustrates the controller functional sequencing.


Figure 8.5: Statechart for intersection controller sequence

Table 2 Intersection controller class
Intersection Controller
Name Description
Atributes Approaches Array of approach objects
Manual override Represents the Manual
Override console.
Remote Override Represents the Remote
Software console.
Traffic History Contains the traffic history
for up to at least seven
(7) days.
Incident Log Contains the incident log for
up to at least seven
(7) days.
Network Interface Object that provides an
interface from the Network

150
resource manager (driver) to
the Intersection
Controller object.
Emergency Vehicle
Interface
Object that provides an
interface between the
Emergency Vehicle
transponder and the
Intersection Controller
object.
Mode Current operating mode of
the Intersection
Controller.
Priority Relative priority of the
approaches.
Cycle Time Time to complete a full
traversal of all intersection
phases.
Splits Array of numbers defining
the fraction of the cycle
time allocated to each
phase.
Current Phase Current intersection phase.
Phase Time Remaining Time remaining until the
intersection moves to the
next phase in the sequence.
Commanded Green
Signal Safety Relay State
Based on the Current Phase,
this attribute holds the
value required for the Green
Signal Safety Relay
resource manager, which is
responsible for driving
the relay.
Detected Green Signal
Safety Relay State
This holds the actual state of
the Green Signal
Safety Relay.
Methods Inicialize
Advance Phase Advance the intersection
phase to the next phase in
the sequence.
Calculate Cycle
Parameters
Calculates the cycle time
and splits for the next
cycle based on traffic data.
Events Phase Time Remaining
Value Reaches 0
Fires when the Phase Time
Remaining timer
reaches 0.
Override Activated Fires when either the
Manual Override or Remote
override is activated.
Override Canceled Fires when Overrides are

151
deactivated.
Watchdog Timeout Fires on a watchdog trip.
Error Fires when an error occurs.
Takes the Error code is a
parameter.


Figure 8.6: Traffic standard aspects for each phase


152
6.4.2 Approach
This is the programmatic representation of an intersection approach.
The Approach object is responsible for managing the following functions:
1. Instantiation of contained objects.
2. Control of the traffic standards associated with the approach.
3. Handling of pedestrian crossing events.
4. Handling of loop detector entry and exit events.
5. Tracking the vehicle count.
Table 3 below illustrates the attributes, methods, and events of the Approach class.

Table 3 Approach class
Aproach
Name Description
Atributes Pedestrian Traffic Standard Object representing the two
pedestrian traffic
standards associated with
the approach.
Vehicle Traffic Standards Object representing the two
vehicle traffic
standards associated with
the approach.
Pedestrian Service Button Object representing the two
pedestrian service
pushbuttons associated with
the approach.
Vehicle Presence Detector Object representing the
proximity detection
loop, located at the stop
line, associated
with the approach.
Vehicle Count Count of vehicles passing
through the
approach.
Indication Array used to store the
indications actually
being displayed on all
associated traffic
standards.
Current Aspect Current commanded aspect
corresponding to
the Intersection Controller
phase.
Speed Limit Value (in km/h) of the speed
limit associated
with the approach.
Methods Set Aspect Set the displayed aspect to
the Commanded
Aspect.

153
Get Aspect Get the actual displayed
aspect based on
signals from the current
sensor hardware
resource manager.
Increment Count Increase the vehicle count
by 1.
Reset Count Reset the vehicle count to 0.
Events Pedestrian Request Fires when a pedestrian
request has been
made.
Vehicle Entry Fires when the loop detector
detects vehicle
entry.
Vehicle Exit Fires when the loop detector
detects vehicle
exit.
6.4.3 Pedestrian Traffic Standard
This is the programmatic representation of a pedestrian crossing signal.
The Pedestrian Traffic Standard object is responsible for managing the following
functions:
1. Displaying the commanded indication aspect from the Approach.
2. Determining the indication actually displayed.
Table 4 below illustrates the attributes, methods, and events of the Pedestrian Service
Button class.
Table 4 Pedestrian traffic standard class
Pedestrian traffic standard
Name Description
Atributes Commanded Aspect Commanded aspect from
the Intersection
Controller.
Methods Set Indication Set the displayed indication
to the
Commanded Indication.
Get Indication Get the actual displayed
indication based
on signals from the current
sensor
hardware resource manager.

6.4.4 Vehicle Traffic Standard
This is the programmatic representation of a vehicle traffic signal.
The Vehicle Traffic Standard object is responsible for managing the following
functions:
1. Displaying the commanded aspect from the Intersection Controller.

154
2. Determining the aspect actually displayed.

Table 5 below illustrates the attributes, methods, and events of the Vehicle Traffic
Standard class.
Table 5 Vehicle traffic standard class

Vehicle Traffic Standard
Name Description
Atributes Commanded Aspect Commanded aspect from
the Intersection
Controller.
Methods Set Indication Set the displayed indication
to the Commanded
Indication.
Get Indication Get the actual displayed
indication based on
signals from the current
sensor hardware
resource manager..

6.4.5 Pedestrian Service Button
This is an object representing the set of pushbutton consoles located on opposite sides of
the crosswalk associated with an approach. The Pedestrian Service Button object is
responsible for managing the following functions:
1. Filtering of pushbutton service requests.
2. Generation of Pedestrian Service Request event.
Table 6 below illustrates the attributes, methods, and events of the Pedestrian Service
Button class.

Table 6 Pedestrian service button class

Pedestrian Service Button
Name Description
Atributes Request Masked Indicates whether pedestrian
service
pushbutton signals should
be ignored or
processed.
Request State Indicates whether or not a
pedestrian service
request is active.
Methods Set Request State In response to a signal from
the pushbutton
hardware resource manager,
determine
whether or not to modify the
Request State

155
and raise an event.
Reset Request State Clear the Request State.
Ignore Request State Masks subsequent
pedestrian button
operations
Listen Request State Respond to subsequent
pedestrian button
operations.
Events Pedestrian Service Request Indicates that a valid
pedestrian service
request is active.
6.4.6 Vehicle Presence Detector
This is an object representing the proximity detection loop located near the stop line
associated with an approach. The object class is based on the Pedestrian Service Button
class. The Vehicle Presence Detector object is responsible for managing the following
functions:
1. Filtering of vehicle service requests (ACTUATED mode).
2. Generation of Vehicle Service Request event (ACTUATED mode).
3. Maintenance of the vehicle count statistic (FIXED, ACTUATED, and ADAPTIVE
mode).

Table 7 below illustrates the attributes, methods, and events of the Pedestrian
Service Button class.

Table 7 Vehicle presence detector class
Vehicle Presence Detector
Name Description
Atributes Request State Indicates whether or not a
vehicle service request is
active (ACTUATED mode).
Methods Set Request State Set the Request State.
Reset Request State Clear the Request State.
Events Vehicle Entry Indicates that the detector
loop is occupied.
Vehicle Exit Indicates that the detector
loop is no longer occupied.
6.4.7 Manual Override
This is an object representing the set of pushbuttons on the manual override console.
The Manual Override object is responsible for managing the following functions:

1. Triggering the appropriate mode change.
2. Generation and handling of events required to control intersection phase.

Table 8 below illustrates the attributes, methods, and events of the Manual Override
class.

156
Table 8 Manual override class
Manual Override
Name Description
Atributes None None
Methods None None
Events Override Activated Fires when the override is
activated.
Override Canceled Fires when the override is
deactivated.
Advance Phase Fires in response to the
ADVANCE button on the
override console being
pressed.
6.4.8 Remote Override
This is an object representing the commands available on the Remote Software console.
Additionally, the object provides an interface for remote access to and update of
intersection traffic data and cycle parameters for coordinated intersection control (option).
The Remote Override object is responsible for managing the following functions:
1. Triggering the appropriate mode change.
2. Generation and handling of events required to control intersection phase.
Table 9 below illustrates the attributes, methods, and events of the Remote Override class.

Table 9 Remote override class
Remote Override
Name Description
Atributes None None
Methods Process Command Processes the events
generated by the object,
modifying the appropriate
attribute or calling the
appropriate method of the
Intersection Controller
object.
Get Status Retrieves the all parameter
and other status data used
as inputs to the Calculate
Cycle Parameters
adaptive control algorithm.
Set Parameters Sets the cycle timing
parameters as calculated by
the remote host.
Events Override Activated Fires when the override is
activated.
Override Canceled Fires when the override is
deactivated.
Advance Phase Fires in response to the
ADVANCE command from

157
the Remote Software
console.
6.4.9 Emergency Vehicle Interface
This is an object that manages the wireless transponder interface to authorized emergency
vehicles and accesses the Intersection Control object in order to display the correct traffic
signals, allowing the emergency vehicle priority access to the intersection.
The Emergency Vehicle Interface object is responsible for managing the following
functions:
1. Triggering the appropriate mode change.
2. Reception of emergency vehicle preemption requests.
3. Decryption and validation of emergency vehicle preemption requests.
4. Generation and handling of events required to control intersection phase.
Table 10 below illustrates the attributes, methods, and events of the Emergency
Vehicle Interface class.

Table 10 Emergency vehicle interface class

Emergency Vehicle Interface
Name Description
Atributes None None
Methods None None
Events Preempt Activated Fires when preemption is
activated.
Preempt Canceled Fires when preemption is
deactivated.
Preempt Timeout Fires when the preempt
cancellation timeout interval
expires.

6.4.10 Network Interface
This is an object that manages communication via the Ethernet port.
The Network Interface object is responsible for managing the following functions:
1. Routing control messages to the appropriate objects.
2. Transferring traffic history and incident log data.
3. Management of maintenance operations.
Table 11 below illustrates the attributes, methods, and events of the Network
Interface class.
Table 11 Network interface class
Network Interface
Name Description
Atributes None None
Methods Process Message Analyzes and routes
network messages.
Receive Message Receive network messages.

158
Send Message Sends network messages.
Events None None
6.4.11 Traffic History
This is an object that manages the stored traffic history.
The Traffic History object is responsible for managing the following functions:
1. Storage and retrieval of traffic history database records.
2. Clearing of traffic history in response to a command from a remote host.
Table 12 below illustrates the attributes, methods, and events of the Traffic History
class.
Table 12 Traffic history class
Traffic History
Name Description
Atributes
Record An array of structures, each of which
holds a
single traffic history record.
First Record Index of the first active record.
Last Record Index of the record most recently
added.
Record Pointer Index used to sequence through the
Traffic
History records.
Methods
Write Record Writes a database record at the
current position
or at a specified position.
Read Record Reads a database record at the
current position or
at a specified position.
Move Record Pointer Moves record pointer as specified.
Clear Database Returns the database to an empty
state.
Events
EOF Fires when the last record is reached.
Database Full Fires when all allocated space for the
database is
used. Since the database is a FIFO
structure,
records will begin to be overwritten.
6.4.12 Incident Log
This is an object that manages the stored incident log.
The Incident Log object is responsible for managing the following functions:
1. Storage and retrieval of incident log database records.
2. Clearing of incident in response to a command from a remote host.
Incidents are generated by the following events:
1. Error conditions.
2. Traffic History database full.
3. System resets.
4. Mode changes, including emergency vehicle preempts.
5. Maintenance actions, as updated by maintenance personnel through portable
test equipment (laptop).
Table 13 below illustrates the attributes, methods, and events of the Traffic History
class.

Table 13 Incident log class

159

Incident Log
Name Description
Atributes
Record An array of structures, each of which
holds a
single traffic history record.
First Record Index of the first active record.
Last Record Index of the record most recently
added.
Record Pointer Index used to sequence through the
Traffic
History records.
Methods
Write Record Writes a database record at the
current position
or at a specified position.
Read Record Reads a database record at the
current position or
at a specified position.
Move Record Pointer Moves record pointer as specified.
Clear Database Returns the database to an empty
state.
Events
EOF Fires when the last record is reached.
Database Full Fires when all allocated space for the
database is
used. Since the database is a FIFO
structure,
records will begin to be overwritten.
6.5 Performance Requirements (non functional
requirements)
6.5.1 Timing Requirements
6.5.1.1 Summary
Table 14 Software timing requirements
Id Designation Applies to
Model(s)
Object/From Event Object/To Response Min
time
(ms)
Max
time
(ms)
1 Initialization All Hardware/Reset Signal Intersection
Controller/Initialization Complete
- 4900
2 Set Default Phase All Intersection
Controller/Initialization Complete
All Traffic
Standards/Display of
commanded phase
- 100
3 Start Normal
Operation
ACTUATED
ADAPTIVE
TIMED
Intersection
Controller/Initialization
Complete
All Traffic
Standards/Display of
Phase 1
- 500
4 Advance
Phase Normal
ACTUATED
ADAPTIVE
TIMED
Intersection
Controller/Phase Time
Remaining Reaches 0
All Traffic
Standards/Display of
Commanded Phase
100
5 Advance Phase
Local
LOCAL
MANUAL
Manual Override/Receipt of
Advance Phase signal
from Manual Override
Panel
All Traffic
Standards/Display of
Commanded Phase
100
6 Advance
Phase Remote
REMOTE
MANUAL
Remote Override/Receipt of
Advance Phase signal
from Network Interface
All Traffic
Standards/Display of
Commanded Phase
100
7 Calculate Cycle
Parameters
Actuated
ACTUATED Pedestrian Detector or
Vehicle Detector/
Pedestrian Request signal
- or - Vehicle Request
signal
Intersection
Controller/Cycle Time
and Splits updated
100
8 Calculate Cycle
Parameters
Adaptive
ADAPTIVE Intersection Controller/Start
of last phase in cycle
Intersection
Controller/Cycle Time
and Splits updated
250

160
9 Critical Error
Display
Defaults
All Any/Critical Error All Traffic
Standards/Display of
Default State
50
10 Critical Error
Alarm
All Any/Critical Error Network Interface/Initiation
of Alarm Transmission
1000
11 Critical Error
Reset
All Any/Critical Error Intersection
Controller/System reset
4500 5000
12 Write Error Log All Any/Any Error Incident Log/Write
completed
500
13 Set Phase ACTUATED
ADAPTIVE
MANUAL
REMOTE
Intersection
controller/Advance phase
All Traffic
Standards/display
commanded phase
100
14 Get Phase ACTUATED
ADAPTIVE
MANUAL
REMOTE
Intersection controller/Get
phase
Intersection
Controller/Displayed
phase determined
150
15 Check Phase ACTUATED
ADAPTIVE
MANUAL
REMOTE
Intersection
controller/Check phase
Intersection
Controller/Phase check
status returned
10
16 Pedestrian
Request
Latching
ACTUATED
ADAPTIVE
TIMED
Resource
Manager/Pedestrian
Request signal
Pedestrian
Detector/Latching of
Pedestrian
DetectorPending state
10
17 Pedestrian
Request
Reset
ACTUATED
ADAPTIVE
TIMED
Intersection
Controller/Completion of
phase(s) during which
pedestrian requests may
be accepted
Pedestrian Detector/Clearing
of Pedestrian
DetectorPending state
100
18 Pedestrian
Request
Processing
ACTUATED
ADAPTIVE
TIMED
Pedestrian
Detector/Latching of
Pedestrian
DetectorPending state
Intersection
Controller/Updating of
cycle time for next two
(2) cycles; Updating of
all splits for next two (2)
cycles.
100
19 Vehicle Entrance FIXED
ACTUATED
ADAPTIVE
Resource manager/Vehicle
Entry signal
Vehicle Detector/Vehicle
Entry state set
10
20 Vehicle Exit FIXED
ACTUATED
ADAPTIVE
Resource manager/Vehicle
Exit signal
Vehicle Detector/Vehicle
Entry state cleared
10
21 Vehicle Request
Processing
FIXED
ACTUATED
ADAPTIVE
Vehicle Detector/Entry State
set
Intersection
controller/process vehicle
request
100
22 Vehicle Reset
Request
State
ACTUATED
ADAPTIVE
Intersection controller/reset
vehicle request state
Vehicle Detector/Clear
vehicle entry state
100
23 Vehicle Count
Update
FIXED
ACTUATED
ADAPTIVE
Vehicle Detector/Entry State
cleared
Approach/Bump count 50
24 Vehicle Count
Fetch
FIXED
ACTUATED
ADAPTIVE
Intersection controller/Get
Count
Intersection
Controller/Count returned
100
25 Vehicle Count
Reset
FIXED
ACTUATED
ADAPTIVE
Intersection controller/Phase
change
Approach/Reset count 100
26 Get Cycle
Parameters
REMOTE Remote Override/Parameter
request
Network interface/Packet
ready to send
100
27 Update Cycle
Parameters
REMOTE Remote Override/Parameter
update
Intersection
controller/Parameters
updated
100
28 Process
Message
EMERGENCY
PREEMPT
Emergency Vehicle
Interface/Activate
Intersection controller/Mode
changed
200
29 Process
Command
EMERGENCY
PREEMPT
Emergency Vehicle
Interface
Intersection
controller/emergency
vehicle operations
100
30 Process
Message
REMOTE Remote operations Intersection
controller/Network
Interface
200
31 Fetch Database REMOTE Remote operations Intersection
controller/Network
Interface
1000

161
32 Add Record FIXED
ACTUATED
ADAPTIVE
Intersection controller Traffic History 200
33 Clear Database FIXED
ACTUATED
ADAPTIVE
Intersection controller Traffic History 200
34 Add Record FIXED
ACTUATED
ADAPTIVE
Intersection controller Incident Log 200
35 Clear Database FIXED
ACTUATED
ADAPTIVE
Intersection controller Incident Log 200
Notes:
[1] The timing requirements for vehicle detection are based on the following
considerations:
Minimum vehicle length = 8 ft
Minimum following distance in motion = 4 ft
Loop width = 4 ft
Loop detects entrance with leading overlap = 2 ft
Loop detects exit with trailing overlap = 1 ft
Maximum vehicle speed = 65 mph(= 95.3 ft/s)
Vehicle speed for minimum gap time (see below) = 10 mph (= 14.67 ft/s)
Minimum presence pulse width = 9 ft/95.3 ft/s = 94.4 ms
Minimum gap time (time between exit and next vehicle entrance) = 3 ft/14.67 ft/s = 204.5
ms
This is illustrated in figure 8.7 and 8.8 below.

Figure 8.7 Minimum presence pulse wildth

162


Figure 8.8: Minimum gap pulse width

It is necessary to determine the speed at which the minimum gap time between vehicles
occurs in order to determine that time. The distance a following vehicle must cover in
order to trigger the loop detector after the leading vehicle has exited is given by

Given this, the gap time given by

It can be shown that the minimum gap time occurs for v = 10 mph
Part two: Using TCTL formalism with UPPAAL tool
Functional requirements (8.3 Specific Requirements) are statements of services the system
should provide, how the system should react to particular inputs and how the system

163
should behave in particular situations. In some cases, the functional requirements may also
explicitly state what system should not do.
Non-functional requirements (in our case 8.5 Performance Requirements) are requirements
which are not specifically concerned with the functionality of a system. They place
restrictions on the product being developed and the development process, and they specify
external constraints that the product must meet. Non-functional requirements include
safety, security, usability, reliability and performance requirements.
To reach those properties we utilize a subset of TCTL formalism which is accomplished
with the Uppaals property specification language.
Functional requirements were compared one by one, using matrix, to eliminate
redundancies, links and conflicts between them. With regard to non-functional
requirements was a cross functional requirements versus matrix with the same objective.
To create the automatons that will resolve above mentioned requirements we use the
UMLs statechart tool figure 8.5.

The Trafic-Ligth- system will have the following modes: Simple Temporized Mode,
Emergency, Manual and the Adaptive Mode Emergency Manual Pedestrian Request.

For the construction of this system is taken into account that the lights should
operate under one of two main modes of operation for all
a regular cycle, being only possible to change one another (simple timed
to adapt or vice versa) in the transition period the end of a cycle and the beginning of
a new one.
That is, prior to the start of each cycle, the system shall consult with the
console mode type under which to operate the system at the begining of the new cycle.
This introduces a necessary modification in the automaton that represents all
sensors, since during the operation of the system under simple timed mode
this automaton should not exist. For this reason, as we shall see, have
made the necessary changes so that when the traffic lights that operate under
that modality, the sensor automaton remains in the same location, and not interact with
other automatons. Another important change is that, in order that the system does not
exchange operating mode during the same cycle phases were differentiated most
of locations that refer to the types of interruptions common to both modes:
emergency mode and manual mode. The latter implies that in the three automata more
important, i.e. Modos_Semaforo, Unidad_Central and Fases_Semaforos, there are separate
location flows in the case of simple timed operation
or adaptive mode.
6.5.2 Timed automatons
There are considered seven automatons for the system which are:
6.5.2.1 Semaphore_Modes Automaton
This automaton represents the Trafic Ligth control algorithm to govern the
intersection. It has an initial location, Idle (common in all simulated systems
so far) and a central location: traffic light. The automaton stays in
this location during the entire cycle if it is regular (so without interruptions), and in

164
general, for most of the time of a cycle is not regular. As explained
next, this automaton has additional locations, which are:
- Idle: Initial location by default
- CPUMA: Location reached by the automaton as long as the remote console has
been ordered the activation of adaptive mode.
- CPUMTS: Location reached by the automaton as long as the remote console has
been ordered the activation of Simple-Temporized- Mode.
- timed_on: Location reached by the automaton, after being in CPUMTS. By the
synchronization corre_reloj!, the internal control of traffic lights system confirms
the console that is ready to begin a simple timed cycle.
- sensor_ready: Location reached by automaton, after being in CPUMA. By
synchronization corre_reloj_adaptive!, the internal control of traffic lights system
confirms the console that is ready to begin a simple timed cycle.
- adaptive_on: this location is reached by the automaton only if the system is
going to operate in adaptive mode, after being sent respective synchronization
(sensor_available!) to Sensor, for the activation of the group of sensors.
- traffic_light: main location acceded by the automaton, just before the
Traffic-Ligth-System(TLS) phase cycle begin (whether under timed simple or
adaptive mode) The automaton will remain in that location during
the entire traffic light cycle provided there are no interruptions, otherwise,
depending on the source of disruption, changes to any of the locations that
mentioned below.
- manual_handle: The automaton changes to this location when he entered the
system interruption by manual traffic controller. Depending on the main mode in
which the system is operating until the time of admission to the interruption, the
synchronization needed to reach this location is different: traffic_controller_ts? and
traffic_controller_adp?. Has required the creation of these two ways of achieving
the same location, to identify the mode under which the system is operating at the
time of the interruption.
- manual_on: Location reached by the automaton once the cycle where the traffic
manual control signal entered has been completed, and after the internal control get
synchronization of TLC override_tl?, which gives pass to manual operation of the
traffic light, canceling all control exercised by the remote console.
- emerg_on: Location reaching the automaton when the system, while operating
under the adaptive mode, at a given instant in the cycle of phases, supported by the
transponder interruption of any emergency vehicle. The timing transponder adp? is
sent by the remote console, then the latter has received the signal from the
transponder.
- emerg_on_ts: Like the previous location, with the difference that the
automaton reached it when the system has been operating under the simple
temporized mode, and occurring disruption of emergency vehicle transponder.
- handling_emerg: Location reached by automaton Modos_semaforo when
synchronizes with Fases_semaforo through emerg_handle_adap! To proceed
responding the request for preferential treatment of an emergency vehicle. It is
worth noting that this is true for the case where the system was operating under
adaptive mode.
- handling_emerg_ts: Like the before location, but for the case in which the
system was operating under simple temporized mode.

165
- sensor_off: This location is reached when the internal monitoring of traffic
light sends the signal corresponding to the group of sensors to interrupt their
normal operation since the traffic light cycle has been altered by
incoming emergency.
- emerg_end: The automaton achieves this location once the emergency has been
attended (in any of the two main modes), and the traffic lights has changed to the
stage that allows the vehicle that triggered the transponder, continue their march
without further delay for the intersection.

- push_pedestrian: Location reaching the automaton when operating under the
adaptive mode, enter the corresponding interrupt request to the attention of
pedestrians. The remote console internal notifies to internal control of the traffic
lights of this interruption by synchronizing pedst_handle?.

- not_allowed_push: This location is reached by the automaton only when the
pedestrian application interruption occurred at a stage that does not match (different
from phase 1 and 5). Synchronization with the automaton
Phases_semaforo_es_wrong?.

- handling_req: The automaton achieves this location after receiving
the synchronization pedestrian? by the Fases_semaforo in order to lengthen
the time of the pedestrian crossing phase in which the disruption was triggered by
pedestrian request.

- sensor_idle: This location is reached when the pedestrian application has
been attended on time, and long time of the concerned phase has expired.
This latter is done by synchronizing req_handled!
between Modos_semaforo and the automaton request.

- req_end: This is the location that reached automaton
after the internal control traffic light sends a signal to all sensors (block_sensor!)
for cease to operate due to the regular cycle disorder introduced by
interruption of pedestrian request.
6.5.2.2 Central_Unit Automaton
This second automaton represents the remote console which interact directly with the
traffic light control algorithm. As the automaton described above, the operating logic of the
Central_Unit in the final system built, is very similar to that explained in more simplified
systems. He has also been necessary to add various locations with respect to the version of
the same automata in the final simulated system, in order to differentiate the flow of
transitions that takes place in this automaton, as the main mode of operation: simple or
temporized adapative . Finally, this automaton as a new feature also includes the addition
of two particular locations that are related to the operation of all sensors. As you know, in
simple timed not need such a set of sensors, so the system while operating under this mode,
you must ensure there is no synchronization whatsoever with the sensor automaton. In total
this automaton has 35 locations, which are detailed below succinct manner:


166

Figure 8.9: Semaphore_Modes Automaton
- Master: initial location by default.
- sensor_ts: Automaton reaches this location when trigger notification
remote_console1! which will be received by Modos_semaforo, and indicates that
the system operates under simple temporized mode.
- sensor_adp: Automaton reaches this location when trigger notification
remote_console2! which will be received by Modos_semaforo, and indicates that
the system operates under adaptive mode.
- adaptive: This location is reached by the automaton after it has sent
the activation signal for the sensor array, so that these
can participate in the phase cycle that is about to begin.
- Timed: Unlike the previous location, the automaton reaches this location
provided the phase cycle is about to start is under the simple temporized mode, and
therefore, by synchronizing kick out! avoids Sensor automata that interact with
other automata of the system.
- activating_sensor: This is the main location of Central_Unit, and it
reaches after remote console sends signal to the TLS indicating that it can begin the
regular cycle, as a main mode that was previously established (simple temporized
or adaptive).
- manual: Location reaching the automaton when, being the system operating
under adaptive mode, the remote console controller receives the signal from
manual traffic, which means that at the end of the current cycle, the TLS will stop
be operated automatically.
- manual_ts: Like the former location, the difference is that it is reached when
the system have been interrupted during his operation under simple temporized
mode.
- manual_alert_tl: Location reaching the automaton, when, being
operating under the adaptive mode, and after the occurrence of the interruption by

167
manual traffic controller, the remote console notifies the internal control
by synchronizing traffic lights traffic_controller_adp!.
- manual_alert_tl_ts: Location reaching the automaton, when, being
operating under the simple temporized mode mode, and after the occurrence of the
interruption by manual traffic controller, the remote console notifies the internal
control by synchronizing traffic lights traffic_controller_ts!.
- override_prepare_emerg: Automaton reaches this location when the TLS
notifies the finish of the cycle phases (under adaptive mode) to the remote console,
through synchronization ciclo_fin_adp?
- override_prepare_emerg_ts: Automaton reaches this location when the
TLS notifies the finish of the cycle phases (under simple temporized mode) to the
remote console, through synchronization ciclo_fin_ts?
- override_prepare_req: Location reaching the automaton, while the
system operating under the guise adpater in the transition from one cycle just
and a new one, when you disable the interruption of the emergency mode, so
that can be reset at the start of next cycle.
- override: This location plays a role similar to the previous one, with the
difference this is reached after the interruption disable application mode
pedestrian, so it can be reset in the next cycle.
- override_ts: This location serves the same function as the location
override_prepare_req, only for the case where the TLS has been
operating the cycle just under the simple temporized mode.
- emergency: Location reaching the automaton, when still operating under
adaptive mode transponder receives the signal from the emergency vehicle.
This is symbolized by the synchronization: signal_transp_adp?.
- emergency_ts: Location reaching the automaton, when being operated
under the simple temporized mode receives the signal from transponders
emergency vehicle. This is symbolized by synchronizing: signal_transp_ts?.
- processing_emerg: Being operating the system under the adaptive mode,
this is the location that reaches the automaton when the remote console notifies of
the incoming emergency to the internal control of TLS, by synchronization
transponder_adp!.
- processing_emerg_ts: Being operating the system under the simple
temporized mode, this is the location that reaches the automaton when the remote
console notifies of the incoming emergency to the internal control of TLS, by
synchronization transponder_ts!.
- cycle_end_emerg: This location is reached when just cycle phases
adaptive mode in which the interruption occurred by the transponder of
emergency vehicle.
- cycle_end_emerg_ts: This location is reached when the phase cycle ends
the simple temporized mode in which the interruption occurred by the
emergency vehicle transponder.
- reactivate_manual: Location when it reaches the synchronized automaton
with EmergVehicle to disable the interruption of the emergency mode, so that can
be re-enabled at the start of next cycle.
- Reactivate_pedestrina_req: Idem as above, but this is achieved
after Central_unit synchronized with Solicitud to disable

168
interrupt request as pedestrian, so it can be enabled again
at the beginning of the next cycle.
- pedestrian_request: Location reaching the automaton when he entered the
application interruption pedestrian attention.
- checking_req: The automaton changes to this location after notifying the
internal control of the TLS the entrance of the pedestrian request, by
synchronization pedst_handle!. In this location the automaton have to decide
whether continues with the attention of the interruption, or otherwise, if he enter
a phase that does not match, reject it and return to the main location
activating_sensor.
- req_cycle_end: Having attended the request pedestrian semaphore
synchronized with the remote console to notify the end of a cycle of phases, and
reaches this location.
- end_to_manual: Location reaching the automaton after sending the
synchronization to disable interruption manual mode for
to be re-enabled in the next cycle.
- end_to_emerg: Idem as above, but applies to disable the
disruption of emergency mode.
- cycle_end_1: Location reaching the automaton if the cycle phases
light has passed normally, without interruption of any kind,
having operated under the simple temporized.
- emerg_again_1: Similar to the previous location, which the automaton reaches
when synchronized with EmergVehicle to disable the interrupt mode
emergency, at the end of a regular cycle of phases.
- cycle_end_2: Similar location to cycle_end_1 with the difference that this is
reached when the system is operating under the adaptive mode.
- manual_again_2: Like the previous location, the difference
with manual_again_1 is that this is achieved when the system operates under
mode adaptive.
- pedestrian_req_again: This location is reached by the automaton when it
completed a regular cycle, and should disable the interrupt request
pedestrian to be enabled to return in the next cycle. This sends the
wait sync req! to automaton Solicitud.

6.5.2.3 Semaphore_Phases Automaton
This automaton represents the physical phases of TLS, plus some intermediate position
depending on the break to enter the system. Similar to the two automata described above,
Semaphore_Phases has several additional locations, which have their origin in the intent to
clearly differentiate the two main modes of operation of the system. This distinction is
reflected primarily in the pre-start of the 8 stages (stage interrupt enable), and in the
aftermath of the elapsed time of phase 8, during the transition to the beginning of a new
cycle (disabling interruptions to be re-enabled at the beginning of the next cycle). In total,
this automaton, in its final version, has 41 locations, which are:

- Idle: Initial location of the automaton by default.

169
- receiving_calc: Location reaching the automaton, when the system will
operate under adaptive mode, and get confirmation of Semaphore_Modes via
synchronization corre_tl_adp?.

Figure 8.10 Central_Unit Automaton
- prepare_manual_ts: Similar to the previous location, but is achieved by
the automaton when the TSL receiving confirmation from the internal control, to
start a cycle under the simple temporized mode through
synchronization corre_ts_tl?.
- Prepare_emerg_ts: Location reaching the automaton, when synchronizes with
Officer in order to enable the interruption by the hand traffic controller
on the cycle of phases under simple temporized mode that is ready to begin.
- Prepare_emerg_adp: Similar location to prepare_emerg_ts, with the difference
that this corresponds to the stage after a cycle under the adaptive mode.
- Prepare_req: Location reaching the automaton after it has been enabled
disruption by the emergency vehicle transponder that can
ask for preferential treatment at any time regular cycle phases.
- Ph1: This location represents phase 1 of the TSL and the automaton reaches
either when the interrupt is enabled by the pedestrian application request attention
(If the system will start a cycle under adaptive mode), or after
enabled to interruption of the emergency mode (cycle is low to begin
simple temporized).
- Ph2: Represents the phase 2 of the TLS.
- Ph3: Represents the phase 3 of the TLS.
- Ph4: Represents the phase 4 of the TLS.
- Ph5: Represents the phase 5 of the TLS.
- Ph6: Represents the phase 6 of the TLS.
- Ph7: Represents the phase 7 of the TLS.
- Dealing1: Intermediate location in order to accommodate the jump location
necessary when the system has entered the sign of a transponder

170
emergency vehicle requesting preferential attention. It corresponds to
Phases 1, 2, 3 and 4.
- Dealing2: Idem as above, but this is for the attention of the
emergence from Phases 5, 6, 7 and 8.
- Req_handle1: Similar location to dealing1, and serves to process the attention of
pedestrian application interruption, corresponding to the case where the interruption
has entered phase 1.
- Req_handle2: Similar location to dealing2, and serves to process the attention of
pedestrian application interruption, corresponding to the case where the interruption
has entered phase 5.
- Hold_ph2: Intermediate location reached by the automaton as long as the attention
interruption by pedestrian request is entered wrongly
in Phase 2. To this end, Semaphore_Phases synchronizes with Solicitud by notice
wrong!
- To_ph3: Location that reaches the automaton when has expired
normal time of phase 2, and also sent the synchronization
req_available_again! so that the interrupt request for attention
pedestrian can be re-available.
- Hold_ph3: Location is reached if the interruption to Solicitud pedestrian mode
erroneously entered in phase 3, similar to that explained for the location ph2_hold.
- To_ph4: Similar location to_ph3, which allows re-enable the interruption for the
Solicitud pedestrian mode from the phase 4.
- Hold_ph4: Location is reached if the interruption to solicitud pedestrian mode
pedestrian erroneously entered in phase 4.
- To_ph5: Location allowing to continue with the regular cycle of TLS and which
leads to phase 5, previously habilitation of disruption for the attention of solicitud
pedestrian so it can be re-available.
- Hold_ph6: Location is reached if the interruption to application mode
pedestrian erroneously entered in Stage 6.
- To_ph7: Location leading to the phase 7 to follow traffic light cycle
its course, after re-enable the interrupt request for solicitud
pedestrian.
- Hold_ph7: Location is reached if the interruption to solicitud pedestrian mode
erroneously entered in phase 7.
- To_ph8: Location is reached if the interruption to solicitud pedestrian mode
erroneously entered in step 8.
- To_end: Location reaching the automaton after it has processed
properly rejected the interruption for care solicitud pedestrian
that erroneously entered in step 8. Also, this location is the beginning of the
transition between the cycle that ends and the next that is about to begin.
- Hold_on1: Location reached by the automaton when notifies the remote console
that it has completed a course in adaptive mode.
- Hold_on2: Location reaching the automaton after to turn the interruption by
pedestrian request, so it can be again enabled, along with other interruptions in the
beginning of the next cycle.
- Hold_on3: Idem to the previous location, but off is reached after
disruption of emergency mode.

171
- hold_on1_ts: Idem to the location hold_on_1, the difference is that it is reached by
Semaphore_Phases automaton when he was operating under temporized simple
mode.
- hold_on2_ts: Idem to the location hold_on_2, but this location is reached when the
TLS has been operating under temporized simple mode.
- cycle_sensor: Location that is reached by the automaton when has finished the 8
phases of one cycle in the adaptive mode, and after being synchronized with the
automaton Sensor for the returning to the initial location by default (Idle_sensor)
- loop_adp: Location reaching the automaton, when the system has operated
under the adaptive mode, after the interruption disabled
manual traffic controller, so you can re-enabled in the following
cycle.
- Loop_ts: Like the loop_adp location, but the difference is that is applied in the case
when a cycle under temporized mode has finished.
- Override_on_tl: Location that reaches the automaton after remote console has
cancelled all control over the system; this is symbolized by
synchronization back! between Phases_Semaphore and Central_Unit.
- Tl_again: Location reached by the automaton before the beginning of a new cycle
and after synchronized with Central_Unit.

Figure 8.11: Semaphore_Phases Automaton
6.5.2.4 EmergVehicle Automaton
This automaton represents the transponder of the vehicle that want to cross the intersection
with preferential treatment because of an emergency. The number of locations is
increased to 4, which are described briefly below:
- Idle_transponder: Initial default location of the automaton.
- Active_adp: The automaton reaches this location after Phases_ Semaphore has sent
a synchronization notice emerg_available! In order to habilitate the interruption in
the adaptive phases cycle that is going to begin.

172
- Active_ts: Idem to the previous location, but for one cycle
of phases simple temporized.
- Crossing: The automaton reaches this location, when, still running
under either of the two main modes (simple adaptive or timed)
The transponder sends the signal from the remote console for
preferential treatment of an emergency vehicle. The necessary synchronization
to reach this location varies depending on the mode: signal_transp_adp! for
adaptive mode, and signal transp ts! for the simple temporized mode.

Figure 8.12: EmergVehicle Automaton
6.5.2.5 Sensor Automaton
This is the automaton that represents the group of sensors installed at the intersection,
whose mission is to provide feedback to the traffic light control algorithm, each cycle
phases, with the appropriate data to calculate the precise times to be assigned to all
subsequent phases of the cycle, when the system operates under the adaptive mode.
As a result of previously mentioned in the description of automata
Central_Unit, this automaton has an additional location to the three presented
in previous systems. Therefore, for this final system, Sensor has four
locations:
- Idle_sensor: Initial location of the automaton. Also, when the system
is in normal operation, this location is again reached by the
automata when it has been operating under the simple timed,
must re-operate under adaptive mode. In that case, the synchronization
makes this possible is kick in!.
- Status: The automaton reaches this location when the system has been
operating under the adaptive mode, and for the next cycle, the remote console
decides that you must switch to simple timed. The synchronization
makes possible this "isolation" of the automaton is kick out!.
- Ready: Location reaching the automaton when the set of sensors
is enabled by the TLS before the onset of an adaptive cycle phases
by synchronizing sensor_available?.
- Sensing: This location remains the automaton during the time it
making the traffic lights a regular cycle of phases, without interruption. This
symbolizes the set of sensors by detecting the amount of
vehicles in each phase of the TLS, in order to send the data for the
TLS mode so that the time to allocate in the next cycle are most

173
appropriate under this traffic pattern. If an interruption occurs
during normal development cycle, immediately return to the automaton
location Idle_sensor.

Figure 8.13: Sensor Automaton
6.5.2.6 Officer Automaton
This automaton represents the hand controller that operates a transit officer
authorized when it was decided to cancel all automatic control over the system. Of
similar behaviour to the automaton that represents the emergency vehicle transponder
requesting preferential attention, Officer also has four locations:
- Idle: Inicial location of the automaton
- Ready_adp: Location reaching the automaton when, prior to the start of a
adaptive cycle phases, the semaphore interrupt enable manual mode.
- Ready_ts: Like to the previous location, the only difference is that applies to a
simple temporized cycle phases.
- On: The automaton reaches this location when the traffic officer authorized
choose to manually control the intersection, sending the corresponding signal
to the remote console, at one point for a normal development cycle
of phases simple adaptive or adaptive. As the primary mode of operation of the
system time of the entry of the interruption, the synchronization
makes possible the change of location varies (signal_officer_adp! or
signal_officer_ ts!).

Figure 8.15: Officer Automaton

174
6.5.2.7 Pedestrian Automaton
The latter automaton symbolizes the push button that can trigger such an authorized officer
in order to prolong one of the two phases that allows the pedestrian crossing, in order that
pedestrians have more time to cross through the intersection. This can be justified by the
number of pedestrians that accumulates in one corner of the intersection at a certain time,
or in the absence of any pedestrian who needs help to cross. Unlike
of other automata described in the final system, Pedestrian maintains three
locations mentioned in the above simulated system:
- Idle: Initial default location of the automaton, indicating that the interruption is not
enabled.
- Ready1: Location reaching the automaton once the TLS enable
interrupt of pedestrian request mode, that is before the onset of cycle phases
by synchronizing request_available?. It is also possible to
reach this location when the interruption has entered a phase error,
and then, the automaton should return the location to the location requesting
concerned so that the interruption may occur in any other
instant of the cycle phases.
- Requesting: This location is reached by the automaton when it is
triggered the interrupt request to the attention of pedestrians, and remains in
the duration of the same, i.e. until the expiry of extended time on the phase at
which admitted such interruption.

Figure 8.16: Pedestrian Automaton
The following describes the syntax used for the construction of the system:
6.5.2.8 Channels of Synchronization
- //Adaptive mode channels
chan remote_console2;
chan corre_reloj_adaptive;
chan sensor_available;
chan signal_send;
chan corre_tl_adp;
chan remote_console1;
chan corre_reloj;
chan corre_tl_ts;
chan kick_out;
chan kick_in;
- //Pedestrian request mode channels
chan request_available;
chan req;

175
chan req_handled;
chan pedestrian;
chan pedst_handle;
chan request_end;
chan wait_req;

- //Emergency mode channels
chan emerg_fin;
chan emerg_handle_ts;
chan emerg_handle_adp;
chan transponder_ts;
chan transponder_adp;
chan em;
chan signal_transp_ts;
chan signal_transp_adp;
chan emerg_available;
chan emerg_available_ts;
chan wait_transponder;

- //Manual mode channel
chan traffic_controller_ts;
chan traffic_controller_adp;
chan signal_officer;
chan signal_officer_ts;
chan signal_officer_adp;
chan override_tl;
chan back;
chan manual_available;
chan manual_available_ts;
chan wait_controller;
chan wait_controller_ts;
chan wait_controller_adp;
chan ciclo_fin;
chan ciclo_fin_ts;
chan ciclo_fin_adp;
chan sensor_done;
chan block_sensor;
chan wrong;
chan override_req;
chan req_available_again;
chan ask_console;
chan re_start_tl;
6.5.2.9 Variables
- Automaton Semaphore_Modes
clock t
- Central_Unit
clock u
- Semaphore_Phases Automaton

176
clock x
const int t1 = 20
const int t2 = 10
const int t3 = 5
const int t4 = 3
const int t5 = 20
const int t6 = 10
const int t7 = 5
const int t8 = 3
- Sensor Automaton
clock w
- Officer Automaton
clock f
- Emerg Vehicle Automaton
clock e
- Pedestrian Automaton
clock s
6.5.2.10 Declaration of the System
To formulate the system is used the following syntax:

Modos = Semaphore_Modes(corre_reloj, corre_reloj_adaptive, remote_console1,
remote_console2, corre_tl_ts, corre_tl_adp, sensor_available, pedestrian, pedst_handle,
req_handled, request_end, block_sensor, transponder_ts, transponder_adp,
emerg_handle_ts, emerg_handle_adp, em, emerg_fin, traffic_controller_ts,
traffic_controller_adp, override_tl, signal_officer, wrong, override_req, re_start_tl);

Consola = Central_Unit(remote_console1, remote_console2, corre_reloj,
corre_reloj_adaptive, ciclo_fin, ciclo_fin_ts, ciclo_fin_adp, pedst_handle, req,
wait_req,signal_transp_ts, signal_transp_adp, transponder_ts, transponder_adp,
wait_controller, wait_controller_ts, wait_controller_adp, wait_transponder,
signal_officer_ts, signal_officer_adp, traffic_controller_ts, traffic_controller_adp, back,
req_available_again, kick_out, kick_in, ask_console, block_sensor);

Semaforo = Semaphore_Phases(corre_tl_ts, corre_tl_adp, signal_send, ciclo_fin_ts,
ciclo_fin_adp, pedestrian, request_available, request_end, sensor_done, corre_reloj,
emerg_handle_ts, emerg_handle_adp, em, manual_available, manual_available_ts,
emerg_available, emerg_available_ts, back, override_tl, wrong, req_available_again,
wait_req, wait_transponder, wait_controller_ts, wait_controller_adp, ask_console,
re_start_tl);

Detector = Sensor(signal_send, sensor_available, block_sensor, sensor_done, kick_out,
kick_in);

Preferencial = EmergVehicle(signal_transp_ts, signal_transp_adp, emerg_available,
emerg_available_ts, emerg_fin, wait_transponder);

Controlador = Officer(manual_available, manual_available_ts, signal_officer,
signal_officer_ts, signal_officer_adp, wait_controller_ts, wait_controller_adp);

177
Peaton = Pedestrian(request_available, req. req_handled, wait_req, override_req);

system Modos, Consola, Semaforo, detector, Preferencial, Controlador, Peaton;

6.5.3 Property Verification Using UPPAAL
We built the final system with all possible modes of operation. what follows is the
verification of the properties of the subset of TCTL formalism using the Uppaal verifier.

Making a simple collection of achievements to date, we can distinguish three (03)
milestones in the process:

- Requirements definition phase of the system.
- Initial drafting stage through block diagrams.
- Stage construction and simulation of automata.

Taking into account the above, it is necessary to verify the obtained models have been
functioning as designed, and, above all, the final system, which considers all possible
modes and interrupts the normal operation of TLS, have no possibility of failure. That is,
every time system real must be robust, secure and fault tolerant. So the software is subject
matter of this paper shows that a given system meets various types of properties. Here
then, for the system developed, it exemplifies the contribution of the verifier of the tool.
6.5.3.1 Anti-deadlock
Thre property of the anti-deadlock is that a system must always have a
fully defined and unique response to any set of inputs, or external stimulus. For systems
simulated in the previous section, this property verifies that any transition of states that
always make a new transition rise to well defined and consistent with the desired behavior,
without bringing the system into indeterminacy.
This property is verified using the syntax:

A[]not deadlock
This means: For all possible paths, the system never hang. Whenever this is the biggest of
all the properties to verify, check that applies to each of the simulated systems in the two
previous sections:
- Simple Temporized Mode
- Adaptive Mode
- Simple Temporized Emergency Mode
- Adaptive Emergency Mode
- Simple temporized Manual Mode
- Adative Manual Mode
- Simple Temporized Manual Emergency Mode
- Adaptive Emergency Manual Mode
- Adaptive Emergency Manual Pedestrian Request Mode
- Simple temporized Adaptive Emergency Manual Pedestrian request Mode

The pictures below show just checking "anti-deadlock" for the first 7 systems.

178

Figure 8.17: Simple Temporized Mode never is blocked


Figure 8.18: Adaptive Mode never is blocked

179

Figure 8.19:Simple-Temporized Emergency Mode never is blocked


Figure 8.20: Adaptive-Emergency Mode never is blocked


180

Figure 8.21:Simple Temporized Manual Mode never is blocked

Figure 8.22: Adaptive Manual Mode never is blocked

181

Figure 8.23: Simple temporized Emergency Mode never is blocked

6.5.3.2 Normal length of a regular cycle of TLS -
maximum and minimum
In this section we analyze the maximum length of a regular cycle TLS, is
i.e. one that contains the eight stages with their normal durations. There is an exception,
and that the last two simulated systems: the maximum length of a normal cycle is increased
slightly by the time it extends the phase for the crosswalk, if the authorized officer pressed
the button.In addition, we analyze the minimum duration that can have a cycle, ie when
there is a preferential treatment requested by a vehicle.
For a regular cycle, we have that the normal duration is the sum of time
corresponding to each of the 8 stages. Therefore, working with predefined times of 20, 10,
5 and 3 seconds for each block of 4 stages: T
total
=t
1
+ t
2
+ t
3
+ t
4
+ t
5
+ t
6
+ t
7
+ t
8
=76s.

182

Figure 8.24: Adaptive-Emergency-Manual Mode never is blocked

Figure 8.25: Adaptive-Emergency-Manual Pedestrian Request never is blocked

183

Figure 8.29: Final System never is blocked

This duration may be altered during the cycle happen when two of the three classes
possible interruptions mentioned in the preceding paragraph. So then expressed by
different queries, regarding the duration of a traffic light cycle.

E<>(Semaforo.cycle sensor imply Consola.u<76)

This means that there is some way that the light has led to the phase 8, and elapsed time is
less than 76 seconds (normal time it would take the TLS if time does not change any of the
8 phases). The explanation for the verification of this property is that the regular cycle can
be interrupted, as we have seen, by the transponder of a vehicle seeking preferential
treatment. If the vehicle calls attention is such that makes the system jump from an early
phase to phase 6, then decreases cycle time significantly.

E<>(Semaforo.cycle sensor imply Consola.u==76)

This latter means that there is some way in which the semaphore is closed with
step 8, and elapsed time is equal to 76 seconds. This case applies for when the regular
cycle has not been altered by any interruption, which causes no change in the times of each
phase. Recall that in this work we chose a pre-determined times to simulate all
systems. Do not forget that these times should be defined according to some criterion for
the simple temporized mode. Regarding the other main mode of operation, the adaptive
mode, it is understood that the times for each phase will vary from cycle to cycle
depending on the traffic flow data from the sensors send. However, in this work, for
purposes of simulation, have also been developed systems for that mode with the same
values of times for simple temporized mode.

184

Figure 8.:TLS cycle may may last less than 76 seconds

E<>(Semaforo.cycle sensor imply Consola.u>76)

This means that there is some way that the semaphore has been completed with phase 8,
and elapsed time is greater than 76 seconds. This is understandable because it is possible
that one of the two phases of the semaphore for pedestrian crossings, a pedestrian presses
the button and ask for the extension of the length of this ( pedestrian request mode). If you
attend such an application in either of the two possible phases in the cycle, and then do not
enter any other interruption, so that the rest of the cycle normally elapses, then the total
time would be greater than the regular ( 76 seconds).


185

Figure 8. The traffic signal cycle can be exactly 76 seconds.


Figure 8.: The traffic light cycle can last more than 76 seconds.

6.5.3.3 Verification of non-admission of two possible
different interruptions at the same time.
In this subsection we will try to verify that the system does not support a type of
interruption if is now meeting another. This check is critical because the system must
prioritize the interrupts in order of occurrence. Be taking one of them, you must block the
other, until the end of the attention of such interruption.

186
A[] not(Controlador.on and Preferencial.crossing)

This means that for any path there will be no state of the system in which
manual traffic controller is on at the same time the transponder of the vehicle that requests
preferential attention has sent its signal to the remote console. This is important, as a basic
principle in the design of the system was that it never can be two simultaneous interrupts.

Manual and Emergency modes do not overlap.

Figure 8.: The system does not support interruptions, at the same time, of the hand
controller traffic and emergency vehicle transponder.

A[] not(Controlador.on and Peaton.requesting)

This means that for any path there will be no state of the system in which
traffic controller is on manual while a pedestrian operated any type push button to extend
the time for one of the two phases pedestrian crossing.

Manual and Pedestrina Request do not overlap

187

Figure 8: The system does not allow at the same time interrupts of manual traffic controller
and push button that can trigger a pedestrian.

A[] not(Preferencial.crossing and Peaton.requesting)

This means that for any path there will be no state of the system in which the transponder
of the vehicle requesting preferential attention has sent its signal to the console while a
pedestrian operated any type push button to extend the time for one of the two phases of
the crosswalk.

6.5.3.4 Checking elongation phase at the request of
pedestrian
Here basically we use the Uppaal verifier to check the elongation
of phases 1 and 5 when a pedestrian traffic light request. Also we try
to check that occurs when operating the push button at some phase
other than those mentioned above, the system will not process the request, and
the cycle will continue their normal operation, with the possibility of allowing any of the
other two interruptions.
Emergency and Pedestrian Request do not overlap

188

Figure 8.: The system does not support interruptions at the same time of the emergency
vehicle transponder and push button type that represents the pedestrian request.

Elongation of phase 1 and phase 5 - powered by the pedestrian button .- To verify that
Phase 1 lasts longer than the time normally allotted to this, we write the check the
following:

E<>(Semaforo.req handle1 and Semaforo.x==21)

This means that there is a way by which to fulfill the request semaphore
pedestrian phase 1, and in response, increases the duration of that phase to normal
21 seconds (for simulated systems has been considered the time of 1 second to meet the
pedestrian additional request).

E<>(Semaforo.req handle2 and Semaforo.x==21)

This means the same as the previously owned verified, only for
the case where the application pedestrian has happened in the instant the traffic light is in
phase 5.

E<>Modos.not allowed push

This means that there is some way in which the system does not process the request
pedestrian attention, because this was admitted to a different phase for pedestrian crossing
(1 and 5). For example, if a pedestrian powered by mistake or ignorance, push button type
in any of the following phases of traffic lights: 2, 3, 4, 6, 7 or 8, then the system can not
fulfill your order. In timed automata, this "refusal" is represented when the Semaphore_
Modes automaton reaches not_allowed_push location.

Extended Phase 1 - pedestrian request

189

Figure 8.: It is possible that the system meets pedestrian and extend the application, thus,
time for phase 1.

Phase 5 long - application pedestrian

Figure 8.: It is possible that the system meets pedestrian and extend the application, thus,
time for phase 5.

Pedestrian request rejected

190

Figure 8.: It is possible that the application of attention pedestrian enter a phase that do not
correspond, and thus processing system rejection.

A[] not(Modos.not allowed push and Semaforo.ph1)

Here it is check for all possible paths, there is no state in having the traffic light is in phase
1, and internal control of the same scope as the location not_allowed_push. That is, there is
a situation where the system rejects the request pedestrian when it is entered during phase
1.

A[] not(Modos.not allowed push and Semaforo.ph5)

Similar to the previous case, under this property has not verified that the
the system can reject an request for pedestrian attention (with extended
phase time) when it enters as the traffic light at phase 5
for pedestrian crossing. That is, with the previous ownership and this one, we
ensure that whenever a pedestrian operated push button corresponding rate in
either pedestrian crossing phases have the light (1 and 5), the system never rejects the
request.

Request is not rejected in phase 1

191

Figure 8. There is no possibility that the system is in phase 1 and reject the request if the
pedestrian pushes the pedestrian button.

E<>(Modos.not allowed push and Semaforo.ph1)

The verification of this property is similar to the last two properties analyzed. In this case,
we want to know is whether there is any way possible for the traffic light which is in phase
1, and the system does not support the request interrupt pedestrian. Fortunately, as
expected, the result that throws the checker Uppaal is negative: the red color of the circle,
and text (Property Is Not Satisfied) so indicated.

E<>(Modos.not allowed push and Semaforo.ph5)

Finally we raise the same kind of question that in the previous case, only
that by the time the traffic light is in phase 5. As expected also, the software confirms that
there is any situation in which a pedestrian request with extended time and phase 5 is
rejected by the system.

Request is not rejected in phase 5.

192

Figure 8: There is no possibility that the system is in phase 5 and reject the request if the
pedestrian pushes the pedestrian button.

Extended Phase 1: impossible to refuse

Figure 8: To prove the last two properties verified, the software confirms that there is any
situation where the system rejects an application for a pedestrian phase.

Phase 5 elongated: impossible to refuse

193

Figure 8: Idem as above, but for phase 5: the system always an application process and
attend the pedestrian to enter while the light is in phase 5.

Part 3: Software System Design and Simulation
After having verified the temporal formulas with the use of timed automata and the subset
of TCTL for TLS (Traffic Ligth System) case study, we focus on the simulation of the
system, taking into account:
- The system will contain multiple nodes. These nodes will each unit, a corner traffic
light made in the previous chapter.
- The systems (nodes) are connected by coaxial cable Ethernet.
- The mode of communication will be asynchronous, multimaster.
- A node is the principal and the others will be slaves. As shown in the figure 8.

There are N traffic lights sources connected to a main traffic light computer. There are
three sensors in each node. The first sensor signaling the red colour (the traffic stops)
pedestrian can cross the street, the second sensor the ambar colour (the traffic is idle)
pedestrian and vehicle are waiting the chage of colour, and the sensor green colour (the
traffic is on) vehicles can go through the street and pedestrian must wait. Similarly the
main traffic light computer has three sensors: allow red, allow ambar, and allow green.
The aim of the control application is to keep in order the transit of a part of the city, i.e.
that the order of the traffic signals are correct to avoid vehicle collisions. The application is
able to switch between the signals (red, ambar, and green) to get its curent state.

The simulation model program code (package trafficlightsystem) contains four principal
parts that are described below:
- The abstract control interface, implemented between computer node and its part of
controlled device.
- The abstract network interface, a serial bus interface.

194

Figure 8.: Overview of the Trafic Light System

- The control program (its simulation version)
- The model of the environment.

6.5.4 The Abstract Control Interface
Is an abstract interface that connects the sub-model of the control program and two sub-
models of their environment together.
CommonControlInterface Java interface contains methods that allow reading of boolean
values from sensors and sensor changes the traffic lights between the three defined colors
(red, amber and green).
The interface is implemented within the submodel of the control program environment in
the class ModelInterface.
6.5.5 Model of the Control Program

The control program contains the following classes:
- SourceMonitor: for each source, there is a monitor object that is able to report
a consistent state of all its sensors. It is also able to switch the sensors.
- SourceControlThead: for each source, there is a control thread, an instance of
class SourceControlThread. This is an infinite loop that consists of a sensor
that reads data periodically evaluates and their possible reaction. In many
cases, no reaction. For each loop, the control thread sleeps for a fixed time
interval.
- For the main node, there is a monitor object (class SourceMonitor) that is able
to report, a consistent state of all its sensors. It also provides two semaphore
functions P and V requestActivity() and releaseActivity(). If N traffic lights

195
are in a ambar colour the monitor suspends the calling control thread of a
source willing to swith the sensor to the red or green colour. The control
thread can be later resumed in releaseActivity() when another control thread
switches its sensors or in wakeUpBlockedThreads() by the station
coordinating thread, described bellow.
- For the main traffic light, there is a periodic thread called station
coordinating thread that reads the sensor data. Whenever it founds that the
sensors of all sources have the same colour, it invokes method
wakeUpBlockThreads() of the station monitor. This is necessary because it
may happen that all control threads are blocked in the requestActivity()
method of the monitor because of the sensor colour of the main traffic light.
The three monitor methods share the same lock the monitor itself and
therefore it is possible to wake up the blocked control threads with a simple
notifyAll() call.
- Class TrafficLightStationControl. An encapsulation of the whole control
program part of the simulation. The constructor of the class creates N objects
(monitors) of traffic lights as well as the object (monitor) of the main traffic
light. It also creates threads responsible for controlling sensords in traffic
lights. Source code of this class needs to be edited when passing from the
model to the production version.
6.5.6 Model of the Control Program environment
The control program environment model part, is divided into four (sub)parts. The first part
package iohw contains a model of HW components that are a part of the embedded
device and that the control program communicates with, e.g. parallel ports of assumed
microcomputer and the sensors connected to single bit of these ports. The second part
package environment, contains a model of processes that the control system, that is the
control program plus the embedded device HW, interacts with. The third part class
ModelInterface, encapsulates all the control program environment part and implements the
CommonControlInterface. The four part, class NetworkModel, this class manages
communication via the Ethernet port, this class implements The
CommonNetworkInterface.
Primarily the part environmet communicates with the iohw and this part is comin with
controlprogram using functions implemented in CommonControlInterface. Iohw
controlprogram parties and together form a control system model, this is the embedded
computing device inlcuding the sensors and actuators connected. the environment is the
model of a controlled environment. When you move from model to real-world version
control system, the controlprogram should not change, at least as little as possible, and the
iohw should be able to be replaced directly with HW devices functionality with iohw
realesy should not change.
The code of iohw part contains the following classes:
- Class MainStationHardwareData. This class contains the encapsulation of the
hardware data provided by the main traffic light sensors, this is the model that the
hardware interface should store the data.


196
- Class TrafficLightHardwareData. This class contains the encapsulation of the
hardware provided by the normal traffic loght sensors; this is the model that the
hardware interface should store the data.

The code of environment part contains the following classes:
- Class TrafficLight. For each traffic light there is an object holding its current state
(red, ambar or green) and a reference to sensor data. The same applies to the main
traffic light class Station.
- For each traffic light, there is a J-Sim process seting the correct colour class
TrafficLightProcess.
- For the main traffic light, there is a J-Sim process seting its correct colours class
StationProcess. It works similarly to the traffic light process.
The third part of the model package class ModelInterface encapsulates all the control
program environment part. It creates the model objects and binds them together. Also
implements the CommonControlInterface , i.e. it provides methods for reading/writing
some data items of the model, specially values of the sensors and the traffic light activity
flags.
The fourth part of the model package class ModelNetworkInterface encapsulates all the
control of the interprocess communication among the traffic lights (nodes) with the main
traffic light (node). Also implements CommonNetworkInterface, i.e. it provides methods
for communication by message passing mechanism among them.
6.5.7 Overall System Performance
The main program of the simulation is contained in precisely the kind MainSimulation
trafficlightsystem package. This exists solely to create the simulation version of the control
interface (CommonControlInterface, ModelInterface instance), the network interface
(CommonNetworkInterface, ModelNetworkInterface instance) control program -
TrafficLightStationControl instance, both are part of a simulation that JiJ is an instance of
JiJSimulation.
The simulation can be executed step by step. After each step completed, the ground state of
the system is printed on the console and all invariants are verified.
The amount of information available to the user depends on how the application will run.
The source code varies greatly when converted to the final version control system. Really
the only ones left in the final as are the interfaces to be instance of some kind native class
of the final real hardware system.
The simulation of the traffic light control system have to be started with two parameters:

java pe...trafficlightsystem.MainSimulation MaxTime RunMode

where the MaxTime means the oveall time of simulation n seconds and RunMode
prescribes a mode of simulation program activity:
- Value 0: time, check of invariants, current output od sensors are printed in every
simulation step.
- Value 1: Like 0, but the state of the environment and the control program is printed
moreover, and invalid invariant passes computation to a step - by - step mode.
- Value 2: Like 1, but the simulation is triggered by a key. Key Q finishes the
computation.


197
At each step the validity of each invariant is checked:
- Invariant 1: the number of traffic lights should not exeed the value N.
- Invariant 2: if the sensors send colour red all of the traffic lights must be in red.
- Invariant 3: if the sensors send colour ambar all the traffic lights must wait in
ambar colour.
- Invariant 4: if the sensors send colour green all the traffic lights must be in green.

During the implementation of the model, an invariant can be invalid for a short time
interval. The control program will react in a future step, not necessarily in the next, as soon
as you read the respective values of the sensors. The reaction by itself, after the sensor data
are read, take a few steps of simulation because it usually invokes a synchronized method.
Invariants of states of controlled objects measured in simulation time can be disabled by a
time interval that is less than or equal to the latent response control system - time to sleep
monitoring process of the threads for some time code execution.
In this version of the demonstration of the application, only invariant state of the control
environment is verified. Generally arbitrary verification can be performed in each
simulation, either step by step or occasionally.
A special simulator process "observer" can be constructed to periodically assess the
activity of the model. Thanks to the design concept of the time, all the checks are carried
out without influencing the activity of the control program model.

198
7 Conclusions

The work consists basically of two methods (chain methods). TCTL - Uppaal and
verification of software using thread serialization concepts. To verify and simulate the
theory contained in the two methods has been used as an example to the first traffic light
and a set of traffic lights for the second. In the first method have been verified the temporal
properties of real traffic light performance using timed automata, which adds the feature of
time and allows synchronization with other automata by events. Thus, the transitions that
occur between the locations of a given automaton impact on the other automata which are
part of the same system, this latter would not be possible under the concept of state
machines.
In the second method has been used as a model the traffic ligth of the first method, but as a
set of traffic lights in a distributed network that interact with the main one sending
messages of their actual situation contained in sensors. The communication is done using
the message passing paradigm in a multimaster topology Ethernet network.
The main objective of this work is the verification of code for a timed system. It has been
reached.
















199
8 Bibliography
[1] A. Pnueli. Linear and Branching Structures in the Semantics and Logics of Reactive
Systems. In Proc. 12
th
ICALP, Nafplion, LNCS 194, 1985.

[2] E. Clarke, E. Emerson, and A. Sistla. Automatic verification of finite-state concurrent
Systems Using Temporal Logic Specifications. ACM Transactions on Programming
Languages and Systems, 8(2):244-263, 1986.

[3] E. Emerson. Automated Temporal Reasoning About Reactive Systems. In Logics for
Concurrency. Springer Verlag, 1995.

[4] H. Wong-Toi and P. Ho. Automated Analysis of an Audio Control Protocol. In Proc. In
Computer Aided Verification, Paris, 1993.

[5] S. Yovine. Kronos: A verification Tool for Real Time Systems. Software Tools for
Technology Transfer, 1997.

[6] T. Henzinger, P.-H. Ho, and H. Wong Toi. Hytech: A Model Checker for Hybrid
Systems. Software Tools for Technology Transfer, 1997.

[7] K. Larsen, P. Pettersson, and W. Yi. Uppaal in a Nutshell. Software Tools for Technology
Transfer, 1997.

[8] T. Coquand and G. Huet. Constructions: A Higher Order Proof System for Mechanizing
Mathematics. In EUROCALL85, LNCS 203, Linz, 1985, Springer Verlag.

[9] T. Coquand. Mathematical Investigations of a Calculus of Constructions. INRIA nad
Cambridge, University, 1986.

[10] T. Coquand and G. Huet. The Calculus of Constructions. Information and Computation,
76(2/3), 1988.

[11] L. Mangusson. The Implementation of ALF a proof editor based on Martin Lfs
Monomorphic Type Theory with Explicit Substitution. PhD thesis, Chalmers University of
Gteborg, 1994.

[12] B. Barras, S. Boutin, C. Cornes, J. Courant, Y. Coscoy, D. Delahaye, D. de
Rauglaudre, J-C. Fillitre, E. Gimnez, H. Herbelin, G. Huet, H. Laulhre, C. Muoz, Ch.
Murthy, C. Parent-Vigouroux, P. Loiseleur, Ch. Paulin-Mohring, A. Sabi, and B. Werner.
The Coq Proof Assistant. Reference Manual, Versin 6.2.4 . INRIA, 1999.


200
[13] Z. Luo and R. Pollack. Lego Proof Development System: Users Manual . Technical
Report ECS LFCS-92-211, LFCS, 1992.

[14] E. Gimnez. An Application of Co-indctive Types in Coq: Verification of the Alternating
Bit Protocol., In BRA Workshop on Types for Proofs and Programs (TYPES95), LNCS
1158, pages 135-152, Springer Verlag, 1995.

[15] E. Gimnez. A Calculus of Infinite Constructions and its Application to the Verification of
Communicating systems. PhD thesis, Ecole Normale Suprieure de Lyon, 1996, Unite de
Recherche Associe au CNRS Nro. 1398, 1996.

[16] E. Gimnez. Two Aproaches to the Verification of Concurrent Programs in Coq. 1999.

[17] Desel, Jrg and Juhs, Gabriel "What Is a Petri Net? Informal Answers for the Informed
Reader", Hartmut Ehrig et al. (Eds.): Unifying Petri Nets, LNCS 2128, pp. 1-25, 2001

[18] Decidability issues for Petri nets - a survey, by Javier Esparza and Mogens Nielsen, in:
Bulletin of the EATCS, 1994. Revised, 1995.

[19] Lipton, R. "The Reachability Problem Requires Exponential Space", Technical Report 62,
Yale University, 1976]

[20] P. Kngas. Petri Net Reachability Checking Is Polynomial with Optimal Abstraction
Hierarchies. In: Proceedings of the 6th International Symposium on Abstraction,
Reformulation and Approximation, SARA 2005, Airth Castle, Scotland, UK, July 26-29,
2005]

[21] Petri Nets: Properties, Analysis and Applications, by Tadao Murata, in: Proceedings of the
IEEE, vol. 77, no. 4, April 1989

[22] T. Araki and T. Kasami, Some Decision Problems Related to the Reachability Problem for
Petri Nets, in: Theoretical Computer Science, 3(1), pp. 85-104 (1977)

[23] C. Dufourd, A. Finkel, and Ph. Schnoebelen: Reset Nets Between Decidability and
Undecidability, in: Proceedings of the 25th International Colloquium on Automata,
Languages and Programming, LNCS vol. 1443, pp. 103-115 (1998)

[24] "Very Brief Introduction to CP-nets", Department of Computer Science, University of
Aarhus, Denmark

[25] Dawis, E. P., J. F. Dawis, Wei-Pin Koo (2001). Architecture of Computer-based Systems
using Dualistic Petri Nets. Systems, Man, and Cybernetics, 2001 IEEE International
Conference on Volume 3, 2001 Page(s):1554 - 1558 vol.3

[26] Dawis, E. P. (2001). Architecture of an SS7 Protocol Stack on a Broadband Switch Platform
using Dualistic Petri Nets. Communications, Computers and signal Processing, 2001.
PACRIM. 2001 IEEE Pacific Rim Conference on Volume 1, 2001 Page(s):323 - 326 vol.1

[27] Milner, R.; J. Parrow and D. Walker (1992). "A calculus of mobile processes". Information
and Computation 100 (100): 1--40. doi:10.1016/0890-5401(92)90008-4.

[28] A Calculus of Mobile Processes part 1 page 10, by R. Milner, J. Parrow and D. Walker
published in Information and Computation 100(1) pp.1-40, Sept 1992.

201
[29] Sangiorgi, D. (1996). "A theory of bisimulation for the -calculus". Acta Informatica 33:
6997. doi:10.1007/s002360050036.

[30] "BPML | BPEL4WS: A Convergence Path toward a Standard BPM Stack." BPMI.org
Position Paper. August 15, 2002.

[31] Atsushi Igarashi, Naoki Kobayashi: A Generic Type System for the _-Calculus. ACM
SIGPLAN Notices, Proceedings of the 28
th
ACM SIGPLAN-SIGACT Symposium on
Principles of Programming Languages, Vol. 36 Issue 3, 2001.
http://portal.acm.org/

[32] Bart Jacobs, Frank Piessens: A _-Calculus Semantics of Java: The Full Definition. Report
CW 355, Department of Computer Science, Katholieke Universiteit Leuven, Leuven,
Belgium, 2003

[33] Jeff Magee: LTSA Labelled Transition System Analyser.
University of London, Imperial College of Science Technology and
Medicine, Department of Computing, London, UK, 1999. http://www.doc.ic.ac.uk/ltsa/

[34] Systems and software verification. Model-Checking Techniques and Tools. B. Brard,
M. Bidoit, F. Laroussinie, A. Petit, L. Petrucci, Ph. Schnoebelen with P. McKenzie.

[35] Klaus Havelund, Thomas Pressburger: Model Checking Java Programs Using Java
PathFinder. International Journal on Software Tools for Technology Transfer, Vol. 2, No.
4, 2000. http://ase.arc.nasa.gov/people/havelund/Publications/-jpf-sttt.ps

[36] James C. Corbett, Mathew B. Dwyer, John Hatcliff, Shawn Laubach, Corina S. Psreanu,
Robby, Hongjun Zheng: Bandera: Extracting Finite-state Models from Java source
Code. Proceedings of the 22nd International Conference on Software Engineering, 2000.
http://www.cis.ksu.edu/santos/bandera/papers/bandera.pdf


[37] John Hatcliff, Matwhew Dwyer: Using the Bandera Tool Set to Model-check Properties of
Concurrent Java Software. Proceedings of CONCUR 2001 Concurrency Theory: 12th
International Conference, Aalborg, Denmark, 2001.
http://www.cis.ksu.edu/~hatcliff/Papers/-CONCUR01-tutorial.ps.gz

[38] Patrice Godefroid: Model Checking for Programming Languages using VeriSoft.
Proceedings of the 24th ACM Symposium on Principles of Programming Languages, Paris,
France, 1997. http://www.bell-labs.com/project/verisoft/popl97.ps

[39] Derek Bruening: Systematic Testing of Multithreaded Java Programs. Masters Thesis,
Massachusetts Institute of Technology, Cambridge, Massachusetts, USA, 1999.
http://web.mit.edu/iye/www/docs/thesis.ps.gz

[40] Derek Bruening, John Chapin: Systematic Testing of Multithreaded Programs.
MIT/LCS Technical Memo, LCS-TM-607, Massachusetts Institute of Technology,
Cambridge, Massachusettes, USA, 2000. http://web.mit.edu/iye/www/docs/tester-
TM607.ps.gz

[41] Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, Thomas Anderson:
Eraser: A Dynamic Data Race Detector for Multithreaded Programs. ACM Transactions on
Computer Systems, Vol. 15, Issue 4, 1997. http://portal.acm.org


202
[42] R. Alur, C. Courcoubetis, and D. Dill. Model Checking for Real-Time Systems. In
proceedings 5
th
Symposium on Logics in Computer Science, pages 414-425. IEEE Computer
Society Press, 1990.

[43] T. Henzinger, X. Nicollin, J. Sifakis, and S. Yovine. Symbolic Model Checking for Real
Time Systems. In proceedings 7
th
Symposium on Logics in computer Science. IEEE
Computer Society Press, 1992.

[44] S. Yovine, Mthodes et outils pour la verification symbolique de systems temporiss. PhD
thesis, Institut National Polytecnique de Genoble, France, 1993.

[45] A. Olivero. Modlisation et Analyse de Systmes Temporiss et Hybrides. PhD thesis,
Institut National Polytcnique de Genobre. France, 1994.
[46] R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science, 126:183
235, 1994.

[47] C. Draws, A. Olivero, and S. Yovine. Verificacin automtica de sistemas temporizados
utilizando KRONOS. Jornadas de Informtica y Telecomunicaciones, IEEE Uruguay, 1996.

[48] R. Alur. Techniques for Automatic Verification of Real Time systems. PhD thesis,
Department of Computer Sciences, Standford University, 1991.

[49] A. Pnueli. The Temporal Logic of Programs. Teoretical Computer Science, 1981.

[50] E. Emerson and E. Clarke. Using Branching Time Temporal Logic to Synthesize
Synchronization Skeletons. Science of Computer Programming, 2:241 266, 1982.

[51] R. Alur, C. Courcoubetis, N. Halbwachs, T Henzinger, P. Ho, X. Nicollin, A. Oliver, J.
Sifakis, and S. Yovine. The Algoritmic Analysis of Hybrid Systems. Theoretical Computer
Science, 138:3 34, 1995.

[52] F. Laroussinie and K. Larsen. Computational Model Checking of Real Time Systems. In
proceedings 6
th
Conference on Concurrency Theory, pages 27 41, Philadelphia, Springer
Verlag, 1995.

[53] O. Sokolosky and S. Smolka. Local Model Checking for Real Time Systems. In
Computer Aided Verification, proceedings 7
th
International WorkShop, Liege, LNCS, pages
211 224, 1995.

[54] T. Henzinger, O Kupferman, and M. Vardi. A Space Efficient On-the-fly Algorithm for
Real Time Model Checking. In Proc. 7
th
Conference on Concurrency Theory, LNCS
1119, pages 514 529, Springer- Verlag, 1996.

[55] J. Hobbs. Granularity. In Proceedings of the IJCAI 85, pages 432-435. IJCAI, 1985.

[56] S. Badaloni and M. Berati. Dealing With Time Granularity. Technical Report,
Departamento de Informtica Universidad de Jaume Castellon DI 06-11/95, 1995.

[57] J. Euzenat. An Algebraic Approach to the Granularity in Time Representation. In
Proceedings of Time 95, 1995.

[58] N. S. Bjrner, A. Browne, and Z. Manna. Automatic Generation of Invariants and
Intermediate Assertions. Theoretical Computer Science, 173(1): 49-87, 1997.


203
[59] E. Emerson, A. Mok, A. Sistla, and J. Srinivasan. Quantitative Temporal Reasoning.
Workshop on Automatic Verification Methods for Finite State Systems, Genobre, France,
1989.

[60] J. Ostroff. Temporal Logic of Real-Time Systems. PhD thesis, University of Toronto,
1987.

[61] J. Burch. Combining CTL, Trace Theory and Timing Models, Automatic Verification
Methods for Finite State Systems, LNCS 407, 1989.

[62] R. Alur and T. Henzinger. Logics and Models of Real Time: A Suvey. In J. W. de
Bakker, K. Huizing, W. P. de Roever, and G. Rozenberg, editors, Real Time Theory and
Practice, LNCS 600, pages 74 106. Springer Verlag, 1992.

[63] A. Pnueli and L. Lamport. And Old Fashioned Recipe for Real Time. In J. W. De
Baker, K. Huizing, W. P. De Roever, and G. Rozenberg, editors, Real Time Theory in
Practice, LNCS 600, Springer Verlag, 1992.

[64] T. Henzinger, Z. Manna, and A. Pnueli. What Good are Digital Clocks?. In W. Kuich,
editor, ICALP 92: Automata, Languages and Programming, LNCS 623, pages 545 558.
Springer Verlag, 1992.

[65] R. Alur and T. Henzinger. Real Time Logics: Complexity and Expressiveness .
Information and Computation, 104(1):35 77, 1993.

[66] R. Alur and T. Henzinger. A Really Temporal Logic. Journal of the ACM, 41(1):181-204,
1994.

[67] M. Bogza, O. Maler, and S. Tripakis. Efficient Verification of Timed Automata Using
Dense and Discrete Time Semantics. In L. Pierre and T. Kropf (Eds.), Proc. CHAEME99,
Springer Verlag, 1999.

[68] A. Gollu, A. Puri, and P. VAraiya. Discretization of Timed Automata. Proc. 33
rd
CDC,
Orlando, Florida, 1994.

[69] T. Hezinger and O. Kupferman. From Quantity to Quality. In Proc. Of the First
International Workshop on Hybrid and Real Time Systems, HART97, LNCS 1201, pages
48 62, Springer Verlag, 1997.

[70] A. Asarin, O. Maler, and A. Pnueli. On the Discretization of Delays in Timed Automata and
Digital Circuits. In R. de Simone and D. Sangorgi (Eds.), Proc. Concur98, LNCS 1466,
pages 470-484, Springer Verlag, 1998.

[71] D. Gries. The Science of Programming. Springer Verlag New York. 1981.

[72] A. Dijkstra, A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.

[73] C. Julta, E. Knapp, and J. Rao. A predicate Transformer Approach to Semantics of Parallel
Programs. In Proc. Of the 8
th
ACM Symposium on Principles of Distributed Computing,
1989.

[74] E. Knapp. A Predicate Transformer for Progress. Information Processing Letters, 33, 1990.


204
[75] L. Lamport. Win and Sin: Predicate Transformers for Concurrency. ACM Transactions on
Programming Languages and Systems, 12(2ACM Transactions on Programming Languages
and Systems, 12(3), 1990.

[76] K. Chandy and B. Sanders. Predicate Transformers for Reasoning about Concurrent
Computation. Science of Computer Programming, 24:129-148, 1995.

[77] R. Dijsktra and B. Sandlers. A Predicate Transformer for the Progress Property to Always.
Formal Aspects of Computing, 9:270 282, 1997.

[78] M. Lindahl, P. Pettersson, and Wang Yi. Formal Design and Analysis of Gear Controller. In
Proc. 4
th
Int. Conf. Tools and Algorithms for the Construction and Analysis of systems
(TACAS98), Lisbon, Portugal, March 1998, volume 1384 of Lecture Notes in Computer
Science, pages 281 297. Springer, 1998.

[79] K. Havelund, A. Skou, K. G. Larsen, and K. Lund. Formal modeling and analysis of an
audio/video protocol: An industrial case study using UPPAAL. In Proc. 18
th
IEEE Real
Time Systems Symposium (RTSS97), San Francisco, CA, USA, Dec. 1997, pages 2 13.
IEEE Comp. Soc. Press, 1997.

[80] K. Havelund, K. G. Larsen and A. Skou. Formal Verification of a Power Controller using
the Real Time Model Checker UPPAAL. In Proc. 5
th
Int. AMAST Workshop Formal
Methods for Real Time and Probabilistic Systems (ARTS99), Bamberg, Germany, May
1999, volume 1601 of Lecture Notes in Computer Science, pages 277 298. Springer, 1999.

[81] J. Bengtsson, W. O. D. Griffoen, K. J. Kristoffersen, K. G. Larsen, F. Larsson, P. Pettersson,
and Wang Yi. Verification of an Audio Protocol with bus Collision using UPPAAL. In
Proc. 8
th
Int. Conf. Computer Aided Verification (CAV96), New Brunswick, NJ, USA, July
Aug. Springer, 1996.

[82] K. G. Larsen, P. Petersson, and Wang Yi. UPPAAL in a nutshell. Journal of Software Tools
for Technology Transfer, 1(1-2):134-152, 1997.

[83] K. Birman and T. Joseph, Reliable communication in presence of failures, ACM
Transactions on Computer System, 3, 1987, 47 76.

[84] K. M. Chandy and L. Lamport, Distributed snapshots: determining global states of
distributed systems, ACM Transactions on Computer Systems, 3(1), 1985, 6375.

[85] A. Kshemkalyani, M. Raynal and M. Singhal, Global snapshots of a distributed system,
Distributed Systems Engineering Journal, 2(4), 1995, 224233.

[86] L. Lamport, Time, clocks and the ordering of events in a distributed system,
Communications of the ACM, 21, 1978, 558564.

[87] F. Mattern, Virtual time and global states of distributed systems, Proceedings of the
Parallel and Distributed Algorithms Conference, 1988, 215226.

[88] P. Panengaden and K. Taylor, Concurrent common knowledge: a new definition of
agreement for asynchronous events, Proceedings of the 5th Symposium on Principles
of Distributed Computing, 1988, 197209.

[89] S. M. Shatz, Communication mechanisms for programming distributed systems,
IEEE Computer, 1984, 2128

205

[90] Powell, D. (1995). Failure Mode Assumptions and Assumption Coverage In:
B. Randell, J. C. Laprie, H. Kopetz, & B. Littlewood (Ed.), Predictably
Dependable Computing Systems. Springer Verlag. Berlin. (pp. 123-140).

[91] SAE (1995). Class C Application Requirements, Survey of Known
Protocols, J20056 In: SAE Handbook. SAE Press, Warrendale, PA. (pp.
23.437-23.461).

[92] Kopetz, H. (1996). A Node as a Real-Time Object. Proc. of the IEEE Workshop on Object
Oriented Real-Time Systems. Laguna Beach, Cal. IEEE Press. (pp. 2-8).

[93] Kim G. Larsen, Paul Pettersson, and Wang Yi. Uppaal in a Nutshell. Int. Journal on
Software Tools for Technology Transfer, 1(1{2):134{152, October 1997

[94] R. Milner. Communication and Concurrency. Prentice{Hall, 1989

[95] Rajeev Alur and David Dill. A Theory of Timed Automata. Theoretical Computer Science,
2(126):183{236, 1994}.

[96] Alexandre David and M. Oliver Moller. From HUppaal to Uppaal: A translation from
hierarchical timed automata to flat timed automata. Research Series RS-01-11, BRICS,
Department of Computer Science, University of Aarhus, March 2001.

[97] Poledna, S. (1995). Fault-Tolerant Real-Time Systems, The Problem of
Replica Determinism. Kluwer Academic Publishers. Hingham, Mass, USA.

[98] Schneider, F. B. (1990). Implementing Fault-Tolerant Services Using the
State Machine Approach: A Tutorial. ACM Computing Surveys. Vol. 22
(4). (pp. 299-319).

[99] Kaer J.: Testing Java Software for Embedded Devices Using J-Sim and Serialization of
Threads. Department of Computer Sciences and Engineering University of West Bohemia,
Univerzitn 8 30614, Plzen, Czech Republic.

[100] Allain Pacheco Csar.: Architecture of the Network for Model Based Development of
Java Distributed Applications for Embedded Devices. ASIS 2005, Advanced Simulation of
Systems. 6 8 september 2005. Perov, Czech Republic. Pags 55-61. ISBN 80-86840-16-6

[101] J. Kacer, Simulation Based Checking of Concurrent Programs. PhD Thesis. University
of West Bohemia chap 7.




206
9 Authors Publications

The papers below described were presented in conferences


1. Allain Pacheco Csar, Verificacin de las Caractersticas del Diseo de Aplicaciones
Empotradas Escritas en Java Usando J-Sim y Serializacin de Hilos. 1st Euro-Latin
American Workshop on Engineering Systems. Department of Mathematics, National
University of Trujillo Tujillo Peru. April 26
th
-30
th
2005. ISBN 9972-9839-9-4. Nacional
Public Library of Per Number 2005-3702. Pages 213-223.

2. Allain Pacheco Csar, A Method of Verification For Distributed Embedded Programs
Written In Java. Proceeding of the (MOSIS 2005) Modeling and Simulation of Systems
Conference. Edited by MARQ, Jan Stefan. Hradec Nad Moravici, Czech Republic. April
19
th
21
st

2005. ISBN 80-868440-10-7. Pages 160-165.

3. Allain Pacheco Csar, A Method of Verification of Software Written in Java for
Embedded Systems. MARQ, NETSS 2005, New Trends in System Simulation.
Proceedings of the 2
nd
International Winter Workshop. Edited by MARQ, Jan Stefan.
Krnov, Czech Republic. February 22
nd
- 23
rd
2005. ISBN 80-86840-07-7. Pages 13-19.

4. Allain Pacheco Csar, Architecture of the Network for Model Based Development of
Java Distributed Applications for Embedded Devices. ASIS 2005, Advanced Simulation
of Systems.. 6 8 setiembre 2005. Prerov, Repblica Checa. Pages 55-61. ISBN 80-86840-
16-6

5. Allain P. Csar, Testing Real Time Software using TCTC logic and JSim Simulation,
INTERCON 2007, Universidad de Piura, IEEE Rama Estudiantil del Per.

6. Allain P. Csar, An Efficient Text Searching in Java Using PAT arrays and PATRICIA
Trees Algorithms. INTERCON 2007, IEEE Rama estudiantil del Per.

7. Allain P. Csar, Prueba de Sistemas en Tiempo Real via Simulacin con JSim y Lgica
Temporal. ECEI congreso Internacional propiciado por el CONCITEC, GOBIERNO DEL
PER, January 2008.

8. Castillo Frank, Allain P. Csar, Diseo del controlador de un semforo par una
interseccin de dos vas utilizando metodologa de sistemas en tiempo real. Tecnologa &
Desarrollo Revista de la Facultad de Ingeniera, Volumen 7, Nmero 1. Enero diciembre
2009. ISSN Nro. 1819-4575

207

Related Talks
Allain Csar. Architecture of the Network for Model-Based Development of Java
Distributed Applications for Embedded Devices. DSS Working Group Seminar, University
of West Bohemia, Pilsen, Czech Republic, 17. 10. 2005
Teaching Activities
1994 2000 Algorithm and Data Structures in C
1994 2000 Information Systems
1996 1997 Numerical Calculus
2000 2003 Data Structures
2006 2007 Software Engineering
2007 2009 Advanced Programing
2007 2009 System Analysis and Design
2007 2010 Internet Technologies