Fronczak, Reniers - Model-Based Systems Engineering - 4TC00 Dictaat 2014-2015 PDF

Model-Based Systems Engineering Lecture Notes 4TC00
J.M. van de Mortel-Fronczak

November 21, 2014
M.A. Reniers
Contents
1 Introduction to High Tech Systems Design
1.1
Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
Verification phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Validation Phases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Introduction to Model-Based Systems Engineering
11
2.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
Applications of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3 Modelling Plants and Controllers/Supervisors
17
3.1
Continuous-time behaviour and mode switching . . . . . . . . . . . . . . . . . . . .
19
3.2
Discrete variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3
Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4
Networks of hybrid automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4 Supervisory control of a patient support system

4.1
4.2
4.3
39
The ideal patient support system . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.1.1
Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.1.2
Model of the ideal patient support system . . . . . . . . . . . . . . . . . . .
41
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.2.1
Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.2
Model of the errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Controller with error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.1
49
Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
CONTENTS
4.3.2
4.4
Model of the controller with error handling . . . . . . . . . . . . . . . . . .
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Supervisory Control Theory
50
55
57
5.1
Notions and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.2
Basic supervisory control problem . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.3
General supervisory control problem . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.4
Modular supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.5
Specification of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.6
Overview of advanced synthesis techniques . . . . . . . . . . . . . . . . . . . . . . .
72
6 Applications of Supervisory Control Theory

6.1
73
Theme Park Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.1.1
Plant and requirement models
. . . . . . . . . . . . . . . . . . . . . . . . .
75
6.1.2
Supervisor synthesis and validation . . . . . . . . . . . . . . . . . . . . . . .
84
6.1.3
Supervisor implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
7 Data-based synthesis
91
7.1
Basic data-based supervisory control problem . . . . . . . . . . . . . . . . . . . . .
92
7.2
General data-based supervisory control problem . . . . . . . . . . . . . . . . . . . .
94
7.3
Automata for capturing requirements . . . . . . . . . . . . . . . . . . . . . . . . . .
95
7.4
Basic data-based synthesis algorithm . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Chapter 1
Introduction to High Tech

Systems Design
High Tech Systems are complex, and built as an answer to societal problems in the areas of mobility, aging, ecology, energy, and so on. Innovation in the development of high tech systems is
of crucial importance to the preservation of our prosperity and wellbeing. Applications of High
Tech Systems such as robotics, motion controllers, guided transport systems and embedded systems, can be found in semiconductor and nanotech systems, micro- and nano-assembly systems,
logistic systems, production automation and systems for handling, packaging, printing and processing goods. ASML wafer scanners, MRI scanners, Oce high-speed printers, and FEI electron
microscopes are prominent examples of such systems.
High-tech systems exploit advanced technologies from multiple engineering disciplines. A characteristic property of such systems is that during the development process not only the complex
component design phases but also the system integration and testing phases require a lot of time
and effort. The design of such systems requires a multidisciplinary approach combining the design of mechatronic systems, regulative control and supervisory control. In the elective package
High-tech systems design three courses are taught that focus on these three aspects.
In [17], a book that reports on the findings of the Boderc project on Model-based design of
high-tech systems, four main reasons for obtaining non-optimal design choices are presented:
1. common language and background between multiple engineering disciplines is lacking
2. many design choices are made implicitly, based on experience, intuition and gut-feeling
3. dynamic and time-depending aspects are complex to grasp
4. out-of-phase evolution of design in the mono-disciplines
The effects of these design complications are amplified by the complexity of high-tech systems [17].
The use of model-based systems engineering may provide a partial solution to these complicating
factors.
5
CHAPTER 1. INTRODUCTION TO HIGH TECH SYSTEMS DESIGN
1.1
Systems Engineering
According to INCOSE (International Council on Systems Engineering, www.incose.org), Systems

Engineering is an interdisciplinary approach and means to enable the realization of successful
systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, including operations, cost & schedule, performance,
training & support, testing, disposal and manufacturing.
Systems Engineering integrates all the disciplines and specialty groups into a team effort forming
a structured development process that proceeds from concept to production to operation. Systems
Engineering considers both the business and the technical needs of all customers with the goal of
providing a quality product that meets the user needs.
A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software,
facilities, policies, and documents; that is, all things required to produce systems-level results.
The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently
by the parts, is primarily created by the relationship among the parts; that is, how they are
interconnected [33].
Systems Engineering is an engineering discipline whose responsibility is creating and executing
an interdisciplinary process to ensure that the customer and stakeholders needs are satisfied in
a high quality, trustworthy, cost efficient and schedule compliant manner throughout a systems
entire life cycle. This process is usually comprised of the following seven tasks: State the problem,
Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and
Re-evaluate. These functions can be summarized with the acronym SIMILAR: State, Investigate,
Model, Integrate, Launch, Assess and Re-evaluate. It is important to note that the Systems
Engineering Process is not sequential. The functions are performed in a parallel and iterative
manner.
State the problem. The problem statement starts with a description of the top-level functions
that the system must perform: this might be in the form of a mission statement, a concept of
operations or a description of the deficiency that must be ameliorated. Most mandatory and
preference requirements should be traceable to this problem statement. Acceptable systems
must satisfy all the mandatory requirements. The preference requirements are traded-off to
find the preferred alternatives. The problem statement should be in terms of what must be
done, not how to do it. The problem statement should express the customer requirements in
functional or behavioral terms. It might be composed in words or as a model. Inputs come
from end users, operators, maintainers, suppliers, acquirers, owners, regulatory agencies,
victims, sponsors, manufacturers and other stakeholders.
Investigate Alternatives. Alternative designs are created and are evaluated based on performance, schedule, cost and risk figures of merit. No design is likely to be best on all
figures of merit, so multicriteria decision-aiding techniques should be used to reveal the preferred alternatives. This analysis should be redone whenever more data are available. For
example, figures of merit should be computed initially based on estimates by the design
engineers. Then, concurrently, models should be constructed and evaluated; simulation data
should be derived; and prototypes should be built and measured. Finally, tests should be
run on the real system. Alternatives should be judged for compliance of capability against
requirements. For the design of complex systems, alternative designs reduce project risk.
Investigating innovative alternatives helps clarify the problem statement.
Model the system. Models will be developed for most alternative designs. The model for the
1.1. SYSTEMS ENGINEERING
preferred alternative will be expanded and used to help manage the system throughout its
entire life cycle. Many types of system models are used, such as physical analogs, analytic
equations, state machines, block diagrams, functional flow diagrams, object-oriented models,
computer simulations and mental models. Systems Engineering is responsible for creating a
product and also a process for producing it. So, models should be constructed for both the
product and the process. Process models allow us, for example, to study scheduling changes,
create dynamic PERT charts and perform sensitivity analyses to show the effects of delaying
or accelerating certain subprojects. Running the process models reveals bottlenecks and
fragmented activities, reduces cost and exposes duplication of effort. Product models help
explain the system. These models are also used in tradeoff studies and risk management.
Integrate. No man is an island. Systems, businesses and people must be integrated so that
they interact with one another. Integration means bringing things together so they work as a
whole. Interfaces between subsystems must be designed. Subsystems should be defined along
natural boundaries. Subsystems should be defined to minimize the amount of information
to be exchanged between the subsystems. Well-designed subsystems send finished products
to other subsystems. Feedback loops around individual subsystems are easier to manage
than feedback loops around interconnected subsystems. Processes of co-evolving systems
also need to be integrated. The consequence of integration is a system that is built and
operated using efficient processes.
Launch the system. Launching the system means running the system and producing outputs.
In a manufacturing environment this might mean buying commercial off the shelf hardware
or software, or it might mean actually making things. Launching the system means allowing
the system do what it was intended to do. This also includes the system engineering of
deploying multi-site, multi-cultural systems.
This is the phase where the preferred alternative is designed in detail; the parts are built or
bought (COTS), the parts are integrated and tested at various levels leading to the certified
product. In parallel, the processes necessary for this are developed where necessary - and
applied so that the product can be produced. In designing and producing the product,
due consideration is given to its interfaces with operators (humans, who will need to be
trained) and other systems with which the product will interface. In some instances, this
will cause interfaced systems to co-evolve. The process of designing and producing the
system is iterative as new knowledge developed along the way can cause a re-consideration
and modification of earlier steps.
The systems engineers products are a mission statement, a requirements document including
verification and validation, a description of functions and objects, figures of merit, a test plan,
a drawing of system boundaries, an interface control document, a listing of deliverables,
models, a sensitivity analysis, a tradeoff study, a risk analysis, a life cycle analysis and
a description of the physical architecture. The requirements should be validated (Are we
building the right system?) and verified (Are we building the system right?). The system
functions should be mapped to the physical components. The mapping of functions to
physical components can be one to one or many to one. But if one function is assigned
to two or more physical components, then a mistake might have been made and it should
be investigated. One valid reason for assigning a function to more than one component
would be that the function is preformed by one component in a certain mode and by another
component in another mode. Another would be deliberate redundancy to enhance reliability,
allowing one portion of the system to take on a function if another portion fails to do so.
Assess performance. Figures of merit, technical performance measures and metrics are all
used to assess performance. Figures of merit are used to quantify requirements in the tradeoff
studies. They usually focus on the product. Technical performance measures are used to
mitigate risk during design and manufacturing. Metrics (including customer satisfaction
comments, productivity, number of problem reports, or whatever you feel is critical to your

business) are used to help manage a companys processes. Measurement is the key. If you
cannot measure it, you cannot control it. If you cannot control it, you cannot improve
it. Important resources such as weight, volume, price, communications bandwidth and
power consumption should be managed. Each subsystem is allocated a portion of the total
budget and the project manger is allocated a reserve. These resource budgets are managed
throughout the system life cycle.
Re-evaluate. Re-evaluate is arguably the most important of these functions. For a century,
engineers have used feedback to help control systems and improve performance. It is one
of the most fundamental engineering tools. Re-evaluation should be a continual process
with many parallel loops. Re-evaluate means observing outputs and using this information
to modify the system, the inputs, the product or the process. Figure 1 summarizes the
Systems Engineering Process. This figure clearly shows the distributed nature of the Reevaluate function in the feedback loops. However, all of these loops will not always be used.
The particular loops that are used depend on the particular problem being solved.
Like all processes, the Systems Engineering process at any company should be documented, measurable, stable, of low variability, used the same way by all, adaptive, and tailorable! This may
seem like a contradiction. And perhaps it is. But one size does not fit all. The above description
of the Systems Engineering process is just one of many that have been proposed. Some are bigger,
some are smaller. But most are similar to this one.
1.2
V-model
The following describes a frequently encountered development process in the area of software
engineering. The text is largely based on the wikibook Introduction to Software Engineering /
Process / V-model.
The V-model represents a software development process (also applicable to hardware development)
which may be considered an extension of the waterfall model. Instead of moving down in a linear
way, the process steps are bent upwards after the coding phase, to form the typical V shape. The
V-Model demonstrates the relationships between each phase of the development life cycle and its
associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.
1.2.1
Verification phases
Requirements analysis In the Requirements analysis phase, the requirements of the proposed
system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be
designed or built. Usually, the users are interviewed and a document called the user requirements
document is generated.
The user requirements document will typically describe the systems functional, interface, performance, data, security, etc requirements as expected by the user. It is used by business analysts
to communicate their understanding of the system to the users. The users carefully review this
document as this document would serve as the guideline for the system designers in the system
design phase. The user acceptance tests are designed in this phase.
There are different methods for gathering requirements of both soft and hard methodologies including; interviews, questionnaires, document analysis, observation, throw-away prototypes, use
cases and status and dynamic views with users.
1.2. V-MODEL
Figure 1.1: V-model, from Clarus Concept of Operations, Publication No. FHWA-JPO-05-072,
Federal Highway Administration, 2005
System Design Systems design is the phase where system engineers analyze and understand
the business of the proposed system by studying the user requirements document. They figure
out possibilities and techniques by which the user requirements can be implemented. If any of the
requirements are not feasible, the user is informed of the issue. A resolution is found and the user
requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase is
generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better
understanding. Other technical documentation like entity diagrams, data dictionary will also be
produced in this phase. The documents for system testing are prepared in this phase.
Architecture Design The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture
is that it should realize all which typically consists of the list of modules, brief functionality of
each module, their interface relationships, dependencies, database tables, architecture diagrams,
technology details etc. The integration testing design is carried out in the particular phase.
Module Design The module design phase can also be referred to as low-level design. The
designed system is broken up into smaller units or modules and each of them is explained so that
the programmer can start coding directly. The low level design document or program specifications
will contain a detailed functional logic of the module. The unit test design is developed in this
stage.
1.2.2
Validation Phases
Unit Testing In computer programming, unit testing is a method by which individual units of
source code are tested to determine if they are fit for use. A unit is the smallest testable part of
an application. In procedural programming a unit may be an individual function or procedure.
Unit tests are created by programmers or occasionally by white box testers. The purpose is to
10
verify the internal logic code by testing every possible branch within the function, also known as
test coverage. Static analysis tools are used to facilitate in this process, where variations of input
data are passed to the function to test every possible case of execution.
Integration Testing In integration testing the separate modules will be tested together to
expose faults in the interfaces and in the interaction between integrated components. Testing is
usually black box as the code is not directly checked for errors.
System Testing System testing will compare the system specifications against the actual system.After the integration test is completed, the next test level is the system test. System testing
checks if the integrated product meets the specified requirements. Why is this still necessary after
the component and integration tests? The reasons for this are as follows:
Reasons for system test In the lower test levels, the testing was done against technical specifications, i.e., from the technical perspective of the software producer. The system test, though,
looks at the system from the perspective of the customer and the future user. The testers validate whether the requirements are completely and appropriately met. Example: The customer
(who has ordered and paid for the system) and the user (who uses the system) can be different
groups of people or organizations with their own specific interests and requirements of the system.
Many functions and system characteristics result from the interaction of all system components,
consequently, they are only visible on the level of the entire system and can only be observed and
tested there.
User Acceptance Testing Acceptance testing is the phase of testing used to determine whether
a system satisfies the requirements specified in the requirements analysis phase. The acceptance
test design is derived from the requirements document. The acceptance test phase is the phase
used by the customer to determine whether to accept the system or not.
Acceptance testing helps to determine whether a system satisfies its acceptance criteria or not, to
enable the customer to determine whether to accept the system or not, to test the software in the
real world by the intended audience.
The purpose of acceptance testing is to verify the system or changes according to the original
needs.
Chapter 2
Introduction to Model-Based
Systems Engineering
This chapter is partly based on [1].
In current industrial practice, it is very difficult to deal with high-tech multi-disciplinary system
development due to system complexity, market pressure, and resource limitations. To overcome
the difficulties, various kinds of models are used increasingly often in the development process.
Specifically, formal and executable models built and employed in the design phase can be used
to assess functional correctness and performance of component designs and overall system design.
Formal verification, in particular model checking [3], is employed when a high degree of confidence
in functional correctness of a design is required. To assess design performance, one can use
simulation directly on the model, or analyze an associated Markov Chain or Queueing Model.
Successful use of models is, however, not limited to the design phase. Models are nowadays also
used in the test and integration phases. The effort required to integrate components and to test the
resulting high-tech multi-disciplinary system against the initial requirements increases significantly
with the increase in complexity. The integration and test phases have a large and growing influence
on time-to-market and product quality, being the main business drivers for system developers.
High-tech multi-disciplinary systems are systems in which cutting edge technologies from multiple
engineering disciplines are integrated to meet strict quality requirements set by the customer. A
characteristic of such systems is that they are integration intensive, which means that integrating
components and testing the resulting system against its requirements consumes a large portion of
total system development effort. In some cases, the integration and test effort may even exceed
the already considerable amount of development effort required to deal with the complexity of
components. Examples of high-tech multi-disciplinary systems are commercial systems such as
wafer scanners, electron microscopes, and high-speed printers, medical systems such as magnetic
resonance imaging (MRI) scanners, as well as aerospace systems such as satellites, airplanes, and
spacecraft.
To wit, it is shown in [6] and [5] that models can successfully be used for early integration of wafer
scanners, where the idea is to start integrating and testing as soon as possible, using models as
replacements of components as long as actual component realizations are not yet available. Using
an appropriate integration infrastructure that implements the designed and modeled interaction
behavior, realized components can be integrated with models of not yet realized components. The
resulting model-based integrated system can then be tested on system level before complete system
realization is available. Another application is in model-based testing [7], where a model is used
to automatically derive and execute tests on an implementation, as shown for wafer scanners in
11
12
CHAPTER 2. INTRODUCTION TO MODEL-BASED SYSTEMS ENGINEERING
[43].
The use of models enables application of model-based techniques and tools for thorough system
analysis and systematic testing, helping to improve system overview for engineers. Additionally,
models of components and requirements enable synthesis of supervisory controllers essential for
correct functioning of systems. Supervisor synthesis procedures are based on Supervisory Control
Theory originating in [30].
Figure 2.1 schematically illustrates a high-tech system with the focus on control. At the bottom,
the main structure is depicted, containing the physical hardware components. Sensors and actuators are mounted on these hardware components to monitor their position or state and to actuate
them. The resource control layer assures that actuators reach a desired position in a desired way
(regulatory control). The supervisory control layer coordinates individual components and gives
the desired functionality to the system.
Event-driven
Supervisory control
Interface
Time-driven
Resource control
Hardware
Figure 2.1: Positioning supervisory control.

The high-tech industry is also confronted with problems related to systematic upgrades of complex
control software, necessary either for new systems or machines or for extending functionality
of the existing ones. Also in this context, system component and requirement models can be
used to speed up the supervisory control design process. To embed supervisor control design in
model-based engineering, modelling and analysis techniques are needed to handle the complexity
frequently encountered in high-tech systems and to support the evolvability in the development
process. High-tech companies are often challenged to increase the functionality and quality of
a product, while simultaneously time-to-market and product costs should be reduced. Current
practice shows that this is not straightforward. As a result, there is a need for new engineering
processes.
This chapter is structured as follows. Section 2.1 gives a short overview of engineering processes
that are based on models. In Section 2.2, we informally explain how models can be used to support
and speed up system engineering processes.
2.1
Overview
To support structured system development, several engineering processes are introduced originating from systems architecting ([32]) and systems engineering ([27]). More recently, [28] proposed
a conceptual model specifically supporting embedded systems architecting. In general, a system
engineering process starts with a global definition of the requirements that the system should
fulfill. Based on these requirements, the global system design is defined, usually partitioned into
subsystems or modules. For each module, the requirements are derived from the global design, a
design is defined and then built. Every module is tested separately to assure that its requirements
2.1. OVERVIEW
13
are satisfied. Subsequently, modules are integrated and the complete system is also tested to
assure that it complies to its requirements. For a system consisting of two modules, component P
and its controller S, this is schematically depicted in Figure 2.2.
RS
design
realize
DS
define
define
design
integrate
Interface I
integrate
define
RP
design
= documents;
realize
DP
= realizations
Figure 2.2: Traditional engineering process.
Thanks to the introduction of microprocessors, it became possible to develop systems with substantially extended functionality. The extended functionality often implies a multidisciplinary
character because mechanical and control engineers needed to cooperate with electrical, electronic
and computer science engineers. Especially for this kind of systems, traditional engineering processes are often not optimal in terms of system quality, time to market and costs.
In the last decades, engineers started to use executable software models to test the designs before
they are actually built. An advantage of such models is that they can be used not only to analyse
designed system behavior but also to investigate how components or modules that are already built
interact with the rest of the system that is not yet built. One can think of, for instance, checking
if the system is nonblocking or estimating system performance. In [5], evidence is provided that
executable models help in improving system quality and in decreasing time-to-market. Models also
support evolvability, as they can easily be re-used for similar systems. Integration of executable
models in engineering processes is rendered in the scheme of Figure 2.3. The difference between
this scheme and Figure 2.2 is that models are built (and analysed) prior to building the realisations.
We can state that realisations are built after the design is proven correct using various model-based
analysis techniques.
RS
design
DS
define
define
design
integrate
Interface I
integrate
RP
= models;
realize
integrate
define
= documents;
model
design
DP
model
integrate
realize
= realizations
Figure 2.3: Model-based engineering process.

Certainly for complex systems, model-based systems engineering (MBSE) methods are state of
the art. However, all current MBSE approaches still carry a significant contribution to the overall
14
system cost. The industry faces increasing complexity and is challenged to reduce development
time and cost. To meet these challenges, a next generation MBSE approach is required that reduces
human errors and shortens the development cycle. An overview of the state of the art commercially
available MBSE methodologies, such as IBM Telelogic Harmony-SE, INCOSE Object-Oriented
Systems Engineering Method (OOSEM), IBM Rational Unified Process for Systems Engineering
(RUP SE) for Model-Driven Systems Development (MDSD) and Vitech Model-Based Systems
Engineering (MBSE) Methodology, can be found in [12]. They include processes, methods and
tools supporting manual development of systems, therefore helping in achieving a paradigm shift
from a traditional document-based approach to a model-based approach. However, in the context
of control software design, they focus on design model formulation. To cope with industrial
challenges, more powerful techniques and tools are required. The MBSE process proposed in
[6] enables the use of various analysis techniques and tools based on formal models to support
system development. Significant development cost and cycle time reduction can be gained by the
incorporation of methods and tools for supervisor synthesis. To this end, as opposed to traditional
engineering, an explicit separation of concerns related to the plant and the supervisor is necessary.
This also means that requirements for supervisory control must be separated from requirements
for regulatory control. Supervisor synthesis techniques replace manual design of control logic by
automatical derivation from component and requirement specifications. The synthesized control
logic is nonblocking and by construction correct with respect to safety properties. In general,
liveness properties still need to be verified. The position of supervisor synthesis in the development
process is shown in Figure 2.4 ([34]).
RS
model
RS
synthesize
define
define
design
realize
integrate
integrate
Interface I
integrate
define
RP
design
DP
model
integrate
realize
Figure 2.4: Engineering process with supervisory control synthesis.
This setting partly corresponds to Figure 2.3. As previously, requirements R of the system under supervision are defined first. Based on these requirements, design D of the system and a
decomposition into requirements for the uncontrolled plant and the supervisor are defined. After
decomposition, requirements RS for the supervisor and RP for the uncontrolled plant are specified. From the plant requirements, design DP and one or more plant models P can be defined.
However, instead of making a design and a model of the supervisor, the requirements for the
supervisor are formally modeled. A discrete-event model of the plant and the formal model of
RS can be used to synthesize a supervisor in the framework of supervisory control theory. Plant
models can also be used to analyse the behavior of the uncontrolled plant under supervision of the
supervisor. Formal and executable models built and employed in the design phase can be used to
assess functional correctness and performance of the design of components and the overall system.
One example of a commercially available tool used for correctness checking is the CSP-based tool
of Verum (www.verum.com). To assess performance of the design, one can use simulation directly
on the model, or use analytical or numerical methods to analyze an associated stochastic model.
In synthesis-based engineering, required system properties are used as input for generation of a
design of a supervisor that is correct by construction. As a consequence, in the analysis phase
verification can be eliminated to a large extent. This changes the development process from
implementing and debugging the design and the implementation, to defining the requirements.
2.2. APPLICATIONS OF MODELS
2.2
15
Applications of models
In this section, we consider the types of models that we encounter in the course of this project in
the model-based engineering approach presented in the previous section. Behavioural models as
they are encountered in this course may be classified on the type of state, on the time domain of
dynamic behaviour and on the cause of state changes. With respect to the state of the system,
one encounters the following types:
continuous state: The state is represented by (combinations of) values from dense domains.
A domain is dense if in between any two values there is another value.
discrete state: The state is represented by (combinations of) values from a countable or
discrete domain.
hybrid state: The state consists of both continuous state components and discrete state
components.
The time domains used for the description of dynamic behaviour are the following:
continuous time: the domain of time points is a dense. The prominent example of such
continuous time domains is the set of non-negative real numbers.
discrete time: the domain of time points is discrete, for example the natural numbers.
For the cause of state changes one usually distinguishes:
time-driven: the state of the system changes on the basis of time passage
event-driven: the state of the system changes on the basis of events, i.e., the start or end
of an activity. Typically the amount of time between pairs of consecutive events is not the
same.
When modelling an uncontrolled plant typically some physical quantities are considered such as
the speed of a vehicle. Also these models tend to have modes of operation for different continuous
dynamics. Therefore these models have both continuous state and discrete state. These are hybrid
state systems. The time domain used in these models is continuous time. The physical quantities
change continuously over time, whereas the mode switching is based on conditions in terms of
sporadic inputs into the system or occurrence of combinations of state values. Therefore these
systems are classified as both time-driven and event-driven. Such systems are also commonly
called hybrid systems.
Supervisory controllers are components that are most of the time modelled using discrete state,
although continuous state and hybrid state controllers also occur. They typically are event-driven.
Controlled plants are of the same type as uncontrolled plants. They may be considered the
composition of an uncontrolled plant and a supervisory controller.
Requirements are modelled as discrete state, time-free, and event-driven systems. In this course
we will also show the use of logical formulas for the specification of requirements. These fall outside
the classification presented here.
All of the models mentioned before can be modelled and simulated using the language and tools
presented in this course. The complexity of the models (in terms of complexity of the dynamics)
influences the efficiency of the simulation. simulation is used for the purpose of validating whether
16
or not the models show the expected behaviour. Especially, simulation is used to validate (1)
whether the uncontrolled plant is a good representation of the real (anticipated) system, and (2)
whether the controlled plant shows the desired behaviour.
Synthesis is a method where a plant model and a requirement model are combined into a supervisor that, when composed with the uncontrolled plant, has the properties expressed by the
requirements. Current status of the synthesis algorithms only allows synthesis for a restricted
class of plant models and for a restricted class of requirements. In this course we will only use
a very basic synthesis algorithm. It allows plant models which are discrete state, time-free, and
event-driven only. It allows requirements specified in the same class of systems and some basis
logical formulas.
Verification is the process of establishing a property formulated in some form of logic with respect
to a model of a system. The language used in this course allows the use of tools for the verification
of discrete state, time-free, event-driven models using mCRL2 and discrete state, discrete time,
event- and time-driven models using UPPAAL.
Chapter 3
Modelling Plants and

Controllers/Supervisors
In the introduction of the model-based systems engineering of the previous chapter several models
were encountered:
uncontrolled system / plant
supervisor / controller
controlled plant
requirements
In this chapter we will be mainly concerned with the introduction of a modelling formalism that
is suited for modelling uncontrolled plants and controllers.
When looking carefully at prototypical examples of uncontrolled systems, or plants, in the domain
of high-tech systems, such as wafer scanners, robots, automotive applications, baggage handling
systems, printing devices, etc., one may find that at least the following concepts occur frequently:
1. physical quantities, such as temperature, speed, mass, energy, etc.
2. different operational modes, such as equipment being on/off, maintenance modes, error
modes, modes associated with different functions of the systems under consideration
3. decomposition of the system in subsystems and interactions between those, e.g., a robot may
consist of subsystems for movement, vision, etc.
4. interaction between the subsystems, e.g., exchange of material and information about one
ones operation state.
Typically, the physical quantities that are encountered are real-valued and moreover may change
continuously over time. Therefore, in literature, and also in this course, systems in which such
quantities are relevant are said to have continuous-time behaviour.
From a modeling perspective often it is useful not to detail all the physics involved in a certain
system. When a system has an on/off button often it is not useful to model the physics involved
17
18
CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS
of the button being pushed with a certain force, resulting in a certain speed of movement, etc.
Many times it is much more convenient to model such a concept as an instantaneous change in the
behaviour of the system. Such behaviour is called discrete-event behaviour. Another phenomenon
that is often modelled by means of a discrete-event is the situation that a certain physical quantity
or combination of physical quantities reaches a certain level. An example here is the speed of a
vehicle reaching a certain pre-set cruise control speed. This fact may be of relevance to the
modeling since on the basis of this the acceleration of the vehicle should be decreased to zero.
Note to the reader. Note that it is not possible to state in general terms how one should model
certain phenomena. This depends on the purpose of the modeling activity. For example, when
you are modeling a system of automated guided vehicles (AGVs) with the purpose of developing
a controller that guarantees that the AGVs do not collide, the model most likely contains detailed
information about speed and position of the AGVs. If, on goal of the modeling activity is to
develop a controller that plans the activities of these AGVs for the near future, most likely this
level of detail is not needed, and it may suffice to model an AGV as an ordered sequence of the
tasks it should carry out.
It is common practice to approach the modelling of a complex system by decomposing the system
in a number of subsystems, each of which may involve less modeling effort, and their interactions. There is again no general rule that dictates how a system must be decomposed. Several
decomposition approaches are used in practice among which we mention
physical/spatial decomposition: the system is decomposed into subsystems based on the
spatial arrangement of the subsystems. For example, in a vehicle a physical decomposition
gives an engine subsystem and a braking subsystem (among many others of course)
functional/logical decomposition: the system is decomposed in the services it offers to the
environment. For example, a printer offers printing, scanning, and faxing services.
It is not very likely that a system can be decomposed into subsystems that are completely unrelated1 . Therefore, we need to model interaction between the subsystems. In the modeling of
high-tech systems with the aim of developing supervisory controllers the interaction is usually of
a discrete nature. An example is the handing over of a piece of luggage between two consecutive
conveyor belts in a baggage handling system.
Summarizing the above discussion, a system can be seen as a collection of subsystems that interact
with each other. One such a subsystem will be called a hybrid automaton, and the collection of all
of those is called a network of hybrid automata. First, hybrid automata are introduced, followed
by networks of hybrid automata.
In this course we use a language called CIF (Compositional Interchange Format) [41]. CIF is
an automata-based modeling language for the specification of discrete event, timed, and hybrid
systems. The CIF 3 tooling supports the entire development process of controllers, including
among others specification, supervisory controller synthesis, simulation-based validation and visualization, verification, real-time testing, and code generation. CIF 3 was created and is currently
developed by the Systems Engineering group of the Mechanical Engineering department, at the
Eindhoven University of Technology (TU/e). The CIF 3 tooling is free, and is available under
the MIT open source license. Relevant and up-to-date information about CIF is available via
http://cif.se.wtb.tue.nl. A screenshot of a typical usage of CIF is given in Figure 3.1.
In the upcoming sections, both hybrid automata and CIF models are used frequently for describing
models. Each time it should be clear how the one can be transformed to the other.
1 One could argue that if a system could be decomposed into unrelated subsystems, then these are actually two
different systems.
3.1. CONTINUOUS-TIME BEHAVIOUR AND MODE SWITCHING
19
Figure 3.1: Screenshot of a CIF session. Source: http://cif.se.wtb.tue.nl/index.html.
3.1
Continuous-time behaviour and mode switching
In this section, a simplified version of hybrid automata will be introduced that is geared towards
the specification of continuous-time behaviour and switching between operational modes.
In such a hybrid automaton the (sub)system that is modelled has a state consisting of a discrete
mode and a continuous part. The discrete mode is modelled by means of locations. A location
represents a specific operational mode where the system may/will reside for a while, such as a
system being On or Off, or Producing or Idling. The (continuous) behaviour of the system
may differ considerably in the different operational modes. This will be explained and illustrated
shortly. In the graphical representation of such hybrid automata the locations are depicted by
means of circles. The name of the location is written inside or close to the circle. See Figure 3.2
for a first example of a hybrid automaton.
Continuous variables are used to represent relevant physical quantities such as speed, force, water
level, etc. Later in this chapter, discrete variables will also be used for representing relevant
discrete information about the system such as the (estimated) number of paper sheets in a certain
tray or the number of items present in a buffer.
The evolution of the physical quantities as a function of time is described in a location by means
of a collection of equations. In each location a different set of equations may be used, in particular
to reflect that different dynamics are modeled. An example is a (model of) a vehicle with one
location for modelling that the vehicle is moving with some speed, and another one representing
that the vehicle is not moving at all.
As is common with the description of the dynamics of systems differential equations are used for
describing the dynamics of the physical quantities. For example the fact that the car is not moving
may be captured by the differential equation v = 0 (where, obviously, v denotes the speed of the
vehicle) and perhaps the differential equation v = a (for some constant a) is used to describe
that the vehicle is accelerating. The equations that describe how the variables behave in a certain
operational mode are written inside the corresponding location. In CIF, it is required to specify
20
v=0
t=0
Standing still
v = 0
t = 1
tT
accelerate
v=s
driving
t := 0
v=0
standing still
t := 0
Decelerating
v = a
t = 1
Accelerating
v = a
t = 1
tT
decelerate
Driving
v = 0
t = 1
Figure 3.2: Example hybrid automaton, illustrating the appearance of the basic concepts.
the dynamics of each continuous variable in each location of the hybrid automaton, even if this
seems unnecessary. For example, in the hybrid automaton from Figure 3.2, the variable t is used
as a clock in the locations Standing still and Driving. It has no meaning in the other locations.
Nevertheless there must be some differential equation describing the evolution of the variable t in
those locations as well. In this case the differential equation t = 1 was chosen (for no particular
reason). Only explicit differential equations are used. This means that each such equation is of
the form v = expr where v is a continuous variable and expr is some expression (of the right type)
in which variables may be used. In the set of equations there may not be cyclic references.
Changes in the discrete mode are achieved by switching between operational modes. Graphically
such a mode switch is represented by an edge between the two involved locations. The control
moves from the location at the start of the edge towards the location at the end of the edge (with
the arrowhead). Edges may be labelled with an event. In the context of a network of automata
(see Section 3.4) events are used to synchronize between different automata.
In most cases the switching depends on the (combined) values of the continuous variables these
are represented in guards. The guard is a predicate (i.e., an expression that, given values of all the
variables, evaluates to one of the Boolean2 values true or false). A transition from one location to
another may only be taken in case the values of the continuous variables are such that the guard
associated with that transition holds (i.e., evaluates to true). Graphically the guard is written
close to the transition it is associated with.
Example 3.1.1 (Thermostat, [22]). Consider a room being heated by a radiator controlled by a
thermostat. Assume that when the radiator is off the temperature, x R, of the room decreases
exponentially towards 0 degrees according to the differential equation
x = ax
(3.1)
for some a > 0. When the thermostat turns the heater on the temperature increases exponentially
2 The truth values true and false are named after the British mathematician George Boole (1815-1864), whom
discovered Boolean algebra and is consider one of the grandfathers of the fields of logic and computer science.
21
towards zero degrees, according to the differential equation

x = a(x 30)
(3.2)
Assume that the thermostat is trying to keep the temperature at around 20 degrees. The thermostat does not attempt to turn the heater on until the temperature falls below 19 degrees. Likewise,
the thermostat does not attempt to turn the heater on until the temperature rises above 21 degrees.
x 19
x = 20
On
x = a(x 30)
Off
x = ax
x 21
Figure 3.3: Hybrid automaton for the simple thermostat system.

A hybrid automaton for the thermostat is given in Figure 3.3 and a CIF model may look as follows.
Note that the value of a is defined as a constant that has value 0.1 in the second line.
automaton thermostat:
const real a = 0.1;
cont x = 20;
location Off:
initial;
equation x = - a * x;
edge when x <= 19 goto On;
location On:
equation x = - a * (x - 30);
edge when x >= 21 goto Off;
end

Exercise 3.1.1. Study the relationship between the hybrid automaton and the CIF model for
the simple thermostat. Play around with the CIF model for the simple thermostat. Simulate the
system with different values for the constant a and observe how this affects the evolution of the
variables. Also replace the constant value 30 by some other values and describe the effects.
Instantaneous updates of variables In many cases the effect of a mode switch should not
only be a change in the dynamics of the system in terms of a new set of differential equations that
describe the evolution, but also a instantaneous change of some of the variables. An example is a
system in which in one of its locations, a variable is used to guarantee that exactly t time units
pass in that location. Upon entering that location it is needed to set the value of this variable to 0
(to start measuring time). With each transition an update may be associated that describes how
the continuous variables are supposed to change instantaneously when that transition is taken.
As with the guard, the update is written close to the transition.
22
Example 3.1.2 (Vehicle). Consider the example of a vehicle that has four operational modes:
Driving, Standing still, Accelerating, and Decelerating. If the vehicle is driving (i.e., operating
in its operational mode Driving), its speed is fixed to be the given constant value s. When
Standing still, the speed is zero. In modes Accelerating and Decelerating the speed is increasing
and decreasing with some constant rate, say a.
Switching between the modes is arranged as follows. In each of the modes Driving and Standing
still the vehicle resides for exactly T time. The modes Accelerating and Decelerating are left as
soon as the speeds associated with driving and standing still are reached. The hybrid automaton
v=0
t=0
Standing still
v = 0
t = 1
tT
accelerate
Accelerating
v = a
t = 1
v=s
driving
t := 0
v=0
standing still
t := 0
Decelerating
v = a
t = 1
tT
decelerate
Driving
v = 0
t = 1
Figure 3.4: Hybrid automaton representing an extremely simplified vehicle. The variable v represents the speed of the vehicle. The constant s denotes its driving speed.
that models this vehicle is given in Figure 3.4. The variable v is used to represent the speed of the
vehicle. In order to measure the amount of time that elapses in the modes Driving and Standing
still a variable t is used. Note that it is set to zero each time one of these locations is entered
(also initially). The fact that the variable t behaves as a clock monitoring time is achieved by the
equation t = 1 which effectively states that t increases with the same rate as time. The dangling
incoming arrow in the location Standing still indicates that the system starts in that location.
The transitions are labelled with a name. This may be useful for understanding the behaviour of
this system in a simulation or may be useful in the context of networks of hybrid automata, to be
explained later on.
The CIF model for the simple vehicle case is as follows:
event accelerate, driving, decelerate, standing_still;
automaton simple_vehicle:
const real a = 10;
const real T = 25;
const real s = 100;
cont v = 0;
cont t = 0;
23
location Standing_still:
initial;
equation v = 0, t = 1;
edge accelerate when t >= T goto Accelerating;
location Accelerating:
equation v = a, t = 1;
edge driving when v = s do t := 0 goto Driving;
location Driving:
equation v = 0, t = 1;
edge decelerate when t >= T goto Decelerating;
location Decelerating:
equation v = -a, t = 1;
edge standing_still when v = 0 do t := 0 goto Standing_still;
end
Note that events need to be declared. As a convention, in this course, we will declare variables
globally, i.e., before the automata are declared.

Exercise 3.1.2. Simulate the model of the simple vehicle using the CIF tools. Select your own
values for the constants a, s, and T .

The guards of some of the transitions in the hybrid automaton in Figure 3.4 are of the form v = e
for some constant value e. Although this describes faithfully what was intended, when working
with simulation tools that use numerical approximations of values, it is most likely that the value
of v is never equal to the value represented by e. Therefore, it is wise to replace v = 0 by v 0
and v = s by v s.
Exercise 3.1.3. Make a CIF model for the hybrid automaton of Example 3.1.2. Are the transitions driving and standing still taken? Now replace with the guards as suggested below the
example. What do you observe in this case?

Based on observing the behaviour of the above model one may find that the transitions are taken
as soon as possible. This is indeed the case! In the formalism that is used in this course, CIF,
for modeling such hybrid automata, it is assumed that taking a transition that is enabled has
priority over spending more time in the source location of that transition. This phenomenon is
called urgency.
Exercise 3.1.4 (Lygeros). [22, before Exercise 1.6] Consider a machine in a manufacturing plant
that processes parts of type p one at a time. The machine can be in one of three states: Idle (I),
Working (W) or Down (D). The machine can transition between the states depending on certain
events. For example, if the machine is idle and a part p arrives it will start working. While the
machine is working it may break down. While the machine is down it may be repaired, etc. Give
an automaton that represents this system. You may use the three states mentioned before and
the events part arrives, complete processing, failure and repair). Assume that processing of
a part takes a given amount of time pt (for processing time) and that repairing will take at most
rt time.

Exercise 3.1.5 (Bouncing ball, [22, Section 3.1.1]). Develop a hybrid automaton model for a
vertically bouncing ball. The purpose of the model is to be able to show the position of the
bouncing ball. At each bounce, the ball loses a fraction of its energy, which means that after the
24
bounce the speed of the ball will be c times the speed of the ball before the bounce, and in the
opposite direction.

Exercise 3.1.6 (Water Tank System [22]). The two tank system, shown in Figure 3.5, consists
of two tanks containing water. Both tanks are leaking at a constant rate. Water is added to
the system at a constant rate through a hose, which at any point in time is dedicated to either
one tank or the other. It is assumed that the hose can switch between the tanks instantaneously.
x2
x1
r2
r1
v1
v2
Figure 3.5: The water tank system, copied from [22]

For i = 1, 2, let xi denote the volume of water in Tank i and vi > 0 denote the constant flow
of water out of Tank i. Let w denote the constant flow of water into the system. The objective
is to keep the water volumes above r1 and r2 , respectively, assuming that the water volumes are
above r1 and r2 initially. This is to be achieved by a controller that switches the inflow to Tank
1 whenever x1 r1 and to Tank 2 whenever x2 r2 . Give a hybrid automaton for this system
with the described controller. Simulate using the following values for the constants r1 = r2 = 0,
v1 = v2 = 1/2, and w = 3/4. Explain what you observe! Use the simulator to experimentally find
an appropriate value of w such that this problem disappears.
3.2
Discrete variables
As mentioned before, in many high tech systems not only quantities appear that continuously
change value but also often quantities are encountered that only change value in specific situations.
Discrete variables may be used to model such quantities. An example of such a quantity is the
number of vehicles waiting in front of a traffic light.
One way of modeling this is by introducing additional states. For example when modeling a
counter that maintains the balance of increment and decrement events, for each relevant value of
the balance a separate state may be introduced. Figure 3.6 gives the graphical representation of
such an automaton.
automaton counter:
event increment, decrement;
location C0:
3.2. DISCRETE VARIABLES
25
edge increment goto C1;

location C1:
edge decrement goto C0;
location C2:
location C3:
initial;
location C4:
location C5:
end
It goes without saying that the above solution can hardly be appreciated when the number of
different relevant values increases.
increment
C0
increment
C1
decrement
increment
C2
decrement
increment
C3
decrement
increment
C4
decrement
C5
decrement
Figure 3.6: (Hybrid) Automaton for the counter.
Obviously, it would be useful to have a special type of variables for which it is not needed to
blur the modelling with many states representing the different values of some quantity. For this
purpose we use discrete variables. Discrete variables are variables that remain constant during
time passage and which can change value only as a consequence of executing a transition. The
model of the counter example using a discrete variable is as follows. Figure 3.7 gives the graphical
representation of such an automaton.
automaton counter:
disc int count = 3;
location:
edge decrement when count > 0 do count := count - 1;
edge increment when count < 5 do count := count + 1;
end
The automaton has two edges, one for the increment event, and one for the decrement event. The
26

count = 3
count < 5
increment
count := count + 1
count > 0
decrement
count := count 1
Figure 3.7: (Hybrid) Automaton for the counter using discrete variables.
edge for the decrement event has a guard that indicates under which circumstances the event can
take place. The condition is indicated using the when keyword. In this case, the guard ensures
that the count can only be decremented if it is currently positive. The guard of the edge for the
increment event indicates that the count can only be incremented as long as it is less than five.
In general, a guard must hold in the source location of the edge, for the edge to be enabled, and a
transition to be possible. If the guard is not specified, it defaults to true, which always holds and
does not restrict the edge in any way.
Both edges also have updates, indicated using the do keyword. Updates can be used to specify
the effect of the transition on variables. In this case, the updates assign a new value to the count
variable that is one less or one more than the current value. That is the value of the count variable
is decremented or incremented by one.
This specification represents a counter that can be repeatedly incremented and decremented by
one, and ensures that the value of variable count is always at least zero and at most five. Note that
adapting the above model to a counter for a different (potentially much larger) counting range is
achieved by replacing the constants 0 and 5 by the lower and upper bound of the counting range.
Once again, discrete variables can only change value by explicitly assigning them a new value in
the do part of an edge. If an edge does not assign a value to a discrete variable, that variable
keeps its current value. Consider the following CIF specification:
automaton lamp:
event turn_on, turn_off;
disc int count = 0;
location off:
initial;
edge turn_on
location on:
edge turn_off
end
do count := count + 1 goto on;
goto off;
This is an automaton representing the turning on and off of a lamp, where additionally the number
of times that the lamp is turned on is counted. The edge for the turn on event increments the
value of the variable by one, each time the lamp is turned on. The edge for the turn off event does
not assign a value to a variable, so variable count keeps its value when the lamp is turned off. See
Figure 3.8 for the graphical representation.
Exercise 3.2.1. It is possible to give a model for the counter discussed above without using
locations for representing the counter values and without using discrete variables. Give a model
for the counter in which you use continuous variables instead.

Exercise 3.2.2. Two philosophers are seated at a round table where there are two plates of food,
3.3. INVARIANTS
27
turn on
count := count + 1
count = 0
On
Off
turn off
Figure 3.8: (Hybrid) Automaton for the lamp.

one in front of each philosopher, and two forks, one on each side between the plates. The behaviour
of each philosopher is as follows. The philosopher may be thinking or he may want to eat. In
order to go from the thinking state to the eating state, the philosopher needs to pick up both
forks on the table, one at a time, in either order. After the philosopher is done eating, he placed
both forks back on the table and returns to the thinking state.
Provide a model for the two philosophers and the forks. Use events with names ifj for philosopher
i picks up fork j and jf for philosopher j puts both forks down. Is there any admissible behaviour
of the philosophers that results in the system getting stuck, i.e., there are no more events possible?
3.3
Invariants
In the example of the counter variable, to keep the count in the allowed range of values, guards were
used to limit the occurrence of the increment and decrement events. Instead of using guards, it is
also possible to use invariants. In hybrid automata invariants are associated with a location. An
invariant of a location specifies a condition in terms of the values of the variables of the automaton
that must always hold when the model resides in that location. Consider the following adapted
model of the counter automaton (see Figure 3.9 for the graphical representation).
count = 3
increment
count := count + 1
0 count 5
decrement
count := count 1
Figure 3.9: (Hybrid) Automaton for the counter with invariant.
automaton counter:
disc int count = 3;
location:
28
initial;
invariant count >= 0 and count <= 5;
edge decrement do count := count - 1;
edge increment do count := count + 1;
end
// Added invariant
// No more guards
The guards on the edges have been replaced by the invariant. The invariant specifies that the
value of variable count must always be at least zero and at most five. In CIF it is not allowed to
use time-dependent variables in an invariant.
For the counter example, initially the count is 3. The edge for the increment event can be taken,
leading to a state where the count is 4. Taking another transition for the increment event leads
to a state where the count is 5. If we then were to take another transition for the increment
event, the count would then become 6. However, that violates the invariant. Therefore, in the
state where the count is 5, no transition for the increment event is possible. In other words, the
invariant disables the transition for the increment event for that state.
Note that it may be the case that different locations in an automaton have different invariants.
The benefit of guards over invariants is that they more explicitly state the condition under which
an edge can lead to a transition. If a guard does not hold, the edge cant be part of a transition. It
is thus immediately clear when the edge can lead to a transition. For invariants, the update has
to be calculated first, after which the invariants can be evaluated for the state resulting from the
transition. If one of the invariants does not hold, the transition is not allowed. In the case of the
invariants, it is not as immediately clear from the edge alone, when that specific edge can or can
not lead to a transition.
The benefit of a location invariant over guards is that they apply to all incoming edges. If
several incoming edges of a location have updates to the same variable, then the invariants need
to be specified only once, and apply to all the incoming edges. Using guards, all the incoming
edges that modify the variable would need their own guards, and if the updates are different, the
different edges usually require different guards. Furthermore, if new edges with updates to the same
variables are added, the invariant is already present, whereas guards have to be added explicitly,
which can easily be forgotten. In those cases, invariants can thus help keep the specification
consistent.
Another benefit of invariants is that they explicitly state the conditions that must hold in relation
to the variables, while guards specify the condition under which the update is allowed. Consider
the following CIF specification:
// Using invariants.
automaton a:
disc int x;
location:
initial;
invariant 0 <= x and x <= 100;
edge do x := 2 * x + 3;
end
// Using guards.
automaton a:
disc int x;
3.4. NETWORKS OF HYBRID AUTOMATA
29
location:
initial;
edge when x <= 48 do x := 2 * x + 3;
end
The goal is to keep the value of variable x in the range [0..100]. The invariant is simple and direct.
The guard however, has to state the condition under which the update does not violate the goal.
That is, the upper bound has to be decreased by three, and the result has to be divided by two,
to get the highest value (48) for which the update is still within the valid range of values. That is,
for value 48 the update results in value 99 (2 * 48 + 3 = 99), and for value 49 the update results
in value 101 (2 * 48 + 3 = 99). An even more complex reasoning is needed to establish that there
is no lower bound needed for the value of the variable before the update. The more complex the
update, the harder it is to figure out the guard to use to keep satisfy the goal. In technical terms,
the guard of a specific update needs to be strengthened with the weakest liberal predicate w.r.t.
the invariant and the update.
You can of course also use 2 * x + 3 <= 100 as guard, instead of x <= 48. However, this
duplicates part of the update in the guard.
So far, all invariants have been specified in locations. They may however also be specified in
automata and even outside of the automata. It is generally recommended to place an invariant at
the highest level where it applies to all constituent elements. The counter may thus be modeled
as follows using an invariant at the automaton level.
automaton counter:
disc int count = 3;
invariant count >= 0 and count <= 5;
// Added invariant
location:
initial;
edge decrement do count := count - 1; // No more guards
edge increment do count := count + 1;
end
3.4
Networks of hybrid automata
Suppose that we need to model a traffic light system consisting of n traffic lights and a controller
that has the obligation to guarantee that the complete system behaves safely (as long as drivers
and automobiles behave as prescribed by the traffic lights). The state of the system can be
characterized as a combination of the states of the contained traffic lights and the state of the
controller. For a traffic light with k different states (usually k equals two or three) and a controller
with l locations this results in k n l locations!
To ease the modelling of such a system we introduce networks of automata. A network of automata
consists of a finite collection of automata. These automata may share events and variables. The
automata in a network of automata execute at the same time. They interact with each other by
synchronizing on shared events and by the shared use of variables.
30
Synchronization on time If automata in a network of automata do not share events and do

not use variables of one another they only synchronize in time. This means that the notion of time
that is implicit in the differential equations that describe the evolution of continuous variables is
the same for all automata. As a simple example consider the two automata presented in Figure
3.10. Simultaneous execution of these gives that the two variables x and y are always in the
relation x = 2 y, because the derivative of x is twice the derivative of y.
x=0
x = 2
y = 1
y=0
Figure 3.10: Hybrid Automata that synchronize on time.
Synchronization of events Events that are used in multiple automata, must synchronize.
That is, if one of those automata performs a transition for that event, the other automata must
also participate by performing a transition for that same event. If one of the automata that uses
the event can not perform a transition in its current location, none of the automata can perform
a transition for that event. To illustrate this, consider the following CIF specification:
automaton producer:
event produce, provide;
location producing:
initial;
edge produce goto idle;
location idle:
edge provide goto producing;
end
The automaton represents a producer that produces products, to be consumed by a consumer.
The producer automaton starts in its producing location, in which it produces a product. Once
the product has been produced, indicated by the produce event, the automaton will be in its idle
location, where it waits until it can provide the produced product to the consumer. Once it has
provided the product to the consumer, it will once again be producing another product. Consider
also the following continuation of the above specification:
automaton consumer:
event consume;
location idle:
initial;
edge producer.provide goto consuming;
location consuming:
edge consume goto idle;
end
31
This second automaton represents a consumer that consumes products. The consumer is initially
idle, waiting for a product from the producer. Once the producer has provided a product, the
consumer will be consuming. Once it has consumed the product, as indicated by the occurrence
of the consume event, it will become idle again. See Figure 3.11 for the graphical representation
of the automata.
produce
Producing
provide
Idle
provide
Consuming
Idle
consume
Figure 3.11: Hybrid Automata that synchronize on events. The event provide is shared between
the automata and therefore will only be executed when both automata allow this.
The specification has three events, the produce and provide events declared in the producer automaton, and the consume event declared in the consumer automaton. The consumer automaton,
in its idle location, has an edge that refers to the provide event declared in the producer automaton. As such, that edge and the edge in the idle location of the producer automaton, refer to the
same event.
Now, lets take a closer look at the behavior of the producer/consumer example. Initially, the
producer automaton is in its producing location, and the consumer automaton is in its idle location.
Since the producer is the only automaton that uses the produce event, and there is an (outgoing)
edge in its current location for that produce event, the producer can go to its idle location by
means of that event.
Both the producer and consumer use the provide event. The producer has no edge with that event
in its producing location, while the consumer does have an edge for that event in its idle location.
Since events must synchronize, and the producer can not participate, the event can not occur at
this time. This is what we expect, as the producer has not yet produced a product, and can thus
not yet provide it to the consumer. The consumer will have to remain idle until the producer has
produced a product and is ready to provide it to the consumer.
The producer blocks the provide event in this case, and is said to disable the event. The event is
not blocked by the consumer, and is thus said to be enabled in the consumer automaton. In the
entire specification, the event is disabled as well, as it is disabled by at least one of the automata
of the specification, and all automata must enable the event for it to become enabled in the
specification.
The only behavior that is possible, is for the producer to produce a product, and go to its idle
location. The consumer does not participate and remains in its idle location. Both automata are
then in their idle location, and both have an edge that enables the provide event. As such, the
provide event is enabled in the specification. As this is the only possible behavior, a transition for
the provide event is performed. This results in the producer going back to its producing location,
while at the same time the consumer goes to its consuming location.
In its producing location, the producer can produce a product. Furthermore, in its consuming
location, the consumer can consume a product. Two transitions are possible, and CIF does not
define which one will be performed. That is, either one can be performed. No assumptions should
be made either way. In other words, both transitions represent valid behavior, as described by
this specification. Since only one transition can be taken at a time, there are two possibilities.
Either the producer starts to produce the product first, and the consumer starts to consume after
32
that, or the other way around.

Once both transitions have been taken, we are essentially in the same situation as we were after the
producer produced a product the first time, as both automata will be in their idle locations again.
The behavior of the specification then continues to repeat forever. However, for each repetition
different choices in the order of production and consumption can be made.
All possible traces together form the state space, which represents all the possible behavior of a
system. For the producer/consumer example, the state space is given in Figure 3.12.
p/i
consume
p/c
produce
e
vid
o
pr
produce
i/i
consume
i/c
Figure 3.12: State space of the producer/consumer network.

Here the circles represent the states of the specification, which are a combination of the states of
the two automata. The labels of the circles indicate the state, as a combination of the first letters
of the locations of the automata. The initial state is labeled p/i, as initially automaton producer
is in its producing (p) location, and the consumer is in its idle (i) location. The arrows indicate
the transitions, and are labeled with events. The state space clearly shows the choices, as multiple
outgoing arrows for a single state.
By using multiple automata, the producer and consumer were modeled independently, allowing
for separation of concerns. This is an important concept, especially when modeling larger systems.
In general, the large system is decomposed into parts, usually corresponding to physical entities.
Each of the parts of the system can then be modeled in isolation, with little regard for the other
parts.
By using synchronizing events, the different automata that model different parts of a system, can
interact. This allows for modeling of the connection between the different parts of the system,
ensuring that together they represent the behavior of the entire system.
Exercise 3.4.1. Recall Exercise 3.2.2 about the dining philosophers. Develop a model of the
system where each philosopher and each fork is modelled as a separate automaton. Is there a
deadlock in this system? Add an automaton that prevents the deadlock from occurring while
maintaining all other behaviour of the system.

Exercise 3.4.2 (Pump-valve-controller system, adapted from [9, Example 2.25]). Consider a
heating system consisting of a pump, a valve, and a controller. In Figure 3.13 the models of the
pump and the valve are shown. The model for the valve contains states VC and VO representing
the situations that the valve is closed and opened, respectively. Additionally, the states SO and
SC represent that the valve is stuck when opened or closed. The events are easily understood by
their names. The model for the pump should be straightforward.
1. Make a CIF model for the pump and valve and simulate the system a number of times.
Observe that the pump can be started while the valve is still closed.
2. Develop a model of a controller that may use the events open valve, close valve, start pump,
and stop pump and that prevents that the pump is operating while the valve is closed.
Simulate your extended model to gain confidence in your solution.
33
stop pump
close valve
VC
stuck closed
SC
Poff
open valve
stuck open
stuck closed
stop pump
start pump
close valve
SO
stuck open
VO
Pon
open valve
start pump
Figure 3.13: Network of nondeterministic automata for the pump-valve-controller system consisting of automata for the valve and the pump.
Exercise 3.4.3. For the pump-valve-controller system, model a valve flow sensor. It may be
assumed that the sensor is discretized to two possible values, namely flow and no flow. First,
establish under what conditions the valve flow sensor should report a flow event and in which
circumstances it must report a no flow event.

Shared variables Discrete variables can only be declared in one automaton, and may only be
assigned (given a value, written) by that automaton. Continuous variables may either be declared
in an automaton as is the case for the discrete variables, or may be declared globally. In the latter
case they can not be assigned a different value on an edge. All variables may however be read
globally. Consider the following CIF specification:
automaton queue1:
event enter, leave;
disc int count = 0;
location:
initial;
edge enter when count < 2 do count := count + 1;
edge leave when count > 0 do count := count - 1;
end
automaton queue2:
event enter, leave;
disc int count = 0;
34
location:
initial;
edge enter when count < 2 do count := count + 1;
edge leave when count > 0 do count := count - 1;
end
automaton customer:
location:
initial;
edge queue1.enter when queue1.count <= queue2.count;
edge queue2.enter when queue2.count <= queue1.count;
end
This specification models a supermarket, and features a customer and two queues. Customers
arrive and enter either of the queues. Eventually customers leave the queue.
Both queues (automata queue1 and queue2) are identical, except for their names3 . Each queue
maintains a variable count, which represents the number of customers in the queue. A queue is
full if it contains two customers. Customers can thus only enter a queue if less than two customers
are present. Similarly, it is only possible for a customer to leave a queue if there is a customer in
the queue.
Customers decide to which queue they go, based on the number of customers already present in
those queues. A customer only enters the first queue if that queue has less than or the same
number of customers as the second queue. Similarly, a customer only enters the second queue if
that queue has less than or the same number of customers as the first queue. If the queues have
the same number of customers, the customer can choose either queue.
The enter event declared in the first queue (queue1) is used by both the customer automaton and
the queue1 automaton. The event is thus only possible (enabled) if both automata can participate.
Both automata restrict the occurrence of the event using a guard. The event is thus only possible
if both guards hold. That is, a custom never enters the first queue if it is full, but it also never
enters that queue if it has more customers than the second queue.
The customer automaton uses the values of the variables of the queue automata, and thus reads
variables of other automata. This is allowed, due to the global read concept of CIF. This concept
allows for short guards, that directly and intuitively represent the condition under which an event
may take place.
The global read concept should only be used when it is intuitive. In the supermarket example,
the customer can physically see how many customers are in the queues. It is therefore intuitive
to directly refer to the count variables of the queue automata. If however the customer would not
be able to physically observer the queues, then the customer would not be able to directly base
its decision of which queue to join, on that information. In that latter case, it may not be a good
idea to model the guard in such way.
The local write concept means that discrete variables can only be written by the automata in which
they are declared. It is not allowed for the customer and queue2 automata to write (change the
value of) the count variable of the queue1 automaton. Only the queue1 automaton may write that
variable. The local write concept prevents that multiple automata write to the same variable, as
part of a synchronizing event, potentially causing conflicting values to be assigned to that variable.
3 CIF
offers features for reuse and parameterization of automata.

the scope of this course.
The online language tutorial contains
http://cif.se.wtb.tue.nl/lang/tut/index.html
However these are beyond

all the relevant information:
35
This leads to several benefits, most notably simpler semantics.

Exercise 3.4.4. For the pump-valve-controller system, as in Exercise 3.4.3, model a valve flow
sensor. This time collect the resulting value in a variable flow.

Exercise 3.4.5 (Manufacturing process). [9, Exercise 2.39] A simple manufacturing process involves two machines, M1 and M2 , and a buffer B in between. There is an infinite supply of parts
to M1 . When a part has finished processing at M1 , it is placed in B, which has a capacity of
one part only. The part is subsequently processed by M2 . Each machine has three states Idle,
Processing, and Down. Each machine has four transitions: event start from Idle to Processing,
event end from Processing to Idle, event Breakdown from Processing to Down and event repair
from Down to Idle. See Figure 3.14 for the automata.
start M1
Idle
end M1
breakdown M1
Processing
Down
repair M1
end M1
start
Empty
Full
start M2
start M2
Idle
end M2
breakdown M2
Processing
Down
repair M2
Figure 3.14: Network of nondeterministic automata for the simple manufacturing system consisting
of automata for two machines and one buffer.
Give a separate controller for each of the following requirements:

M1 can only begin processing if the buffer is empty;
M2 can only begin processing if the buffer is full;
M1 cannot begin processing if M2 is down;
If both machines are down, then M2 gets repaired first.
36
Can you establish whether the system consisting of all these automata has deadlock? Deadlock
is the situation that no more events can be executed from a state of the system which may be
reached from the initial state.

Exercise 3.4.6 (Traffic system [9, Exercise 3.28]). Consider the traffic system shown in Figure
3.15. There are two vehicles, denoted by a and b, that must go from the origin to the destination.
The road is divided into four sections, numbered 1 - 4. There are traffic lights at the entrances of
sections 1 and 4. There are vehicle detectors at the entrances of sections 1, 3, and 4 and at the
destination.
Figure 3.15: Traffic system; schematic representation.

Let events ai (and bi ) (for 1 = 1, . . . , 5) denote that vehicle a (and b) enters section i, where section
5 is the destination. Develop a model for a controller that guarantees that (i) the two vehicles
must reach the destination, and (ii) only one vehicle can be in a road section at any given time (in
order to avoid collisions). You may assume that vehicle a can only perform the sequence of events
a1 a2 a3 a4 a5 and that vehicle b can only perform the sequence of events b1 b2 b3 b4 b5 . The controller
may only use the events a1 , a3 , a4 and a5 and the similar b-events. Take care that your controller
does not prevent the events a3 and b3 from happening since there is not traffic light at the start
of section 3. Is your controller more restrictive than necessary?

Exercise 3.4.7 (Railroad-gate controller [18]). We consider a railroad-gate controller. The train
is modeled by the automaton of Figure 3.16. It approaches the crossing at a speed between 45 and
55 meters per time unit. When it is 1000 meters from the crossing, a sensor signals its approach
to the controller, and the speed of the train is reduced to the range of 35 to 50 meters per time
unit. A second sensor, at 100 meters past the crossing, signals the exit of the train. The train
may return to the crossing, but only on a route that is at least 5100 meters long.
The controller, modeled by the automaton of Figure 3.16, lowers and raises a gate at a railroad
crossing. Whenever it detects the presence of an oncoming train, it closes the gate after a fixed,
yet unknown, amount of time, as measured with the local clock x. The controller raises the gate
when the train exits the vicinity of the crossing.
The complete system is represented by the parallel composition of the controller automaton and the
train automaton. In this example, event labels are used to synchronize the concurrent execution
of the controller and the train: the events train present must be executed simultaneously, thus
ensuring that the controller receives the approach signal from the train; similarly, the events
train leaves must be executed simultaneously, ensuring that the controller receives the exit signal
from the train (as before, edges without event labels are executed individually).
As you can see the equations defining the speed of the train have been omitted from the automaton.
Find appropriate (simple or complex) equations for these speeds such that these are in line with
the statements made about these speeds previously. Use simulation of a CIF model based on these
automata and establish a value for the closing of the gate according to which the gate is always
closed at the moment a train passes.
37
d 100
train leaves
d = 5000
Far
d := 5000
Approaching
d =?
d 1000
train present
Near
d =?
x=0
Open
x = 0
train present
x := 0
Closing
x = 1
x ?
Closed
x = 0
train leaves
Figure 3.16: Train automaton and railroad-gate controller automaton. Note that the gate closing
time is not given in the railroad-gate controller automaton.
38
Chapter 4
Supervisory control of a patient

support system
This chapter is based on the bachelor final project executed by J.W.H. Verhoeven [44].
Complex modern machines require some form of control to operate properly. The interactions
between the sensors and actuators through the machine form the uncontrolled system behavior.
The controlled behavior can be achieved by processing the sensor information and controlling the
actuators. The code for the controller can be derived from its control requirements. These specify
the desired behavior for a certain set of sensor and state values.
A magnetic resonance imaging (MRI) scanner is a complex machine that is used to create medical
images of the patient. Strong magnetic and radio frequency fields are used to get protons in
the body into exited states. By turning of the radio frequency fields the protons return to their
equilibrium states. The rates at which they return to their equilibrium states depend on the sort
of tissue and this allows the MRI scanner to form images of the different tissues. By applying
additional magnetic fields the orientation of the image can be changed.
Figure 4.1: Patient support system

39
40
CHAPTER 4. SUPERVISORY CONTROL OF A PATIENT SUPPORT SYSTEM
The patient lies on a table called the patient support system (PSS, see Figure 4.1). This table can
be used to move the patient in and out of the bore of the scanner. The PSS consists of a table
with a removable tabletop and a user interface (see Figure 4.2). The table can be moved along a
vertical and a horizontal axis. The upper and lower limits of the vertical axis are monitored by two
position sensors. The horizontal axis also has an inner and outer limit sensor as well as a position
encoder which determines the position of the table along the horizontal axis. The tabletop can
be removed using the tabletop release button. The presence of the tabletop is measured with the
tabletop sensor. When the clutch is engaged the motorized movement of the table is possible.
This is controlled with the tumble switch. When the clutch is disengaged the table can be moved
manually.
Figure 4.2: User interface buttons

The goal of this chapter is to illustrate the use of CIF to create a model for the PSS that can deal
with failures and disturbances. This model makes use of a hybrid observer. It uses a hybrid model
to track where the table should be and combines that information with the sensor input to detect
possible errors. A specific question is in what capacity the error handling should be integrated
with the normal control strategy.
In Section 4.1 the patient support system without any error handeling is discussed. Section
4.2 introduces the possible errors and how they should be solved. The integration of the error
handeling in the controller is discussed in Section 4.3. In each chapter the real world model is
explained first. In the second part of these chapters the implementation in the CIF code can be
found.
4.1
The ideal patient support system
In this section the model of the ideal patient support system is introduced. In this ideal model it
is assumed that all components of the PSS work properly and that there are no disturbances. The
model for the patient support system is split into a hardware file and a software file. The hardware
includes separate automata for both axes, all sensors and the tumble switch. The software contains
the controller automaton along with the error detection automaton. In this section the hardware
components and the basic controller will be discussed.
4.1.1
Real world model
In order to model the PSS in CIF, a model of the real world device needs to be made. This
model will deal with the physical behavior of the PSS. This needs to be modelled to simulate the
operation of the controller. In this section the model the PSS is discussed.
Vertical and Horizontal axes The patient support system can move along two axes, a vertical
and a horizontal axis. The table can be moved up on the vertical axis in order to align the table
with the bore. The table can then be moved along the horizontal axis to move the table into the
bore. In order to avoid collisions between the table and the bore the table should only move along
the horizontal axis when it is at the top of the vertical axis and along the vertical axis while it is
4.1. THE IDEAL PATIENT SUPPORT SYSTEM
41
at the outer position on the horizontal axis. When the PSS is not moving along one of the axes,
the brake on that axis is engaged in order to prevent movement.
At each end of both axes is a sensor. These sensors can be activated or not activated. When the
table is in front of the sensor it is activated. The sensor is placed slightly before the end of each
limit to allow the PSS time to decelerate.
On the horizontal axis there is an encoder. This encoder tracks the horizontal position of the table.
Whenever the table is removed and placed the encoder needs to be recalibrated. The encoder is
re-calibrated on the outer sensor on the horizontal axis.
The table can be disengaged from the horizontal motor. This can be done with either the clutch
or the tabletop release button, which is located on the PSS. When the table is disengaged it can
be moved freely along the horizontal axis without the engine.
User interface The operator of the MRI scanner controls the PSS. The motions of the PSS are
controlled via a tumble switch. Moving this tumble switch to one side moves the table upwards
and inwards. Moving it to the other side moves it outwards and downwards.
There are also several buttons present on the user interface console and the table itself. The
table itself can be removed. While the table is removed it can not be moved along the horizontal
axis. When the table is present it can only be moved along the horizontal axis when the clutch
is engaged. The operator has a button to disengage the clutch. There is also a tabletop release
button present on the PSS. This button also disables the motorized movement along the horizontal
axis.
On the user interface a LED is present to communicate the status of the device.
Controller without error handling In order to let the sensors and actuators interact, a
controller is needed. The controller turns on the engines based on the states of the sensors and the
input from the tumble switch. The controller also tracks along which axis the table has moved and
whether it should move along the vertical or horizontal axis. When the table is on a position on
the vertical axis, the sensor at the top of the vertical axis is turned off and the tumble switch is in
the upward position, the vertical motor is started for the upward motion. The controller turns of
the appropriate motors when the PSS approaches the end of an axis. When the table transitions
between the two axes, the controller brings the table to a full stop before beginning the motion
along the new axis. When the table is disengaged from the horizontal motor, the controller should
prevent activations of the motor.
4.1.2
Model of the ideal patient support system
Vertical and Horizontal axes In the CIF model the movement along the vertical axis is
modelled in a single automaton. There are three possible states for the motor: moving, stopping
and stopped. There are two locations for moving since there are two directions: up and down.
The same applies for stopping. While the table is moving motorized it accelerates until it reaches
its maximum speed. When either outer limit is reached the table decelerates and stops. This
is modelled in the controller as it is an interaction between sensors and actuators. The vertical
axis is modelled as a second order dynamical system. Both the acceleration of the table and its
deceleration are taken into account.
automaton vmotor :
cont y =0.0;
cont v =0.0;
42
location moving_up :
equation v =
if v >=1 :
else
end ;
equation y =
v;
0.0
1.0
edge when controller . a_vmotor = -1

edge when controller . a_vmotor =0
location stopping_up :
equation v = -1.0;
equation y =
v;
goto moving_down ;
goto stopping_up ;

edge when v <=0.0
goto moving_down ;
goto moving_up ;
goto stop ;
location stop :
initial ;
equation v =0.0;
equation y =0.0;
goto moving_down ;
goto moving_up ;
There are two values that are calculated with a differential equation in each state: the position y
and the velocity v. These values are initialized at zero because the starting position of the table
during the simulation is a the bottom of the vertical axis. When the automaton is in a moving state
the table accelerates until the table is moving at a constant speed. By calculating the position in
a differential equation using the speed, the position can be determined as a function of time. This
is necessary for the interactive simulation.
While the automaton is in a stopping location the table decelerates. When the speed becomes
zero it transfers to the stopped location. While the table is stopped both the acceleration and
speed are considered zero. This is done to prevent any movement from rounding errors in v. The
interaction between the motor and the controller is arranged via the a vmotor variable. This value
is set in the controller automaton and can be set to one, zero or minus one. This variable indicates
whether the motor is on and in which direction it is moving.
The horizontal axis is modelled similarly to the vertical axis. It is also a single automaton with
three possible states. What differentiates it from the vertical axis is a new location called disengaged. When the clutch is disengaged the motorized movement of the table is not possible. When
in the disengaged position the table behaves as in a stopped position. The location transitions are
however different.
location disengaged :
equation v =0.0;
equation x =0.0;
edge when clutch . on and tabletop . on and ttr . on
goto stop ;
All of the sensors are instantiations of the same automaton definition. The four specific sensor are
generated with different parameters. The sensors are located before the ends of the axes to allow
for deceleration. The activation point of the sensor differs from its deactivation point in order to
simulate hysteresis.
automaton def sensor ( alg real p1 , p2 , p3 , p4 ; alg string name ) :
location on :
4.1. THE IDEAL PATIENT SUPPORT SYSTEM

edge when p1 <= p3
43
goto off ;
location off :
initial ;
edge when p2 > p4
goto on ;
svgout id < string > name attr " fill " value if on : " green " else "
white " end ;
end
topsensor
botsensor
insensor
outsensor
:
:
:
:
sensor ( vmotor .y , vmotor .y ,9.0 ,9.5 , " topsen " ) ;

sensor (1.0 ,0.5 , vmotor .y , vmotor .y , " botsen " ) ;
sensor ( hmotor .x , hmotor .x ,9.0 ,9.5 , " insen " ) ;
sensor (1.0 ,0.5 , hmotor .x , hmotor .x , " outsen " ) ;
The sensors are modeled as a simple automaton with two states: on and off. The automaton uses
the position values from the horizontal and vertical axis automata and evaluates these against the
given activation and deactivation points. These are the values p1, p2, p3 and p4. Which of these
parameters is the activation or deactivation point and which is the position depends on which
sensor it is.
In the sensor definitions the value for p1, p2, p3 and p4 are given as well as the names for the
sensors. The parameter name of type string is used for the visualization.
A position encoder is present along the horizontal axis. This encoder tracks the position of the
table. The encoder needs to be homed in order to work. This homing happens when the table
reaches the out position and activates the sensor. From then on until the table is removed can be
in four possible locations: in, out, mid safe and mid unsafe. This is based on the real position in
the horizontal axis automaton.
User interface The tumble switch does not have its own automaton. In the SVG that is used
for the interactive visualization a tumble switch with the three positions is present. When clicked
these generate an uncontrollable event. These events also appear in the controller automaton.
The clutch, tabletop and tabletop release switch are all modelled as simple automata with two
locations. They are either present or engaged in which case motorized movement of the device
is possible. If one of these automatons is in the disengaged or removed positions the motorized
movement along the horizontal axis is not possible and the controller will prevent this motorized
movement. The tabletop has one additional requirement that it cannot be removed while the table
is inside the bore because this is physically impossible. The uncontrollable events, u table in
this case, are used in the interactive visualization to simulate the user input.
automaton tabletop :
monitor ;
location on :
initial ;
edge u_table when hmotor .x <=5.0
location off :
edge u_table
goto off ;
goto on ;
svgout id " table " attr " opacity " value if on :1.0 else 0.3 end ;
svgout id " tablebutton " attr " height " value if on :50.0 else 70.0 end ;
svgout id " tablebutton " attr " y " value if on : 460.0 else 440.0 end ;
44
end
There is a LED present that indicates whether the system is operating properly. The LED can be
on or off or blink quickly or slowly. The automaton for the LED therefore has these four locations.
It is only present for visualization purposes since it has no direct influence on the operation of the
PSS.
Controller without error handling The controller uses the sensor information and the user
input from the tumble switch to activate the actuators. The basic controller does this without
taking the errors into account. The controller automaton has nine locations. Four locations
deal with the motion in the four directions, two ways along the horizontal and two ways along
the vertical axis. Since the movements are mutually exclusive, meaning that the table can only
ever move in one direction at the a time, they can be modelled as separate locations in the same
automaton. The other five locations deal with the stopped positions of the system. It has separate
automata for the two outermost positions, the bottom and the inner position. It also has two stop
locations for in between these locations, one for the horizontal axis and one for the vertical axis.
The final stopped location is for the point at the top of the vertical and the outer edge of the
horizontal axes where the table is stopped when transiting from moving along one axis to moving
along the other.
When the table is moving upwards along the vertical axis and it approaches the top the movement
along the vertical axis should be stopped. If the tumble switch is kept in the up position the table
should proceed to move inwards when it has arrived at the top. The opposite applies when the
table is moving outwards and it approaches the out sensor.
The location of the controller automaton can be changed via the tumble switch, which can be
seen by the generated events u up and u stop. The location can also be changed based on the
sensor information and the locations of the tabletop release button and clutch. The table can only
move inwards while the encoder is homed. Motorized movement along the horizontal axis is only
possible if the table is present and the clutch is engaged.
location
edge
edge
edge
edge
going_out :
u_up when not encoder . unhomed
u_stop
when outsensor . on
when ttr . off or clutch . off
goto
goto
goto
goto
going_in ;
stop_h ;
stop_top ;
stop_h ;
Visualization In order to test and validate the model an interactive visualization is made. In
the visualization an abstract image of a patient support system is used. The table should be moved
up and down and left and right. The bounds indicate the space in which the table can be present.
On the left the tumble switch and the buttons for the table, tabletop release and the clutch can
be found. These buttons are used for the normal operation of the table. The box in the bottom
right corner holds the buttons for the error generation. The box in the bottom left represents the
display on which the messages are displayed to the operator. The sensors and lights can change
in colour to indicate their location.
4.2
Errors
In this section the errors that are the result of failures and disturbances in the system are discussed.
The errors can be introduced in the simulation via the error console.
4.2. ERRORS
45
Figure 4.3: Figure for interactive visualization
4.2.1
Real world model
When designing a controller that can deal with errors one must first figure out what the desired
handeling is. Ideally the controller would be able to solve all problems created by disturbances on
the machine. This is however not possible because the error detection can never be perfect. The
controller might make a faulty diagnosis due to a combination of multiple errors. Therefore the
controller cannot solve the problems on its own and it needs to leave the actions to the operator.
The controller itself should diagnose the problem and suggest a solution to the operator. The
controller has limited sensor information and can therefore not always detect what exactly is
going wrong. It can however generally detect that something is going wrong. It is also possible
that multiple errors occur simultaneously. This might cause the controller to be unable to correctly
diagnose the problem or to correctly solve it.
Not all possible errors have been implemented in the model. The errors that have been excluded are
both rare and either impossible to diagnose or impossible to solve. For instance a faulty tabletop
sensor would be more easily noticed by the operator and cannot be solved by the controller.
Sensor failure It is possible for the sensors in the system to fail. Most notably, the outer
limit sensors on the bottom and top of the vertical axis and the inner and outer sensors on the
horizontal axis. The other sensors like the tabletop sensor can also fail but this is less dangerous.
The sensors could become defective and either not turn on at all or stay active when they should
not. False sensor input could also be the result of human intervention when for instance the
patient accidentally holds his hand in front of the sensor.
Errors in the operation of the sensors could have serious consequences. If the table is not fully in
its upper position when it starts its motion along the vertical axis the PSS could collide with the
bore. Therefore, a premature activation of the upper limit sensor has to be detected.
When a sensor fails it could either not activate when it has to, or activate when it should not.
When this happens, the sensor will not activate when the controller expects it to. The desired
behavior is then to recalibrate the internal position on the opposite sensor on the axis. The table
can then move back along to see if the sensor activates when expected. If the sensor error was
caused by something like a body part accidentally blocking the sensor, it should be resolved. If
the problem persist like when the sensor is broken a mechanic has to come and fix the issue.
46
Motion disturbances Another possible source of errors could be disturbances on the position of
the table. This could for instance be caused by someone bumping into the table or an added source
of friction while the table is moving. The results of such disturbances can not be differentiated
from the sensor errors from purely the results of the sensor output and as such they need to be
taken into account.
The motion disturbances cause errors similar to the sensor errors. When the table is experiencing
additional friction it will move slower than expected. The appropriate sensors will not activate
when the system expects it because the table has not reached its position yet. Since this causes
errors that cannot be distinguished from the sensor errors by the controller they should be treated
the same. The solution given above also solves the issue if the cause of the problem is gone. This
would be the case is the error was caused by someone bumping into the machine. If the source of
the motion disturbance is still present, a mechanic is also needed to investigate the issue further.
When the break fails and the table starts falling a similar error is generated. This error is however
essentially a displacement error and its solution is identical.
Hysteresis
When hysteresis occurs, the deactivation point of a sensor can differ from its activation point.
When this happens the sensor has a work range, dx in figure 4.4, instead of a work point. When
Figure 4.4: Sensor hysteresis

this for instance occurs with the upper limit sensor, the system can think that the table is in
the upmost position while this is not the case. If the motion along the horizontal axis is then
started, the table could experience great friction or even collide with the bore. Therefore when the
controller detects that sensor hysteresis occurs, motion along the other axis should be prevented.
While this situation is not very common it is extremely important that it is prevented when it
does happen.
4.2.2
Model of the errors
In order for the controller to deal with the errors they need to be introduced into the simulation.
This can be interactively done via the error console in the SVG. The some of the errors are handled
in their own automaton while others are included in the errors of the system.
4.2. ERRORS
47
Hysteresis implementation The hysteresis is implemented directly in the sensor automaton.

Because hysteresis is a fundamental problem of the sensor it does not need to be introduced by
the error console. It occurs during the normal operation of the table. The hysteresis is modelled
by giving the sensor two different position values for the its activation and its deactivation. The
values p1, p2, p3 and p4 are the positions that are evaluated for the transitions of the sensor
locations. Because the equations use larger than and smaller than signs, these position can be
either the table position or the activation or deactivation point. This depends on which sensor it
is. The l1 and l2 Booleans are implementations of the sensor errors and are discussed in the next
subsection.
automaton def sensor ( alg real p1 , p2 , p3 , p4 ; alg string name ; alg bool l1 ,
l2 ) :
location on :
edge when p1 <= p3 and not l2
edge when l1
goto off ;
goto off ;
location off :
initial ;
edge when p2 > p4 and not l1
goto on ;
edge when l2
goto on ;
svgout id < string > name attr " fill " value if on : " green " else "
white " end ;
end
Sensor error implementation The sensor has two possible error states. It can remain turned
off when it should activate and it can activate when it should not. Because of the interactions
between the sensors and the controller, this behavior is modelled in a separate automaton. This
sensor error automaton has three states: the no error state, the error on state and the error
off state. The transitions between these states come from the uncontrollable events that can be
activated in the error console. This automaton is present for each of the sensors. The sensor
automaton follows the behavior of this sensor error automaton. The transitions in this automaton
are solely based on the uncontrollable events from the error generation console u 1 and u 2. The
SVG output lines change the opacity of the corresponding buttons to give information about the
status of the sensor error automaton during the interactive visualization.
automaton def sensorerror ( uncontrollable u_1 , u_2 ; alg string name ) :
location no_error :
initial ;
edge u_1
goto error_on ;
edge u_2
goto error_off ;
location error_on :
edge u_1
goto no_error ;
edge u_2
goto error_off ;
location error_off :
edge u_1
goto error_on ;
edge u_2
goto no_error ;
svgout id < string > name + " on " attr " opacity " value if
error_on :
" 1.0 "
else " 0.5 " end ;
svgout id < string > name + " off " attr " opacity " value if error_off : "
1.0 "
else " 0.5 " end ;
end
48
The sensor definitions and the sensor error definitions are instantiated for each individual sensor.
The l1 and l2 variables are the locations in the sensor error automata. The sensor error automata
get their input via the error console in the simulation.
ertop
: sensorerror ( u_errorupon , u_errorupoff , " up " ) ;
erbot
: sensorerror ( u_errordownon , u_errordownoff , " down " ) ;
erin
: sensorerror ( u_errorinon , u_errorinoff , " in " ) ;
erout
: sensorerror ( u_errorouton , u_erroroutoff , " out " ) ;
topsensor
: sensor ( vmotor .y , vmotor .y ,9.0 ,9.5 , " topsen " ,
ertop .
error_off , ertop . error_on ) ;
botsensor
: sensor (1.0 ,0.5 , vmotor .y , vmotor .y , " botsen " ,
erbot .
error_off , erbot . error_on ) ;
insensor
: sensor ( hmotor .x , hmotor .x ,9.0 ,9.5 , " insen " ,
erin .
error_off , erin . error_on ) ;
outsensor
: sensor (1.0 ,0.5 , hmotor .x , hmotor .x , " outsen " ,
erout .
error_off , erout . error_on ) ;
Motion disturbance implementation The motion disturbance is handled with motion error
automaton. This automaton creates a time based deviation in the speed of the PSS. After the
input from the error console, values are assigned that return to zero after a time period. These
values are then added to the speed variables of the PSS in the horizontal and vertical motor
automata. If the table is moving along the axis in which this disturbance is introduced it can
simulate a change in friction. If the table is not moving it can simulate bumping into the table.
The value of the x and y variables are added to the velocities of the horizontal and vertical axes
automata respectively. The time variable t ensures that the disturbance is temporary. This creates
a discrete change in the position variables in the axes automata. The transitions in this automaton
are based on the events generated in the error console and the value of the time variable.
automaton mov_er :
monitor ;
cont x =0.0 der 0.0;
cont y =0.0 der 0.0;
cont t =0.0 der 1.0;
location move :
edge when t >=0.0
location stop :
initial ;
edge u_kright when
move ;
edge u_kleft when
move ;
edge u_kup
when
move ;
edge u_kdown when
move ;
end
do y :=0.0 , x :=0.0
goto stop ;
hmotor .x <=9.0
do t := -2.0 , x :=0.5
goto
hmotor .x >=1.0
do t := -2.0 , x := -0.5
goto
vmotor .y <=9.0
do t := -2.0 , y :=0.5
goto
vmotor .y >=1.0
do t := -2.0 , y := -0.5
goto
The vertical brake failure is modelled as an additional location in the vertical axis automaton.
While in a resting position the table can be made to fall using the error console. It then accelerates
downwards until it either reaches the bottom, until the engine is engaged or until the error is
disabled again via the console.
location falling :
equation v = -0.1;
equation y =
if y <=0.0: 0.0
else
v
4.3. CONTROLLER WITH ERROR HANDLING
edge
edge
edge
edge
4.3
end ;
when controller . a_vmotor = -1
when controller . a_vmotor =1
when y <=0.0
u_falling
49
goto
goto
goto
goto
moving_down ;
moving_up ;
stop ;
stopping_down ;
Controller with error handling
The controller consists of several parts. It contains a system that is a able to estimate the position
of the PSS, a system that is able to diagnose when something is going wrong and what is going
wrong and it contains a part that overrides the basic controller so that the PSS is stopped until
the operator takes the appropriate action. In this chapter these parts are described as well as the
specific solutions to the errors described in the previous section and the implementations in CIF.
4.3.1
Real world model
In this part the real world restrictions and requirements of the error handling part of the controller
are described.
Position estimation In order to detect and diagnose the errors, it is helpful if the controller
knows the expected location of the PSS. In order to accomplish this, the controller should calculate
where the PSS is supposed to be, based on the state of the controller. The estimation can however
not be excepted to remain accurate as the simulation continues as the discrepancies add up. To
remedy this the virtual position is re-calibrated from the sensor information. Whenever a sensor
is deactivated the exact position is known and can be set as the estimated value. As long as the
discrepancies are small enough and the time between two sensor activations is short enough the
estimation will be accurate. Large discrepancies could be the result of an error and are handled
as such.
Error detection In order to help solve problems the controller needs to be able to detect them.
This detection is done via the error automaton. While in its initial position none no errors have
been detected and the controller behaves as the basic controller. When a specific combination
of sensor information, controller status and estimated position occurs the automaton transitions
to the appropriate error location. The transitions in the controller automaton are dependant on
the state of this error automaton and this results in the PSS stopping when an error is detected.
When an error is detected the diagnosis and the suggested actions are displayed to the operator.
In the visualization this is done via the text box.
Three specific errors are taken into account and can be diagnosed. These errors are a sensor
activating when it should not activate, the sensor not activating when it should and the hysteresis.
Each of these errors can occur for each of the four sensors and this leads to a total of 12 error
locations.
Hysteresis is unlike the sensor errors and the displacements an inherent sensor property. This
means that it cannot be prevented. As such the system should not be blocked entirely when it
is detected. The controller only needs to respond to the detected hysteresis when it would cause
problems.
50
4.3.2
Model of the controller with error handling
Position estimation The error detection makes use of an estimated position. This position is
based on the states of the controller and is tracked in real time. The controller as described in
Chapter 4.1.2 contains nine locations, five stationary and four moving. The controller automaton
has four variables, positions x and y and velocities vx and vy, to describe the positions and
velocities of the PSS. These are initialized at zero since that is considered the default starting
position during the simulations. Each location has several differential equations to calculate them
in real time.When the controller is in a moving location the estimated speed is increased until it
reaches its maximum velocity. In this way they mimic the second order dynamical behavior of the
real patient support system and generate an estimate for its position. The controller changes its
location based on user input via the tumble switch. This is modelled with the events u up, u down
and u stop. When errors are detected the controller also comes to a stop. When the edge of the
axis is reached the controller also brings the PSS to a stop. When controller location transitions
based on a sensor activation, the estimated position is set to the known sensor location.
automaton controller :
monitor ;
cont x = 0.0;
cont y = 0.0;
cont vx = 0.0;
cont vy = 0.0;
alg int a_hmotor = if controller . going_in
elif controller . going_out
else
end ;
alg int a_vmotor = if controller . going_up
elif controller . going_down
else
end ;
: 1
: -1
0
: 1
: -1
0
location going_up :
edge u_down
goto going_down ;
edge u_stop
goto stop_v ;
edge when error . toperror or error . toperror2 or error . hys_top or
error . sensor_h or error . sensor_v
goto stop_v ;
edge when ( error . boterror or error . boterror2 ) and topsensor . on do
y :=9.5
goto stop_v ;
edge when topsensor . on and y >=9.4 and error . none do y :=9.5
goto stop_top ;
equation x = 0.0;
equation y = vy ;
equation vx = 0.0;
equation vy =
if vy <1
:
1.0
else
0.0
end ;
The controller automaton has no stopping locations. Therefore the deceleration takes place when
the controller is in a stop location. There are five stop locations: stop bot, stop in, stop v, stop h
and stop top. The first two are the two outermost positions of the PSS. From these positions the
table can move in only one direction. The stop h and stop v locations indicate that the PSS is
stopped somewhere along the horizontal or vertical axis respectively but not on the edges. When
the controller is in the last location, stop top, the PSS is on the transit point between the two
axis. When the table has come to a complete stop the PSS can move either downwards or inwards
51
based on the tumble switch input. The differential equations in this location decelerate the PSS in
both directions whereas the other stop locations only decelerate in the direction of the axis they
are on. This is done by adjusting the speed variables, vx and vy, towards zero if they are outside
of a certain margin.
location stop_top :
edge u_down when vx >= -0.05 and vx <=0.05 and vy >= -0.05 and vy <=0.05
goto going_down ;
edge u_up when vx >= -0.05 and vx <=0.05 and vy >= -0.05 and vy <=0.05
and encoder . out and not hmotor . disengaged
goto going_in ;
equation x =
if vx >=0.05
: vx
elif vx <= -0.05
: vx
else
0.0
end ;
equation y =
if vy >=0.05
: vy
elif vy <= -0.05
: vy
else
0.0
end ;
equation vx =
if vx >0.05
:
-1.0
elif vx < -0.05 :
1.0
else
0.0
end ;
equation vy =
if vy >0.05
:
-1.0
elif vy < -0.05 :
1.0
else
0.0
end ;
This part of the error handling is integrated into the controller. This makes it easier to calculate
the estimations.
Error detection The errors are detected with the error detection automaton. The default location for this automaton is none. While the error automaton is in the none location, the controller
operates normally. When a specific set of Boolean requirements is met, the error automaton goes
from the none location to the appropriate error location. Since multiple errors can occur in with
multiple sensors, the set of these requirements is usually very similar. This condition is always
looks like:
edge when controller state and sensor state and position estimate goto error location
In some error states, some of these conditions can occur multiple times and some may not occur
at all. Because the error automaton handles all errors, only one error can be detected at any time.
This is done to allow the error automaton to reset when it reaches the other end of an axis, since
this could otherwise result in a new and redundant error.
automaton error :
location none :
initial ;
edge when controller . going_up and topsensor . on and controller .y
<9.0
goto toperror ;
edge when controller . going_down and botsensor . on and controller .y
>1.0
goto boterror ;
edge when controller . going_in and insensor . on and
controller .x
<9.0
goto inerror ;
edge when controller . going_out and outsensor . on and controller .x
>1.0
goto outerror ;
52

edge when controller . going_up and not topsensor . on and controller .
y >9.6
goto toperror2 ;
edge when controller . going_down and not botsensor . on and
controller .y <0.4
goto boterror2 ;
edge when controller . going_in and not insensor . on and controller .x
>9.6
goto inerror2 ;
edge when controller . going_out and not outsensor . on and controller
.x <0.4
goto outerror2 ;
edge when controller . going_up and botsensor . on and controller .y
>0.5
goto hys_bot ;
edge when controller . going_down and topsensor . on and controller .y
<9.5
goto hys_top ;
edge when controller . going_in and outsensor . on and controller .x
>0.5
goto hys_out ;
edge when controller . going_out and insensor . on and controller .x
>9.5
goto hys_in ;
edge when not controller . going_down and not controller . going_up
and botsensor . on and controller .y >1.0 and not topsensor . on
goto brake ;
edge when topsensor . on and botsensor . on
goto sensor_v ;
edge when insensor . on and outsensor . on
goto sensor_h ;
The error can in general be detected based on the sensor information.

When a sensor activates to soon, the sensor is activated while the estimated position is not yet
close enough to the known sensor location. This can only occur when the sensor is expected to
activate because the PSS is moving in the direction of the sensor. This is the case for the first
four errors.
When a sensor does not activate when it is expected to, the PSS must not continue moving while
the estimated position is past the known sensor location. This can also only occur when the PSS
is moving towards the sensor. This can be seen in the fourth till eigth error.
The PSS can be stopped in the hysteresis area of a sensor moving it away from the sensor and
stopping it before the sensor deactivates. In order to distinguish whether the PSS has moved past
the activation point or not, the estimated position is checked. This can be seen in errors nine till
twelve.
Finally the table might have a faulty break. When the table is not supposed to move along the
horizontal axis they brake is engaged and only then it can fail. If the bottom sensor is activated
while the estimated position is higher than the activation point this error is detected. If the top
sensor is however also active there must be a sensor error and the conclusion of a faulty break
can no longer be drawn. In the case of two opposite sensors activating, at least one of the sensor
activations must be false and the problem should be examined manually.
This part of the error handling is located in a separate automaton. By separating the error
detection from the normal control strategy, both parts can be easily adapted separately. It also
provides a clearer overview of the code.
Error resolution Once an error is detected the dangerous movements are disabled by the
controller. The error messages and suggestions must then be given to the operator. In the
visualization this is done via the dialog box. In this box two text strings are printed based on the
location of the error automaton.
53
value switch self :

case none
:
""
case toperror :
" topsensor active to early "
case boterror :
" botsensor active to early "
case inerror :
" outsensor active to early "
case outerror :
" insensor active to early "
case toperror2 : " topsensor not active when expected "
case boterror2 : " botsensor not active when expected "
case inerror2 :
" insensor not active when expected "
case outerror2 : " outsensor not active when expected "
case hys_bot :
" hysterese "
case hys_top :
" hysterese "
case hys_in :
" hysterese "
case hys_out :
" hysterese "
case brake
:
" the brake failed "
case sensor_v :
" One of the sensors is incorrectly activated "
case sensor_h :
" One of the sensors is incorrectly activated "
end ;
svgout id " suggestion " text
value switch self :
case none
:
""
case toperror :
" move the table down to recalibrate the
sensor "
case boterror :
" move the table up to recalibrate the sensor "
case inerror :
" move the table out to recalibrate the sensor
"
case outerror :
" move the table in to recalibrate the sensor "
case toperror2 : " move the table down to recalibrate the
internal position "
case boterror2 : " move the table up to recalibrate the
internal position "
case inerror2 :
" move the table out to recalibrate the
internal position "
case outerror2 : " move the table in to recalibrate the
internal position "
case hys_bot :
" move the table up until the sensor
deactivates "
case hys_top :
" move the table down until the sensor
deactivates "
case hys_in :
" move the table out until the sensor
deactivates "
case hys_out :
" move the table in until the sensor
deactivates "
case brake
:
" move the table upwards to resume operation "
case sensor_v :
" resolve the sensor failure before continuing
"
case sensor_h :
" resolve the sensor failure before continuing
"
end ;
The first string indicates the source of the error. The second string indicates the suggested action.
For the early and late activations the table is to be moved to the other outer position of the axis to
reset the estimated position. During hysteresis the PSS should be moved away from the sensor to
deactivate it. A possible engine reversal can be detected but not solved by the operator. Therefore
the hardware needs to be checked. If the brake failed the table can be moved upwards. If the
problem persists however, a mechanic should still look at the problem to resolve it.
location toperror :
54

edge when controller . stop_bot
goto none ;
location boterror :
edge when controller . stop_v and topsensor . on
goto none ;
location inerror :
edge when controller . stop_h and insensor . on
goto none ;
location outerror :
edge when controller . stop_in
goto none ;
location toperror2 :
edge when controller . stop_bot
goto none ;
location boterror2 :
edge when controller . stop_v and topsensor . on
goto none ;
location inerror2 :
edge when controller . stop_h and outsensor . on
goto none ;
location outerror2 :
edge when controller . stop_in
goto none ;
location hys_bot :
edge when botsensor . off
goto none ;
location hys_top :
edge when topsensor . off
goto none ;
location hys_out :
edge when outsensor . off
goto none ;
location hys_in :
edge when insensor . off
goto none ;
location brake :
edge when botsensor . off
goto none ;
location sensor_v :
edge when botsensor . off or topsensor . off
goto none ;
location sensor_h :
edge when insensor . off or outsensor . off
goto none ;
When the appropriate action is followed and the PSS responds as expected, the error automaton
can return to its default none position and the controller can resume its normal operation. If
the PSS needed to be moved to its outer position to reset the position estimation, the task is
completed when the other outer sensor activates. Hysteresis is resolved when the table is moved
far enough away for the sensor to deactivate.
The error resolution is mostly done by the operator. It is however partly integrated into the
normal control strategy because the controller needs to prevent dangerous movement when errors
are detected.
Use cases A number of use cases are made to display the operation of the controller and its
ability to deal with errors. In these use cases an error is created. The actions as suggested by the
4.4. CONCLUSION
55
controller are then taken and the PSS is able to resume its operation. Three use cases are created.
The use cases deal with early and late activation of sensors due to both sensor failure and motion
disturbance as well as hysteresis.
import " software . cif " ;
import " hardware . cif " ;
case1 : Case ( u_up , u_stop , u_down , u_table , u_clutch , u_topsen , u_errorouton
, u_erroroutoff , u_errorinon , u_errorinoff , u_errordownon , u_errordownoff ,
u_errorupon , u_errorupoff , u_kleft , u_kright , u_kup , u_kdown , u_falling , u_ttr ) ;
automaton def Case ( uncontrollable u_up , u_stop , u_down , u_table , u_clutch ,
u_topsen , u_errorouton , u_erroroutoff , u_errorinon , u_errorinoff ,
u_errordownon , u_errordownoff , u_errorupon , u_errorupoff , u_kleft , u_kright ,
u_kup , u_kdown , u_falling , u_ttr ) :
cont t = 1.0 der -1.0;
disc int n =0;
location :
initial ;
edge u_up when t
edge u_up when t
edge u_down when
edge u_stop when
edge u_up when t
<
<
t
t
<
0
0
<
<
0
and n
and n
0 and
0 and
and n
=
=
n
n
=
0
1
=
=
4
do t := 12.0 , n := n + 1;
do t := 1.0 , n := n + 1;
2 do t := 8.0 , n := n + 1;
3 do t := 0.1 , n := n + 1;
do t := 7.0 , n := n + 1;
edge u_up , u_stop , u_down , u_table , u_clutch , u_topsen , u_errorouton ,

u_erroroutoff , u_errorinon , u_errorinoff , u_errordownon , u_errordownoff ,
u_errorupon , u_errorupoff , u_kleft , u_kright , u_kup , u_kdown , u_falling ,
u_ttr
when false ;
end
During the use case the simulation is set to activate events without the interactive user input.
Therefore all events are given a guard to prevent their unintended activation. The desired events
and the intervals between these events is the specified. When the timer variable t reaches zero
the next event is activated. The counter variable n keeps track of which event is the next to be
activated.
4.4
Conclusion
The patient support system for an MRI scanner is modelled in CIF. The model takes into account
the second order dynamical nature of the system. A hybrid controller is used to deal with errors.
A visualization is used to verify the controller. Errors as a result of sensor failure, unexpected
displacement and hysteresis are taken into account. The controller can detect and diagnose these
errors with the use of the position estimation. The use of a hybrid controller seems to be a good
way of dealing with errors. The error handling is partially integrated into the basic controller to
stop the machine when errors are detected and to prevent dangerous movements. The controller
does not solve the issues but gives advice to the operator in the interest of comfortable patient
handeling. Several use-cases are created to demonstrate the implemented error handling.
The error handling part of the controller is largely separated from the normal control strategy. By
separating them, both the normal controller and the error detection can be adjusted more easily
on their own. The position estimation should however be integrated into the controller because
56
this makes it easier to calculate.
Chapter 5
Supervisory Control Theory

In this chapter, we focus on the theory that allows to synthesize correct and maximally permissive
supervisors for discrete-event systems. Sections 5.5 and 5.6 are partly based on [16].
5.1
Notions and concepts
Supervisory control theory (SCT) of [30] allows to synthesize a model of the supervisor from formal
models of the uncontrolled system and of the requirements. First, the uncontrolled system (plant
P ) is formally specified in terms of automata. These automata are, on the one hand, restricted to
discrete elements: states (locations), with the distinguished initial state, and transitions caused by
events. On the other hand, two types of events are distinguished: controllable and uncontrollable,
and a special type of states is introduced: marker states. Controllable events are the ones that
can be disabled by the supervisor, for instance a command to an actuator. Uncontrollable events
are the ones that cannot be prevented from happening, for instance a fault event or a change
of sensor readings. The marker states have a special meaning and play an important role in
supervisory control synthesis. The event sequences ending in a marker state can be interpreted as
the completion of some operations or tasks.
Example 5.1.1 (Manufacturing process revisited). Consider the simple manufacturing process
from Exercise 3.4.5. In Figure 5.1, the automata given previously are extended with the new
notions. The Idle states of the machines and the Empty state of the buffer are now defined as
marker states, filled circles in graphical representations. Events start M1, repair M1, start M2,
and repair M2 are now defined to be controllable solid arrow; while events breakdown M1,
end M1, breakdown M2, and end M2 are now defined to be uncontrollable dashed arrow. We
abbreviate the names of states by the first letter.

In the context of supervisory control theory, automata are used to model three types of elements:
plants, supervisors, and requirements (which are discussed later). In CIF, we distinguish these
three types by associated keywords replacing the keyword automaton. Events are declared either
controllable or uncontrollable and marking of states is defined. For instance, machine M1 as a
plant component with one marker state, two controllable and two uncontrollable events is given
by the following specification.
plant M1:
controllable start_M1, repair_M1;
57
58
CHAPTER 5. SUPERVISORY CONTROL THEORY

I
start M1
end M1
repair M1
breakdown M1
start M2
end M2
repair M2
breakdown M2
end M1
F
start M2
Figure 5.1: Automata with marker states, controllable and uncontrollable events.
uncontrollable end_M1, breakdown_M1;

location Idle:
initial; marked;
edge start_M1 goto Processing;
location Processing:
edge end_M1 goto Idle;
edge breakdown_M1 goto Down;
location Down:
edge repair_M1 goto Idle;
end
Exercise 5.1.1 (Manufacturing process continued). Make a CIF model of the plant components
from Example 5.1.1. Include the controller components derived in Exercise 3.4.5, now with the
keyword supervisor and define which states are marked. Perform (interactive) simulation experiments to observe the behavior of the supervised system.

Exercise 5.1.2 (Pump-valve-controller system revisited). Consider the pump-valve-controller system from Exercise 3.4.2. Redefine the given automata so that the automaton types, marker states,
controllable and uncontrollable events are determined. Make a CIF model of the plant components. Include the previously developed controller (supervisor) and define which states are marked.
Perform (interactive) simulation experiments to observe the behavior of the supervised system.
5.2
Basic supervisory control problem
As mentioned previously, a plant automaton (possibly derived from several component automata,
by means of an operation on automata called synchronous product) describes the physically possible behavior of the system to be controlled. This behavior can contain undesired states. In the
context of supervisory control theory, the undesired states are states from which it is not possible
5.2. BASIC SUPERVISORY CONTROL PROBLEM
59
to get to a marker state, called blocking states, and states from which an uncontrollable event
leads to a blocking state. The function of the supervisor is to prevent the system from getting
to undesired states by disabling certain controllable events and enabling other ones, based on the
events generated by the plant, as schematically shown in Figure 5.2.
supervisor S
events generated
by the plant
events enabled
by the supervisor
plant P
Figure 5.2: The feedback loop of supervisory control.

The basic supervisory control problem is formulated as follows. For plant P a supervisor S is
required such that:
1. P under control of S, denoted by S/P , is nonblocking.
2. S does not disable uncontrollable events.
3. Output of S only depends on observable outputs of P .
4. S is maximally permissive, that is, it only disables events to prevent the undesired states of
P.
Supervisory control theory provides means to synthesize supervisor S. To illustrate the basic
supervisor synthesis procedure, a simple example from [46] is worked out below.
Example 5.2.1 (Workcell with an AGV). A workcell consists of two machines M1 and M2 , and
an automated guided vehicle AGV . The AGV can load a workpiece at M1 or M2 and unload it
at M2 or at the infinite buffer B, respectively. This is schematically shown in Figure 5.3.
start M1
M1
M2
start M2
B
end M2
AGV
end M1
to B
Figure 5.3: Workcell.

In the sequel, we use italic event labels (e.g. to B ) and bold state labels (e.g. Busy). The models
of the two machines are simplified versions of the ones from Example 5.1.1. The AGV model has
three states: Empty, which is initial and marked, At M1 and At M2 . Events start M1 and
start M2 are controllable; events end M1 , end M2 , and to B are uncontrollable.
Components M1 , M2 , and AGV are modeled by automata shown in Figure 5.4. The behavior
of the uncontrolled system P is represented by the synchronous product (synchronized behavior)
of M1 , M2 and AGV drawn in Figure 5.5. States of the synchronous product consisting of local
component states that are all marked, are the marker states. In this example, every component
has only one marker state so the synchronous product has only one marker state, too.
60

start M1
M1 :
Idle
start M2
M2 :
Busy
end M1
Idle
AGV : end M1
Busy
end M2
end M2
At M1 start M Empty
2
to B
At M2
Figure 5.4: Workcell automata.

start M1
0
end M1
1
start M1
2
start M2
start M2
start M1
end M1
to B
start M1
to B
end M2
end M2
start M1
Figure 5.5: Uncontrolled system.
The labels of the states correspond to the following component state combinations.
0
M1
Idle
Busy
Idle
Busy
Idle
Busy
Idle
Busy
Idle
Busy
M2
Idle
Idle
Idle
Idle
Busy
Busy
Busy
Busy
Idle
Idle
AGV
Empty
Empty
At M1
At M1
Empty
Empty
At M1
At M1
At M2
At M2
We informally explain the conditions that must be satisfied by the supervisor for this uncontrolled
system. We assume that all events are observable. This implies that condition 3 is satisfied.
Hence, we can focus on the remaining conditions. In the basic supervisor synthesis approach, the
supervisor is derived from the uncontrolled plant behavior. As can be seen above, the absence of
control results in a blocking situation: from states 6 and 7 it is not possible to get to the marker
state. The supervisor we are constructing should influence the plant under control to avoid the
blocking situation. Only controllable events may be disabled. To avoid blocking, controllable
event start M1 must be disabled in state 4 and controllable event start M2 must be disabled
in state 3. This results in Figure 5.6a, where these supervisory control actions introduce a new
blocking situation: after removing the transitions labeled by start M1 and start M2 including the
subsequent states and transitions (because they become unreachable), from state 3 the marker
state cannot be reached anymore. This situation can be prevented by disabling controllable event
start M1 in state 2 resulting in Figure 5.6b. Finally, by construction this supervisor gives a proper
5.2. BASIC SUPERVISORY CONTROL PROBLEM
61
maximally permissive (only the undesired behavior is prevented) control to the plant: conditions
1 through 4 are satisfied.
start M1
0
end M1
1
start M1
2
start M1
3
end M1
1
start M2
start M2
to B
to B
to B
end M2
start M1
to B
(a) Step 1
end M2
start M1
(b) Step 2
Figure 5.6: Derivation of the supervisor.

Exercise 5.2.1 (Workcell with an AGV continued). Make a CIF model of the plant components
from Example 5.2.1. Perform the synthesis procedure by right clicking on the CIF file and then
choosing Event-based synthesis tools and Apply supervisor synthesis, see Figure 5.7. Compare
the synthesized supervisor with the one in Figure 5.6b. Apply trim check: (a) to the supervisor,
(b) to the synchronous product of the plant and the supervisor and inspect the results. Apply
controllability check to the plant models and the supervisor and inspect the results. Controllability
check relates to requirement 2 that the supervisor has to satisfy, the trim check to requirement 1.
Perform (interactive) simulation experiments to observe the behavior of the supervised system.
Figure 5.7: Screenshot of a CIF supervisor synthesis session.

Exercise 5.2.2 (Dining philosophers). Use the CIF tool to perform the synthesis procedure for
the plant components defined in Exercise 3.4.1. This tool requires that a dummy requirement
62
is defined: one initial and marker state, no transitions. Compare the synthesized supervisor with
the one you devised yourself. Apply controllability check to both supervisors and plants. Apply
trim check to every supervisor and to the synchronous products of each supervisor and the plant.
What are the results? Perform (interactive) simulation experiments to observe the behavior of the
supervised system.
5.3
General supervisory control problem
In the previous section, we explained how supervisory control can solve blocking situations in uncontrolled systems. Another important application domain for supervisory control is in achieving
the desired nonblocking system functionality based on the functionality of components. This is
where system requirements make their entrance. For instance, assume we have two independent
plant components, with disjoint event sets. Moreover, assume we have a specific idea about how
these components should work together, so that some system tasks are accomplished. Because the
event sets are disjoint, the uncontrolled combined behavior (synchronous product of associated
automata) does not contain any undesired states, assuming that the component behaviors are
nonblocking. When we try to restrict the uncontrolled system behavior so that this idea (which
is called requirement) is realized, we must watch for introducing undesired states.
This gives rise to the general supervisory control problem which is formulated as follows. For plant
P and requirement R, a supervisor S is required such that:
1. P under control of S, denoted by S/P , satisfies requirement R.
2. S/P is nonblocking.
3. S does not disable uncontrollable events.
4. Output of S only depends on observable outputs of P .
5. S is maximally permissive, that is, it only disables events to prevent the undesired states of
the synchronous product of P and R.
Also in this case, supervisory control theory provides means to synthesize supervisor S. To illustrate the general supervisor synthesis procedure, another simple example from [46] is worked out
below, similar to the simple manufacturing process from Example 5.1.1.
Example 5.3.1 (Manufacturing flow line). Two machines M1 and M2 function as described
previously. Their event sets are disjoint. This time, we do not take the buffer plant B into
account. We do define two requirements that we want to impose on these machines:
1. Every product processed by M1 is subsequently processed by M2 and there is no more than
one product waiting for M2 .
2. If both machines are down, M2 must be repaired before M1 is.
The task of the supervisor is to impose these requirements on the machines in such a way that no
undesired states (blocking or leading to blocking via an uncontrollable event) can be reached.
In Figure 5.8, these requirements are expressed as automata. When presenting requirements
graphically, the convention is used that events not mentioned on the edges are not influenced by
them.
The following CIF specification represents the plant models of the two machines and the requirements defined above.
5.3. GENERAL SUPERVISORY CONTROL PROBLEM
63
end M1
E
start M2
repair M1
breakdown M2
M2 notDown
M2 Down
repair M2
Figure 5.8: Requirements for the flow line.
controllable start_M1, repair_M1, start_M2, repair_M2;

uncontrollable end_M1, breakdown_M1, end_M2, breakdown_M2;
plant M1:
location Idle:
initial; marked;
location Down:
end
plant M2:
location Idle:
initial; marked;
location Down:
end
requirement R1:
location Empty:
initial; marked;
edge end_M1 goto Full;
edge start_M1, repair_M1, repair_M2, breakdown_M1, end_M2, breakdown_M2;
location Full:
64

edge start_M2 goto Empty;
edge start_M1, repair_M1, repair_M2, breakdown_M1, end_M2, breakdown_M2;
end
requirement R2:
location M2notDown:
initial; marked;
edge breakdown_M2 goto M2Down;
edge start_M1, end_M1, start_M2, end_M2, breakdown_M1, repair_M1;
location M2Down:
edge repair_M2 goto M2notDown;
edge start_M1, end_M1, start_M2, end_M2, breakdown_M1;
end
An application of the supervisor synthesis procedure delivers the following result.

controllable start_M1;
uncontrollable end_M1;
uncontrollable breakdown_M1;
controllable repair_M1;
controllable start_M2;
uncontrollable end_M2;
uncontrollable breakdown_M2;
controllable repair_M2;
supervisor sup:
alphabet start_M1, end_M1, breakdown_M1, repair_M1,
start_M2, end_M2, breakdown_M2, repair_M2;
location s1:
initial;
marked;
edge start_M1 goto s2;
location s2:
edge breakdown_M1 goto s3;
edge end_M1 goto s4;
location s3:
edge repair_M1 goto s1;
location s4:
location s5:
location s6:
location s7:
5.3. GENERAL SUPERVISORY CONTROL PROBLEM
65

location s8:
location s9:
location s10:
location s11:
location s12:
end

Exercise 5.3.1 (Manufacturing flow line continued). Perform the synthesis procedure for the plant
and requirement models from Example 5.3.1. Apply trim check to the supervisor and inspect the
results. Apply controllability check to the plant models and the supervisor. Apply trim check to
the synchronous product of the plant models and the supervisor. Perform (interactive) simulation
experiments to observe the behavior of the supervised system.

Supervisors can be synthesized according to the procedure sketched above. The resulting supervisor can be used to supervise an uncontrolled plant, which is schematically illustrated by Figure 5.2.
The supervisor can only react to observable events that are generated by the uncontrolled plant.
The supervisor influences the behavior of the plant by disabling certain controllable events. The
method guarantees that the system consisting of the derived supervisor and the uncontrolled plant
fulfills the requirements. If the supervised model does not contain the desired functionality, the
models of the uncontrolled plant or the requirements are inadequate.
In a similar way, a self-made supervisor can be verified by checking the conditions enumerated
below. Automaton S 0 is a proper supervisor for plant P if
Controllability check on P and S 0 lists only controllable events being disabled.
Trim check on the synchronous product of P and S 0 delivers ok.
Trim check on S 0 delivers ok.
Additionally, if S 0 /P produces the same marked sequences (ending in a marker state) as the
synthesized supervisor S then S 0 is also a proper and maximally permissive supervisor for plant
P . Hence, a plant can have several proper and maximally permissive supervisors.
Exercise 5.3.2 (Manufacturing flow line alternative supervisor). Manufacturing flow line from
Example 5.3.1 under control of a supervisor must satisfy the admissible behavior defined by requirements. Think of a simplified supervisor S 0 that does not contain the restrictions already
enforced by the plant behavior and in a proper way contains the restrictions imposed by the requirements. Check whether it satisfies the conditions that make it a proper supervisor. If yes,
figure out a way to investigate whether S 0 /P produces the same marked sequences (ending in a
marker state) as the synthesized supervisor S. If not, try another solution.
66
Exercise 5.3.3 (Workcell with a test unit). A workcell consists of two machines M1 and M2 ,
buffer B and test unit T U . Machine M1 receives workpieces from an input bin (controllable event
start M1 ). After processing, machine M1 sends a workpiece to buffer B (uncontrollable event
end M1 ). Two-place buffer B receives a workpiece either from M1 or from the test unit T U
(controllable event to B). From the buffer, workpieces are transferred to M2 (controllable event
start M2 ). After processing, machine M2 sends workpieces to the test unit T U (uncontrollable
event end M2 ). From the test unit, workpieces are transferred either to the buffer (controllable
event to B) or to an output conveyor (uncontrollable event to C). The corresponding automata
are shown in Figure 5.9.
M1 :
M2 :
start M1
start M2
Busy
Idle
Busy
Idle
end M1
end M2
B:
TU :
0
to B
to B
end M1
end M1
end M2
2
Idle
start M2
start M2
Busy
to B
to C
Figure 5.9: Workcell plant automata.

The behavior of the system needs to be restricted to satisfy the following requirements:
M1 can only begin processing if the buffer is not full.
M2 can only begin processing if the buffer is not empty.
M1 and M2 cannot be busy processing at the same time.
M1 and T U cannot be busy processing and testing at the same time.
Construct automata that model the above requirements. Synthesize the proper maximally permissive supervisor, so that the controlled workcell behavior satisfies the above requirements. Perform
simulation experiments to check whether the requirement automata are properly constructed.
Exercise 5.3.4 (Pump-valve-controller system continued). Consider the pump-valve plant components from Exercise 5.1.2 and the requirement stated in Exercise 3.4.2 (it must be prevented
that the pump is operating while the valve is closed). Define the requirement automaton, apply
the supervisor synthesis procedure and analyse the result. Do the resulting supervisor and the
behavior of the supervised system correspond to your expectations? If not, improve the (plant or
requirement) models used for synthesis and repeat the above design steps.
5.4
Modular supervision
In previous sections, we showed how to synthesize one supervisor for an uncontrolled systems. Such
a supervisor is called monolithic or centralized. Sometimes, especially for more complex systems,
it is more convenient to divide the supervisory task into several subtasks. This seems logical in
situations where several requirements are defined. For each of the requirements, the synthesis
procedure can be applied resulting in several supervisor automata (also called local supervisors)
which together, under the circumstances explained below, implement a solution to the original
5.4. MODULAR SUPERVISION
67
S(s)
P
(a) Monolithic
(b) Modular
Figure 5.10: Monolithic versus modular supervisor.
problem. Figure 5.10 schematically shows the differences between the two approaches. In case of
modular supervision, an event is enabled only if it is enabled by S1 and S2 .
Modular supervision has several advantages:
Allocation of control tasks to local supervisors reduces complexity.

The supervisor is no longer monolithic (one large automaton) but may consist of several
components (possibly smaller automata).
Synthesis of supervisory components is easier.
Modular supervisor is easier to modify, update and maintain.
For instance, if only one control subtask (requirement) is modified only the corresponding
local supervisor needs to be redesigned.
However, nonblocking at the global level must be ensured. We illustrate this point by the dining
philosophers example (see Exercise 3.4.1).
Example 5.4.1 (Dining philosophers modular). We model the philosophers by the following
automata:
68

P h1 :
P h2 :
P 1 f1
P 2 f1
P 1 f2
P1 f
P 2 f2
P 1 f2
P 2 f2
P2 f
P 2 f1
P 1 f1
The forks which are now treated as requirements (not as plants) are modelled as follows. Note
that P 1 f 1, P 2 f 1 related to an edge means that there are two transitions: one labeled by P 1 f 1
and one labeled by P 2 f 1.
F2 :
F1 :
P 1 f 1, P 2 f 1
P 1 f 2, P 2 f 2
P 1 f, P 2 f
P 1 f, P 2 f
For the purpose of modular supervision, we employ F1 and F2 as local supervisors. It can be
checked that, for i = 1, 2, Fi is controllable with respect to the synchronous product of P h1 and
P h2 , and the synchronous product of Fi , P h1 and P h2 is nonblocking. Hence, both are proper
supervisors. However, it is easy to see that when both are put into operation, the system can
arrive in a blocking situation: for instance, after P h1 performs P 1 f 1 and P h2 performs P 2 f 2,
no events are possible.

The general modular design procedure is defined for plant P and two requirements R1 and R2 by
the following steps:
1. Synthesize the proper maximally permissive supervisor S1 for P and R1 .
2. Synthesize the proper maximally permissive supervisor S2 for P and R2 .
3. Check that the synchronous product of S1 , S2 and P is trim.
4. Check that the synchronous product of S1 and S2 is trim.
As opposed to the monolithic design procedure, the existence of a modular supervisor is not always
guaranteed.
If the trim checks mentioned above in steps 3 and 4 are positive, {S1 , S2 } is a modular
proper, but not necessarily maximally permissive, supervisor of P with respect to R1 and
R2 .
If not, we do not have the modular solution to the problem (but a coordinator can be
computed to resolve the conflicts).
Alternatively, we can use manually designed supervisors S1 and S2 , or even the requirements
themselves, as local supervisors. In this case, we need to investigate whether S1 (R1 ) and S2 (R2 )
themselves are proper maximally permissive supervisors for the plant. If so, the nonblocking checks
mentioned in steps 3 and 4 can be performed. Additionally, the demand that local supervisors are
maximally permissive can be dropped.
5.5. SPECIFICATION OF REQUIREMENTS
69
Exercise 5.4.1 (Dining philosophers revisited). Apply the monolithic design procedure to the
dining philosophers problem treated above in which fork models are treated as plants. Because
the CIF tool expects at least one requirement, again a dummy requirement needs to be defined.
What is the result?

Exercise 5.4.2 (Dining philosophers continued). We introduce two requirements as shown below.
R2 :
R1 :
P1 f
P 2 f1
P1 f
P 2 f2
P 1 f1
P2 f
P 1 f2
P2 f
Apply the modular design procedure to the dining philosophers problem with these two requirements. What is the result? Do the two synthesized local supervisors together form a proper
supervisor for this problem?

Exercise 5.4.3 (Manufacturing flow line modular). Apply the modular synthesis procedure for
the plant and requirement models from Example 5.3.1. What is the result? Do the two synthesized
local supervisors together form a proper supervisor for this problem?

Exercise 5.4.4 (Manufacturing flow line modular revisited). Use the two requirement models
from Example 5.3.1 as possible local supervisors. To this end, check whether they are proper
supervisors for the flowline. What is the result? Are R1 and R2 proper supervisors for the
flowline? If not, investigate why, propose modifications and repeat previous steps. If yes, check
the nonblockingness conditions from the modular design procedure. Do R1 and R2 together form
a proper supervisor for this problem?
5.5
Specification of requirements
When designing a system, the first step is to define what it should do. This is done by means
of requirements. The importance of this first step has been recognized and confirmed in many
projects over the last three decades. In the meantime, it has become a common knowledge that,
as mentioned for instance in [36], most system design errors and cost overruns are caused by
incomplete, unclear, or incorrect requirements. As a consequence, many recommend to use a
precise, formal, and unambiguous method for specifying requirements.
The properties a system should satisfy can be divided in two classes. The first class contains the,
so-called, safety properties. They are usually defined by indicating that the system should never
be in certain undesired states. For instance, in a railway crossing system controlling a gate at the
intersection of a railway and a road, an important safety property is that the gate should never
be open when a train is in the intersection area. Another example is the safety property in the
pump-valve system requiring that the pump is not operating when the valve is closed. In many
cases, there is also an (implicit) overall safety property stating that the system should never block.
There is, however, a (too) simple solution guaranteeing safe behavior. Namely, a system that
satisfies safety properties in its initial state and further does not do anything useful would be such
a solution. For instance, we could keep the gate closed permanently in the railway crossing system
mentioned above. In the pump-valve system, we would only allow the uncontrollable events in the
initial state. To ensure that systems also exhibit useful behavior, liveness or progress properties
should be satisfied as well. In the case of the railway crossing system, a progress property would
be that the gate should be open if there are no train in the intersection area. In the case of
the pump-valve system, we would like to see the valve open and the pump operating. Also here,
70
there can be an (implicit) overall liveness property stating that the system should be maximally
permissive.
In the event-based supervisory control framework, automata are used to describe plant models and
requirement models. In this chapter, we already saw several examples of requirement automata,
most of them specifying safety properties. However, sometimes it is easier or more intuitive to
express requirements by state-based expressions instead of automata. By means of automata, we
can only enumerate all possible behaviors (sequences of events), while state-based expressions can
describe them more concisely. Moreover, when we look at the case studies, we observe that system
requirements are often expressed in terms of conditions over states. Design engineers can express
requirements more easily by using state-based specifications because they naturally follow from
informal, intuitive requirements. This possibility is provided in the state-based framework, where
both state-based expressions and automata are available to specify the desired behaviour. In this
section, we use (a part of) the syntax described in [26] for defining state-based expressions.
Exercise 5.5.1 (Dining philosophers with fairness). The solutions to the dining philosophers
problem discussed previously all suffer from the, so-called, individual starvation: it is possible
that one of the philosophers never will be able to eat. Propose an extended model for the dining
philosophers problem (modified plant components), so that in this new setting it is possible to
define as a requirement that every philosopher regularly gets a possibility to eat if he wants to. Is
it a safety property or a progress property? Define the requirements, synthesize a supervisor and
investigate whether the supervised system indeed exhibits the desired behavior.
Exercise 5.5.2 (Traffic system revisited). Consider the traffic system from Exercise 3.4.6. Make
the system recurrent and make models of all elements: road sections, traffic lights, and vehicle
detectors. Define marker states, controllable and uncontrollable events. Define requirements to
guarantee that: (i) the two vehicles must reach the destination, and (ii) only one vehicle can be in
a road section at any given time (in order to avoid collisions). Should vehicle behavior be modeled
as a plant or as a requirement? Synthesize the supervisor and analyse the supervised traffic system
behavior.
As mentioned above, requirements can be defined as automata or as state-based expressions. Consider for instance, the requirement related to the pump-valve system (Exercise 5.3.4): prevent that
the pump is operating while the valve is closed. For convenience, we rephrased this requirement
as follows: event start pump is only enabled in the states in which the valve is not closed, i.e. VO
and SO. This rephrased formulation suggests that the valve model can be used as basis because
there we can refer to the valve states. Now to enable event start pump in VO and SO, we add
to looped transitions labeled by this event. The resulting automaton representation is as follows.
5.5. SPECIFICATION OF REQUIREMENTS
71
close valve
stuck closed
VC
SC
open valve
stuck open
stuck closed
close valve
stuck open
SO
start pump
VO
open valve,start pump
The same can be expressed by the following state-based expression:

{ start pump } (Valve.VO Valve.SO )
Consider the workcell with a test unit (Exercise 5.3.3) as another example. We focus on the
requirement saying that M1 and T U cannot be busy processing and testing at the same time.
Because this requirement refers to the states of two components, M1 and T U , it is convenient to
take their synchronous product as basis. The requirement defines one combination of local component states as undesired, namely (M1 .Busy, TU.Busy). Hence, the requirement automaton
shown below is achieved by removing this state from the synchronous product automaton. Note
that state I in this automaton corresponds to (M1 .Idle,TU.Idle)
end M2
end M1
to B
(M1 .Busy,TU.Idle)
(M1 .Idle,TU.Busy)
start M1
to C
This requirement can easily be written down as the following state-based expression:
(M1 .Busy TU.Busy )
In the state-based expressions, the following elements are used. Elements 1 and 0 stand for truth
values of propositional logic. Negation , conjunction , disjunction and implication are
standard logical operators. In this kind of expressions, also state predicates C.S and event
predicates E can be used. The state predicate C.S expresses that component C is in state S.
The event predicate E expresses that an event from set E is enabled by the supervisor. The
logical expressions used in the lecture notes are of the form:
ST ::= M S | E M S
where M S ::= 1 | C.S | M S | M S op M S and op {, , }.
Exercise 5.5.3 (Multimover). Consider the multimover from Chapter 6. Make CIF descriptions of
the plant components belonging to the subsystem called motor actuation. Analyze the associated
72
requirements and translate the state-based formulations into automata. Synthesize the supervisor
and analyse the supervised behavior of this subsystem.
5.6
Overview of advanced synthesis techniques
As computational complexity is high for systems of industrial size, several advanced techniques
have been introduced to reduce synthesis complexity, such as modular ([10]), hierarchical ([45]),
interface-based hierarchical ([21]), aggregative ([14, 25]), distributed ([37, 19, 8]), coordinated distributed ([38]) and aggregated distributed ([39]) synthesis. They allow for splitting a system in a
number of modules for which local supervisors can be synthesized. If needed, also a coordinator
can be synthesized on top of them. The local supervisors together with the coordinator compose a
nonblocking supervisor for the total system. However, this supervisor is not necessarily maximally
permissive. A different approach is the state-based supervisory control framework of [23]. In this
framework, discrete-event systems are represented by state tree structures (STS), a representation
that allows for computationally efficient monolithic supervisor synthesis. Unlike the event-based
framework, the state-based framework allows to formulate requirements as conditions over states.
In [2], a first step is reported in the direction of defining supervisor synthesis techniques for a
process-theoretic setting. Additionally, [40] describes how to compute a nonblocking supervisor
that not only complies with the prescribed requirements but also achieves a time optimal performance such as throughput.
In general, there are two basic control strategies: state-based feedback control and event-based
feedback control. In the former strategy, the supervisor observes only state information, and
in the latter one only sequences of observable events are available to the supervisor. Based on
observations the supervisor issues appropriate control commands accordingly, which determine the
set of events that are allowed to be fired before new observations are obtained. Which strategy
should be used completely depends on what can be observed in the system, i.e., states or events.
When the system is not complex, a centralized approach can be used to synthesize a centralized
supervisor, see e.g. [31]. Unfortunately, centralized approaches cannot overcome the state-space
explosion phenomenon. To deal with this computational complexity issue, several advanced synthesis techniques have been introduced recently. For example, in [23] a new state-based synthesis
approach is proposed, which utilizes state-tree structures plus binary decision diagrams to encode
states so that reachability search can be done efficiently. The approach can handle fairly large
systems even though it is centralized. In [21] an interface-based hierarchical synthesis approach
is presented, which fully exploits the benefit of interface invariance in system decoupling so that
synthesis is carried out only in local components. One potential drawback of this approach is that
the conditions for interface invariance may be too strong for many practical applications. In [14]
and [25] compositional synthesis approaches are provided which aggregate component models one
after another hoping that bad behaviors can be dropped out during the process of aggregation,
instead of being kept to the last stage which usually results in extremely high complexity. Notable
attentions should also be paid to some recent distributed synthesis approaches presented in e.g.,
[37], [13], [19], [39] and [38], which utilize (language-based or automaton-based) model abstraction techniques when dealing with local synthesis. These distributed approaches are of particular
interest for several reasons: (1) most (if not all) complex systems are naturally constructed in a
modular way; (2) by deliberately masking out certain internal behaviors the plant model G can
be significantly simplified for synthesis; (3) synthesized local controllers may be reused when G
undergoes a structural change, which only affects part of it.
Chapter 6
Applications of Supervisory
Control Theory
This chapter is based on [16].
6.1
Theme Park Vehicles
In this chapter, a real industrial product is presented as a case study: a flexible vehicle that can be
used in theme parks or museums, called the multimover. The multimover, as shown in Figure 6.1a,
is a battery-operated Automated Guided Vehicle that follows an electrical wire integrated in the
floor. This track wire produces a magnetic field that can be measured by track sensors. Next to
the track wire, floor codes are positioned, that can be read by means of a metal detector. These
floor codes give additional information about the track, e.g., the start of a certain scene program,
a switch, junction or a dead-end. The scene program, which is read by the scene program handler,
defines when the vehicle should ride at what speed, when it should stop, rotate, play music and
in which direction the vehicle should move (e.g., at a junction).
User Interface
(3 LEDs/3 buttons) (on/off)
Scene Program Handler

(on/off)
Steer Motor
Drive Motor
(on/off)
(on/off/stopped)
Bumper switch
Battery
Buttons
Ride Control
(start/stop)
Motors
Bumper Switch
Battery
(on/off)
(empty/OK)
4 Proximity Sensors
(on/off)
(a) The Multimover
Proximity sensors
Ride Control
LEDs
(b) Component interactions
Figure 6.1: Theme park vehicle

An operator is responsible for powering up the vehicle and deploying it into the ride manually. The
operator also controls the dispatching of the vehicles in the passenger boarding and outboarding
73
74
CHAPTER 6. APPLICATIONS OF SUPERVISORY CONTROL THEORY
area. The vehicle can receive messages from Ride Control. Ride Control coordinates all vehicles
and sends start/stop commands to these vehicles. These messages are sent with wireless signals or
by means of the track wire. Multimovers are not able to communicate with other vehicles. Safety
is an important aspect of this vehicle. Therefore, several sensors are integrated in this vehicle to
avoid collisions. First, proximity sensors are integrated in the vehicle to avoid physical contact
with other objects. We can distinguish two types of proximity sensors. A long-range proximity
sensor that senses obstacles in the vicinity of six meters and a short-range proximity sensor that
senses obstacles in the vicinity of one meter. Second, a bumper switch is mounted on the vehicle
that can detect physical contact with other objects. The interactions between vehicle components
are shown schematically in Figure 6.1b.
The main requirement for supervisory control synthesis is safety. Three safety-related aspects can
be distinguished:
Proximity handling The supervisor has to assure that the multimover does not collide
with other vehicles or obstacles. To this end, proximity sensors are integrated at the front
and back which can detect an obstacle in the vicinity of the multimover. To avoid collisions,
the multimover should drive at a safe speed and stop if the obstacle is too close to it.
Emergency handling The system should stop immediately and should be powered off when
a collision occurs. To detect collisions, a bumper switch is mounted on the multimover. The
same applies when the battery level is too low. The LED interface should give a signal when
an emergency stop has been performed. The multimover should be deployed back into the
ride by an operator manually.
Error handling When a system failure occurs (e.g., a malfunction of a motor), the system
should stop immediately and should be powered off to prevent any further wrong behaviour.
The LED interface should give a signal that an emergency stop has been performed. The
multimover should be deployed back into the ride by an operator manually.
A divide-and-conquer strategy is often applied to get a good overview of control problems. This
means that a large control problem can be divided into smaller control subproblems which can be
solved more easily. We can divide the control problem of the multimover into five subproblems:
LED actuation (I) An operator must be able to check in which state the multimover is by
looking at the Interface LEDs. This means that the states of the LEDs represent the current
state of the multimover. It is a task of the supervisor to actuate the LEDs according to the
state of the multimover.
Motor actuation (II) The drive motor, steer motor and scene program handler have to
be switched on and off according to the state of the multimover. If the multimover is in the
state Active, all motors can be switched on. If the multimover is in the state Reset or
Emergency, all motors have to be switched off.
Button handling (III) The user interface of the multimover contains three buttons that
may only be used by the operator. The reset button is used to reset the vehicle if the
multimover is active and deployed into the ride or it is in the state Emergency. The
forward and the backward buttons are used to deploy the vehicle into the corresponding
direction. The supervisor has to assure that the corresponding state is reached after a
button is pushed.
Emergency and error handling (IV) In order to guarantee safety of passengers, the
multimover should be deactivated immediately when an emergency situation occurs. It
should not be possible to reset the multimover if the bumper switch is still activated or
battery power is still too low. A control task of the supervisor is to enter the Emergency
state of the multimover when an emergency situation occurs.
6.1. THEME PARK VEHICLES
75
Proximity and Ride Control handling (V) On each side of the multimover, two proximity sensors are mounted: one long-range and one short-range. If a long-range proximity
sensor detects an object in the traveling direction, the multimover should react by slowing
down to a safe driving speed. If an obstacle is detected by a short-range proximity sensor,
the multimover should stop in order to prevent a collision. When the short-range proximity sensor no longer detects an object, the vehicle should start riding automatically. If the
multimover receives a stop command from Ride Control, it should stop as in the case of
short-range proximity handling. If Ride Control sends a start command, the multimover
should automatically start riding with the speed depending on the state of the proximity
sensors related to the current driving direction.
Based on system functionality and the amount of interaction between components, components
that have a lot of interaction with each other and are strongly coupled in the control problem belong
to the same control subproblem. Fig. 6.2 shows a graphical representation of the partitioning of
the multimover control problem. This forms the basis for distributed synthesis.
IV
Battery
II
I
Bumper
LEDs
Internal State
Scene Program
III
Motors
Buttons
Proximity Sensors
Ride Control
Figure 6.2: Partitioning of the control problem
6.1.1
Plant and requirement models
In our case study, the plant model represents an event-based abstraction of the actual behaviour
of the physical components and their resource control, which is schematically shown in Figure 6.3.
The arrows represent the information flow between the components, the resource controllers and
the supervisor.
Supervisor
Supervisory controller
LED RC
Button RC
Motor RC
LED
Button
Motor
Plant
Figure 6.3: The control architecture

As usual in the context of supervisory control, plant models are defined by automata. Each
component together with its resource controller is modelled by one automaton. Automata consist
76
of states and transitions labeled by (controllable and uncontrollable) events. States of the plant
model represent all relevant states of each resource (e.g. on, off, empty, active). Controllable events
represent relevant discrete commands (function calls) to the resource control (e.g. enable, disable).
These actions can be enabled or disabled by the supervisor. Uncontrollable events represent
messages that are sent from the resource control to the supervisor (e.g. a failure notification, a
sensor event). These events cannot be disabled by the supervisor.
The plant model is made with the assumption that the resource control of the multimover is
working correctly. This assumption is reasonable because the resource controllers are embedded
in the existing implementation and have thoroughly been tested. This means that if a command
is given, it is carried out correctly. Furthermore, the communication between the plant and the
supervisor is sufficiently fast. If an event occurs at the plant (e.g., a button is pressed), the
supervisor is synchronized immediately. In Section 5, we argue that this is also the case in our
prototype implementation because the response time of the multimover controller is short enough
to properly react to the changes in its environment.
In the graphical automaton representation, initial states are denoted by an unconnected incoming
arrow and marker states are denoted by filled vertices. Controllable and uncontrollable events are
denoted by solid and dashed edges, respectively. The component models have disjoint alphabets.
x press
X Released
x release
X Pressed
Figure 6.4: Button automaton

The user interface of the multimover contains three buttons (the reset, the forward and the backward button) that are used to reset the vehicle and to deploy the vehicle into the ride and three
LEDs (the reset, the forward and the backward LED) that are used to show its actual state. In
Figure 6.4, the automaton representing the buttons is depicted. It has two uncontrollable events:
the event that represents the button being pressed (x press) and the event that represents the
button being released (x release). For the reset button, X (x) should be replaced by RB (rb),
for the forward button by FB (f b) and for the backward button by BB (bb). In Figure 6.5, the
automaton representing the forward and backward LEDs is depicted. The controllable events
x on and x off represent the function call to switch the LED on and off, respectively. As for the
buttons, for the forward LED, X (x) should be replaced by FL (f l) and for the backward LED by
BL (bl). As shown in Figure 6.6, in the model of the reset LED, the initial and marker states are
different.
x on
X Off
x off
X On
Figure 6.5: LED automaton

rl on
RL Off
rl off
RL On
Figure 6.6: Reset LED automaton
77
All sensors are modelled by automata having the same structure, as depicted in Figure 6.7 for a
sensor. The sensor can generate two events: x active and x inactive. As explained in Section 3,
the multimover is equipped with two long-range proximity sensors, FLP and BLP, two short-range
proximity sensors, FSP and BSP, and the bumper switch, BS, a sensor mounted on the bumper
that can detect physical contact with an object. Again, for individual sensor models, X and x
should be substituted by the respective sensor names.
X Inactive
x active
X Active
x inactive
Figure 6.7: Sensor automaton
A different kind of sensor measures the battery level. If the battery level is below a certain limit,
an uncontrollable event ba empty is sent. If the vehicle is charged, ba ok is sent. The automaton
representing this functionality is depicted in Figure 6.8.
ba empty
BA OK
ba ok
BA Empty
Figure 6.8: Automaton of the battery sensor
Ride Control can send a general start/stop command to start or stop all the multimovers in an
attraction. Ride Control sends these commands constantly with a certain interval. Therefore, it
is possible that the same command is sent over and over again. This behaviour is captured by
the automaton depicted in Figure 6.9. Note that the events mentioned above are uncontrollable,
since the supervisor cannot disable them.
stop
Start
Stop
stop
start
start
Figure 6.9: Automaton of Ride Control
The Scene Program Handler shown in Figure 6.10, reads the scene programs provided by the
customer and sends certain commands to the rotation device, drive motor, steer motor and audio
player. Since only starting (sh enable) and stopping (sh disable) the reading of the scene program is
relevant for our supervisor, only these events are modelled. Because a scene program could contain
a command that the multimover should start driving in the opposite direction, the uncontrollable
event sh chdir is modelled. If the scene program file contains a parse error, the multimover should
stop moving and enter the emergency mode. If a parse error is read, the uncontrollable event
sh error occurs.
In Figure 6.11a, the automaton of the steer motor is given. The relevant states of the steer motor
are SM On and SM Off. The actuation signals that are important for the supervisory controller
are switching on the steer motor (sm enable) and switching off (sm disable). This motor contains
a hardware safety in case the motor is short-circuited or has a hardware failure. If this hardware
safety is activated (sm error ), the motor is automatically switched off. Since the hardware safety
78

sh error
sh chdir
sh enable
SH Off
sh disable
SH On
Figure 6.10: Automaton of the Scene Program Handler
can also be activated when the motor is switched off and still slowing down, the event error is
looped at state SM Off.
In Figure 6.11b, the automaton of the drive motor is given. It is basically the same as the
automaton of the steer motor. However, it contains an extra state DM Stopping, since for
safety reasons the drive motor may not be switched off if the multimover is still moving (e.g.,
stopping). Therefore, an extra event dm stop is introduced that stops the drive motor. If the drive
motor has stopped, the uncontrollable event dm disable occurs and the drive motor is switched
off. Because we want to be able to set the maximum speed of the drive motor, the events dm fw,
dm fwslow, dm fwstop, dm bw, dm bwslow and dm bwstop are introduced. The drive motor also
contains a hardware safety in case the motor is short-circuited or has a hardware failure. When
such a situation occurs, the motor is automatically switched off, which is modelled by the event
dm error.
sm error
sm enable
SM On
SM Off
sm error
sm disable
(a) Automaton of the steer motor
dm enable fw
dm enable bw
DM Off
DM On
dm error
dm error
dm disable
dm
dm
dm
dm
dm
dm
fw
fwslow
fwstop
bw
bwslow
bwstop
dm stop
dm enable fw
dm enable bw
dm stop
DM Stopping
(b) Automaton of the drive motor
Figure 6.11: Automata of motors
The multimover itself can also be in three states, namely MM Emergency, MM Reset and
MM Active, see Figure 6.12. MM Emergency denotes the state of the multimover in which
all components are switched off and the multimover has to be reset manually by pushing the reset
button. If the reset button is pushed, the multimover should enter the state MM Reset. From
this state, the multimover can be deployed into the ride (MM Active) or can switch back to
MM Emergency (if an emergency event occurs). Since a lot of control requirements are based
79
on the state of the multimover, this automaton is introduced for modelling convenience.
MM Emergency
mm reset
MM Reset
mm emergency
mm emergency mm reset
mm active
MM Active
Figure 6.12: Model of the multimover

Marker states are used to describe completed tasks. As stated in [24], they represent states that
we always want to be reachable by any behaviour. Since in the model, the MM Reset state is a
marker state, the synthesized supervisor always assures that the multimover can be reset.
Behaviour of plant components can be modelled in different ways. For instance, component models
can represent an already restricted behaviour (partially controlled), or all the physically possible
behaviour (uncontrolled), with no restrictions. We have chosen for component models representing
the uncontrolled behaviour. As shown in Figure 6.3 and explained above, the models of plant
components used for supervisory control problem definition describe the component behaviour
in terms of discrete commands (turning on and off, setting the speed level and direction) to
and messages (failure notification, sensor values) from the resource controllers. This means that
an abstraction is made from physical variables like velocity and displacement. With respect to
velocity, only the distinction is made between two predefined speed values, namely normal and
slow. With respect to displacement, only the direction (backwards and forwards) and rotation are
taken into account. In this way, the plant models are obtained that match exactly the behaviour
of the interface of the components defined at the resource-control level. Decomposing the system
in an uncontrolled plant and a supervisor gives a clear view of the system functionality. Supervisor
synthesis is slightly more difficult with these unrestricted plant automata, since more behaviour
has to be restricted by means of requirement models.
All requirements described above are formally specified.
Emergency and error handling

The automata depicted in Figure 6.13 specify the control requirements of the emergency and error
handling control module. Figure 6.13a and 6.13b specify that the events mm active and mm reset
are only allowed to take place if the bumper switch is not activated and the power level of the
battery is sufficient. This requirement can be defined by taking the plant automata of the bumper
switch and the battery and adding loops with events mm active and mm reset at the states that
represent the bumper switch not being activated and the power level of the battery being sufficient.
The last requirement, which is depicted in Figure 6.13c, specifies when the event mm emergency
is allowed to occur. It is only allowed to occur after activation of the bumper switch (bs press),
the power level of the battery becoming too low (ba empty), a parse error of the scene program
(sh error ), a failure of the drive motor (dm error ) or a failure of the steering motor (sm error ). If
one (or a sequence) of these emergency events takes place, the requirement allows the occurrence
of the event mm emergency, all other events are allowed to take place in any order without
restrictions.
80

bs press
bs release
mm reset
mm active
(a)
ba empty
ba ok
mm reset
mm active
(b)
sm error
dm error
sh error
ba empty
bs press
sm error
dm error
sh error
ba empty
bs press
mm reset
mm emergency
mm reset
(c)
Figure 6.13: Requirement models of the emergency module
The original event-based framework uses automata to describe plant models and requirement
models. Sometimes it is easier or more intuitive to express requirements by state-based expressions
instead of automata. Automata can only enumerate all possible behaviours, while state-based
expressions can describe them more concisely. Moreover, system requirements are often expressed
in terms of conditions over states. This possibility is provided in the state-based framework,
where both state-based expressions and automata are available to specify the desired behaviour.
However, as indicated in [26], deriving the suitable state-based expressions can be an error-prone
and tedious task. To avoid this inconvenience, logical specifications are proposed for automatic
generation of these state-based expressions. Design engineers can express requirements by logical
specifications that naturally follow from informal, intuitive requirements.
The requirements that are depicted in Figure 6.13a and 6.13b can also be specified by a logical
expression stating that if the events mm reset and mm active are enabled by the supervisor then
the bumper switch is released (BS Released) and the power level of the battery is sufficient
(BA OK). Using the syntax introduced in [26], this logical expression reads: { mm reset,
mm active } BS Released BA OK .
To explain the syntax for the logical expressions of [26], we take unique state names as a starting
point. In the expressions, 1 and 0 as truth values of propositional logic, negation , conjunction
, disjunction and implication as standard logical operators, state predicates s and event
predicates E can be used. The state predicate s expresses that a component is in state s.
The event predicate E expresses that an event from set E is enabled by the supervisor. The
logical expressions used in this paper are of the form:
ST ::= E M S
81
where M S ::= 1 | s | M S | M S op M S and op {, , }.

Logical expression defined above can be used instead of automata. However, not every requirement
can be specified as such a logical expression, which is illustrated in the Appendix. As described in
the next section, the same collection of requirements in terms of logical expressions and automata
is used as basis for state-based and event-based synthesis.
The remaining requirements are defined and explained per module. Most requirements are in the
form of logical expressions. Automata are used for requirements that cannot be defined as logical
expressions. This collection of logical expressions and automata is used for synthesis as explained
in Subsection 6.1.2.
LED actuation
The reset LED may only be switched off if the status of the multimover is active or reset.
{ rl off } (MM Active MM Reset )
The reset LED may only be switched on if the status of the multimover is emergency.
{ rl on } MM Emergency
The forward LED may only be switched on if the status of the multimover is reset.
{ fl on } MM Reset
The forward LED may only be switched off if the status of the multimover is active or emergency.
{ fl off } (MM Active MM Emergency )
The backward LED may only be switched on if the status of the multimover is reset.
{ bl on } MM Reset
The backward LED may only be switched off if the status of the multimover is active or emergency.
{ bl off } (MM Active MM Emergency )
Motor actuation
The Scene Program Handler may only be switched off only if the status of the multimover is reset
or emergency.
{ sh disable } (MM Reset MM Emergency )
The Drive Motor may only be stopped if the status of the multimover is reset or emergency and
the Scene Program Handler is off.
{ dm stop } ((MM Reset MM Emergency ) SH Off )
The Steer Motor may only be switched off if the status of the multimover is reset or emergency
and the Drive Motor is off.
{ sm disable } ((MM Reset MM Emergency ) DM Off )
The Steer motor may only be switched on if the status of the multimover is Active.
{ sm enable } MM Active
The Drive Motor may only be switched on if the status of the multimover is Active and the Steer
Motor is on.
{ dm enable fw, dm enable bw } (MM Active SM On )
The Scene Program Handler may only be switched on if the status of the multimover is Active,
82
the Steer Motor is on and the Drive Motor is on.

{ sh enable } (MM Active SM On DM On )
The Drive Motor may only execute another drive command if the multimover is Active.
{ dm enable fw, dm enable bw, dm fw, dm fwslow, dm fwstop, dm bw, dm bwslow, dm bwstop }
MM Active
The automaton depicted in Figure 6.14 specifies the relationship between the Scene Program
Handler and the drive motor. If the Scene Program Handler receives a command to change the
direction sh chdir, the active state of the drive motor is changed. This requirement cannot be
specified as a logical expression.
dm stop
dm
dm
en
err
o
ab
le
fw
dm fw
dm fwslow
dm fwstop
sh chdir
sh chdir
dm stop
bw
le
or
err
ab
en
dm
dm
dm disable
dm error
dm bw
dm bwslow
dm bwstop
Figure 6.14: Requirement of the motor actuation module
Button handling
The multimover may only switch to Active if the forward button or the backward button (not
both) is pressed and the reset button is not pressed.
{ mm active } (((FB Pressed BB Released )
(BB Pressed FB Released )) RB Pressed )
The multimover may only switch to Reset if the reset button is pressed.
{ mm reset } RB Pressed
The automata depicted in Figures 6.15a and 6.15b determine the occurrence of the events dm enable fw
and dm enable bw. Both events are only allowed if first the corresponding interface button is
pressed (fb press or bb press) and then the multimover has become active (mm active). Note that
in this case, the occurrence of an event depends on a specific order of other events which must by
specified by automata.
83
mm active
mm emergency
mm reset
mm emergency
mm reset
fb press
fb release
fb release
dm enable fw
mm reset
mm emergency
mm active
fb press
fb release
(a)
mm active
mm emergency
mm reset
mm emergency
mm reset
bb press
bb release
bb release
dm enable bw
mm reset
mm emergency
mm active
bb press
bb release
(b)
Figure 6.15: Requirements of the button handling module
Proximity and Ride Control handling

The multimover must stop driving in the forward direction only if the status of Ride Control is
Stop or the FSP sensor is active.
{ dm fwstop } (RC Stop FSP Active )
The multimover must stop driving in the backward direction only if the status of Ride Control is
Stop or the BSP sensor is active.
{ dm bwstop } (RC Stop BSP Active )
The multimover must continue driving in the forward direction only if the status of Ride Control
is Start and the FSP sensor is inactive.
{ dm fwslow, dm fw } (RC Start FSP Inactive )
The multimover must continue driving in the backward direction only if the status of Ride Control
is Start and the BSP sensor in the backward direction is inactive.
{ dm bwslow, dm bw } (RC Start BSP Inactive )
84
The multimover must slow down in the forward direction only if the FLP sensor is active.
{ dm fwslow } FLP Active
The multimover must drive at regular speed in the forward direction only if the FLP sensor is
inactive.
{ dm fw } FLP Inactive
The multimover must slow down in the backward direction only if the BLP sensor is active.
{ dm bwslow } BLP Active
The multimover must drive at regular speed in the backward direction only if the BLP sensor is
inactive.
{ dm bw } BLP Inactive
The proximity module contains one requirement specified by an automaton. Since this automaton
is too large to depict here, only a description is given. This requirement specifies the occurrence
of the events dm fw, dm fwslow, dm fwstop, dm bw, dm bwslow, dm bwstop and dm stop. Each of
these events except dm stop is not allowed to take place twice without the occurrence of another
event in between. The automaton has seven states, S0 through S6 . S0 is the initial and marker
state. From every state including S0 , event dm stop goes to S0 . From every state except S1 ,
event dm fw goes to S1 . From every state except S2 , event dm fwslow goes to S2 . From every
state except S3 , event dm fwstop goes to S3 . From every state except S4 , event dm bw goes to
S4 . From every state except S5 , event dm bwslow goes to S5 . Finally, from every state except S6 ,
event dm fwstop goes to S6 .
6.1.2
Supervisor synthesis and validation
To indicate the complexity of the multimover supervisory control problem, Table 6.1 shows the
numbers and sizes of the plant components and the requirements. In the event-based framework,
it is not possible to derive a centralized supervisor for a problem of this size.
Table 6.1: Complexity of the supervisory control problem
No.
No.
No.
No.
of
of
of
of
components
states per component
control requirements
states per requirement
17
2-4
30
2-7
For the supervisory control problem of the multimover, a centralized state-based supervisor and
two distributed event-based supervisors are synthesized. The centralized supervisor has been
synthesized using the state-based approach of [23] based on state tree structures. The state-based
synthesis produces binary decision diagrams (BDD) for each controllable event. The maximum
BDD size is 15 and the minimum BDD size is 1. The BDD size of the optimal controlled behaviour
is 100. Furthermore, two distributed supervisors have been synthesized using the event-based
coordinated approach of [38] and the event-based aggregative approach of [39]. The results of
the event-based synthesis are shown in Tables 6.2 and 6.3 that illustrate the effectiveness of the
distributed synthesis techniques in application to supervisory control problems of this size.
For both approaches, the same multimover component models are used. The state tree structure
needed for the state-based approach applied consists of one AND superstate consisting of 17 OR
component superstates with which the corresponding automata are associated. In both cases,
also the same requirements (the collection of logical expressions and automata specified above)
are used as a starting point. The logical expressions are translated to the state-based expression
format required by the NBC tool supporting the [23] approach. The synthesis step takes only
85
a few seconds. Since only automata can be used for specifying the requirement models of a
distributed supervisor, an automatic conversion of logical expressions to automata is used. This
conversion allows design engineers to specify the formal requirements with automata and logical
expressions and still synthesize a distributed supervisor. In [15], a detailed description of the
results is provided.
For the application of the coordinated distributed technique, first local supervisors are synthesized for modules defined in Subsection 6.1.1 and associated requirements. As all modules under
control of their supervisors are nonconflicting, no coordinator is needed and, hence, no automaton
abstraction needs to be calculated.
Table 6.2: Distributed coordinated supervisors
Module
LED actuation
Motor actuation
Button handling
Emergency handling
Proximity handling
# states
25
41
193
181
481
# transitions
77
222
1541
2149
4513
For the application of the aggregated distributed technique, first the local supervisor is synthesized
for the LED actuation module and its requirements (see Appendix). An automaton abstraction
of the module under control of its supervisor is calculated and in combination with the motor
actuation module used for synthesis of the second local supervisor, etc. The sizes of the local
supervisors synthesized according to this procedure, in terms of numbers of states and transitions,
are stated in the left part of Table 6.3. In the right part of the table, the sizes of the local supervisors
synthesized in a different order are listed. In general, the existence of the solution, when using
aggregated procedure, may depend on the order in which modules are used for synthesis. In the
multimover case, several solutions are possible.
Table 6.3: Distributed aggregative supervisors depending on synthesis order
Module
LED actuation
Motor actuation
Button handling
Emergency handling
Proximity handling
Order
1
2
3
4
5
# states
25
41
465
89
225
# trans.
77
222
3477
626
1953
Order
5
2
4
3
1
# states
41
257
177
118
481
# trans.
125
1428
765
609
4513
The necessary steps of both distributed synthesis techniques are performed using the SuSyNA
package, see [35]. The synthesis and automaton abstraction steps take only a few seconds. The
nonconflicting check requires a longer calculation time, approximately one hour.
Synthesized supervisors have been evaluated to check whether the models of the controlled system
are consistent with the intended behaviour. For this purpose, discrete-event simulation is used
persistently. In this setting, the state-space stepper is used to explore the state space of the
closed-loop system behaviour. The state-space stepper allows to check whether the supervisor
disables right transitions in right states when evaluating a trace. Several scenarios relevant to the
multimover have been tested to confirm the validity of the models used. These scenarios involve
generation of control actions in reaction to generated events, such as a button is pressed or a sensor
is activated. All scenarios related to pressing the buttons and activating sensors are evaluated,
so that every local supervisor is activated, including the supervisor for the emergency and error
handling module. The CIF-toolset described in [42], in which also synthesis tools are integrated,
is used for discrete-event simulation.
86
6.1.3
Supervisor implementation
In the original supervisory control framework, a supervisor acts as a passive device that tracks
events produced by the plant and restricts the behaviour of the plant by disabling the controllable
events, see e.g., [4]. However, it is often the case that the plant does not generate all controllable
events on its own without being initiated. Usually, machines do not start their work unless a
start command is given. In this case, it is desirable to have a controller which not only disables
controllable events but also initiates the occurrence of particular controllable events, as indicated
by [11]. Furthermore, supervisory control theory is based on the assumption that the supervisor is
always synchronized with the state of the plant, i.e. there is no communication delay. However, in
contrast to the synchronous communication used in models, real systems often use asynchronous
communication. Hence, a supervisor can be seen as a dictionary of allowed events at each state of
the plant, from which an associated controller can choose an appropriate control action. In this
section, the implementation is explained of such a controller, which is referred to as a supervisory
controller. Simulation-based analysis of the synthesized supervisors indicated that there are no
infinite loops of controllable events. This means that each execution of the selected controllable
event brings the system closer to the desired final state. In this sense, although the supervisory controller still can choose between two control actions, it functionally resembles a directed
controller of [20].
uncontrollable events
State tracker
Supervisor
Plant
Control decision maker
controllable events
Figure 6.16: A supervisory controller

The functionality of a supervisory controller can be roughly divided in two tasks. The supervisory
controller needs to track the state of the plant in order to give appropriate feedback to the plant.
We call this part of the controller the state tracker. Next, the controller is responsible for sending
appropriate control actions back to the plant based on the state of the plant. We refer to this
part of the supervisory controller as the control decision maker. In Figure 6.16, a schematic
overview of a supervisory controller is given. In this figure, we can distinguish the plant which
represents the components and the low-level resource control, and a supervisory controller in the
filled frame. This supervisory controller contains a state tracker which tracks the state, a control
decision maker which sends appropriate actions back to the plant and a supervisor which contains
all allowed behaviour.
At some point, the plant generates an event (e.g., a button is pressed or a sensor is activated). A
notification must be sent to the state tracker, which updates the current state of the supervisor.
This is done by looking in the supervisor what the new current state is. Only uncontrollable events
are tracked by the state tracker, since the supervisory controller initiates the controllable events.
If the state tracker is ready with updating the current state of the supervisor, the control decision
maker has to search for an appropriate control action that can be sent back to the plant (e.g.,
turn the LED on or turn off the motor). If an appropriate control action is found, this action is
carried out and the current state of the supervisor is updated again.
The communication problem is related to building controllers from supervisory control models, as
discussed in [24]. This problem occurs when the controller sends a control action to the plant, but
in the meantime, the state of the plant is changed. Hence, a control action is chosen based on an
old state of the plant. Such a situation can occur because communication between the plant and
87
the controller in the real system is not synchronous.

In order to prove the concept of synthesis-based engineering, a prototype of a supervisory controller
with the synthesized supervisors is implemented in the existing control software of the multimover.
This implementation is set up in such a way that it works with all supervisors synthesized. A
schematic overview of the control architecture of the multimover with the supervisory controller is
given in Figure 6.17. The implemented supervisory controller replaces the existing control software
that has the same functionality.
Supervisor
State tracker / Control decision maker
Interface
LED RC
Bumperswitch RC
Motor RC
. . . RC
LED
Bumperswitch
Motor
...
Figure 6.17: Control architecture of the implementation

The lowest layer includes all components and their resource controllers. Above the resource control,
an interface is defined that is responsible for sending the correct events from the resource control
to the supervisory controller and sending the correct events from the supervisory controller to
the resource controllers. This interface makes use of a listener and notifier structure, which is a
simple communication paradigm used to implement distributed event handling systems. Libraries
supporting this paradigm are available in the C platform used for our case study. The resource
control of each component can publish messages of a certain topic and can subscribe to a certain
topic, which means that it receives all published messages of that topic. The interface is subscribed
to all relevant events and will receive them. This interface has to be coded manually, since it is
different for every system.
The next layer in Figure 6.17 is an implementation of a supervisory controller containing a state
tracker and a control decision maker. This layer is set up in such a way that it is independent
of the supervisor model, supervisory control framework used and the system itself. A generic
implementation of a supervisory controller is shown as pseudo-code of Algorithm 1. As already
mentioned, the functionality of the supervisory controller can be divided into two (parallel) tasks,
namely tracking the state of the system by the state tracker (lines 3 through 7) and making
appropriate control decisions by the control decision maker (lines 9 through 19).
All (uncontrollable) events that are generated by the plant (e.g. button and sensor signals) are
inserted by the interface in a buffer (called list). This buffer is emptied, one by one, by the state
tracker by taking and removing its first element (E pop(list)). Subsequently, the current state
of the supervisor is updated (line 5, UpdateSupervisor(S)). If the list is empty, the state tracker
knows the current state of the system. Based on this current state of the supervisor, a control
decision can be calculated.
If the current state of the supervisor has changed (S 1), the control decision maker has to check
if a control action is possible. Setting variable S to 1 (line 6) activates the control decision maker.
First, a control decision is computed. If an appropriate control action is found (line 11, E 6= 0),
the event list has to be checked (line 12), to ensure that the supervisory controller has made an
88
Algorithm 1 Supervisory controller implementation
5:
10:
15:
20:
loop
// State Tracker
while len(list) > 0 do
E pop(list);
UpdateSupervisor(E);
S1
end while
// Control Decision Maker
if S = 1 then
E ComputeControlAction;
if E 6= 0 then
if len(list) = 0 then
UpdateSupervisor(E);
ExecuteEvent(E)
end if
else
S0
end if
end if
end loop
appropriate control action based on the most actual state of the plant. If this is the case, the
state of the supervisor is updated and the appropriate control action is executed. Note that this
implementation does not prevent the execution of a control action based on an old state of the
supervisor. The communication problem can still occur.
If no control action is possible (e.g. all controllable events are disabled by the supervisor), there
is no need to search for a control action over and over again. So, the Boolean variable S is set to
0 (line 17), which means the control decision maker is not executed anymore. If the state of the
system changes again due to the occurrence of an uncontrollable event, the control decision maker
is activated again.
The next layer in Figure 6.17 is the supervisor itself, which contains the information about the
allowed behaviour, according to the requirements. This information can be generated from the
model of the supervisor. This is done by a script in Python, that reads the information from a CIF
model and stores this information in a lookup table. A lookup table is used for this information,
since a lookup table can be used with an efficient indexing operation, which can reduce processing
time. The details of the implementation can be found in [15].
The prototype implementation described above is suitable for supervisors of both frameworks,
either event-based or state-based. However, there are some differences with respect to how the
state is tracked and the control decisions are made for both frameworks. A supervisor that is
synthesized with the event-based framework contains the complete allowed language of the closedloop system, stored in one or more automata. The state is tracked by updating the current states of
the automata if an event occurred. An automaton is only updated if the event that has occurred is
also in the language of this automaton. If an event occurs that is not allowed by automata, then the
model is inadequate, since the state tracker cannot track the state of the system. If this happens,
the supervisory controller and all components are switched off. Control decisions are calculated
by searching for controllable events that are allowed by all automata. The first controllable event
that is found and allowed by all automata is chosen as the control action. A supervisor that is
synthesized with the state-based framework uses automata and BDDs to store the state feedback
control (SFBC) map in. The automata are used to store the information when each controllable
89
event is allowed by the plant models and the BDDs are used to store the information when each
controllable event is allowed by the state-based expressions. A state-based implementation uses
the plant models and event-based requirements to track the state of the system. All automata
of the plant models and event-based requirements are updated if an uncontrollable event occurs.
If an uncontrollable event occurs that is not allowed by an automaton, the state of the system
cannot be tracked and the model of the supervisor is inadequate. If this happens, the supervisory
controller and all components are switched off. Control decisions are calculated by searching for a
controllable event that is allowed by all automata and its BDD. The first controllable event that
is allowed by all automata and its BDD is used as a control action.
Our implementation is first tested on a test rack and, then, on a real vehicle. For testing, the same
scenarios were used as in simulation-based analysis of the synthesized supervisors that comprised
of pushing buttons and activating and deactivating sensors. All relevant situations were tested
exhaustively, in order to validate the error handling, proximity handling and emergency handling.
During the tests, the communication problem did not occur. This can be explained by the fact
that the supervisor responds sufficiently fast to the state changes of the plant. In the prototype
implementation, the choices in the supervisor do not depend on the order in which uncontrollable
events happen. Additionally, as the state changes are evaluated within 80 ms (for the state-based
supervisor; for the event-based supervisor within 20 ms), which is fast enough for the multimower,
the assumptions about asynchronous and instantaneous event firings mentioned in Sections 2 and 4
are satisfied by our prototype implementation. We conclude that both types of supervisors, statebased and event-based, are equally well suited for the system under investigation. Testing indicated
that the event-based supervisor is faster, but the state-based supervisor needs less memory.
As mentioned previously, the purpose of the project described in this paper was to show that our
model-based engineering process incorporating supervisor synthesis can reduce the time-to-market
and development costs. To this end, we compared the time needed for implementation of changes
associated with integration of one additional sensor and introduction of a few new requirements in
the actual company project and in our set up. The company project leader indicated that for this
change, approximately two man-days were needed to design, implement and test the new control
software, and subsequently to integrate it in the existing control system and test the integration,
according to the V-model. In our set up, approximately four hours were needed. However, we
observed that as long as synthesis tools are not incorporated in a commercially available modelbased engineering set up, the threshold for applying supervisor synthesis in industrial projects is
still too high.
90
Chapter 7
Data-based synthesis
In Chapter 3 we have seen that, even for discrete event systems, the use of discrete variables
in modelling plant automata is very convenient and prevents the plant automata from becoming
unnecessarily large. In Chapter 5 however a theory for synthesising proper supervisors has been
presented that does not allow the use of such syntactically rich plant automata. There both the
plants and the requirement automata had to be modelled using automata in which no variables
could be used. In Section 5.5 a requirement specification formalism, state-based expressions, has
been presented that allows the use of Boolean variables referring to the states of plant automata.
It was demonstrated that this already is much more convenient from the point of view of modelling
some of the requirements.
In this chapter we will introduce, at a rather informal level, a form of synthesis, that is called
data-based synthesis which allows the use of discrete variables in plant models. We adapt the
basic supervisory control problem from Section 5.2 to deal with plant automata that use discrete
variables. Consider for example the plant automaton shown in Figure 7.1.
x<8
e1
x := x + 2
x=0
1
0
x<7
e2
x := x + 1
Figure 7.1: Plant automaton with variables to which data-based synthesis is to be applied.
If you inspect the behaviour of this plant, for example by means on interactive simulation in CIF,
you may easily find that the plant has blocking states, and even deadlock states. The state space
of this plant is shown in Figure 7.2. It would be useful to have a theory of synthesis that allows
to synthesize a supervisor that prevents blocking while maintaining controllability.
One way of achieving this is to first represent the plant automaton by another plant automaton
that does not use the discrete variables. Actually, the automaton from Figure 7.2 would be a good
candidate for this. In general, the resulting plant automata could be really big! On the dataless
plant automaton synthesis can be applied to obtain a proper supervisor that is controllable and
nonblocking.
91
92
CHAPTER 7. DATA-BASED SYNTHESIS

e1
0,0
e2
1,2
e1
0,3
e2
1,5
e1
0,6
1,8
Figure 7.2: State space of the plant automaton from Figure 7.1. The names of the locations are
pairs of numbers, the first of which represents the name of the location the plant is in and the
second number is the value of the variable x.
7.1
Basic data-based supervisory control problem
In this section we will introduce a variant of synthesis, called basic data-based synthesis that
allows to obtain a proper supervisor for plants in which variables are used. This application does
not support all CIF specifications. In the present implementation of this algorithm in CIF only
discrete variables with a Boolean type, ranged integer type (e.g., int[0..5]), or enumeration type
are supported. Continuous variables and algebraic variables are not supported1 . Automata with
automaton and supervisor kind are not supported. Specifications without plant automata are not
supported. Events not declared as controllable or uncontrollable are not supported. Locations of
plant automata must either be initial or non-initial. Plant automata must have exactly one initial
location. Locations that are initial in some situations and not initial in other situations (e.g.,
initial x > 2) are not supported. Plant automata with non-determinism are not supported.
That is, plant automata that have locations with multiple outgoing edges for the same event, with
overlapping guards (e.g., x > 1 and x < 4), are not supported.
Only limited forms of assignments are supported. For a Boolean variable x, only assignments of the
form x := not x and x := b are supported, for Boolean expression b2 . For an integer variable x,
only assignments of the form x : = n, x := x + n, and x := x - n are supported, for integer
expression n. Here n may be an integer value, or a computation that results in an integer value,
as long as the computation is not too complex to be performed statically. For an enumeration
variable x, only assignments of the form x := y are supported, for expression y, where y may
be a enumeration literal, or a computation that results in an enumeration literal, as long as the
computation is not too complex to be performed statically.
Only limited forms of predicates (for markers, invariants, initialization, guards, etc) are supported.
The supported predicates are:
Boolean literals (true, false), discrete Boolean variables (x, for x a discrete variable with
a Boolean type), and locations (aut.loc, for aut an automaton name and loc a location of
that automaton).
Expressions composed using the unary inverse operator (not), and the binary logical operators conjunction (and), disjunction (or), logical implication (=>), and biconditional or
equality (<=>).
Predicates over a single Boolean variable x (x op b, b op x). The supported operators (in
place of op) are equality (=) and inequality (!=). b is a Boolean expression as in the case of
assignments.
1 Further restrictions apply. Discrete variables with initial values that are too complex to evaluate statically,
are not supported. That is, their initial values must essentially be constant. For instance, 1 + 1 and 2 * 5 are
supported, as is c + 1 if c is a constant. However, v * 2 with v a discrete variable that can initially have several
different values, is not supported.
2 The Boolean expression b may be a Boolean value (true or false), or a computation that results in a Boolean
value, as long as the computation is not too complex to be performed statically. That is, b must essentially be
constant. For instance, true and false is a supported computation for b, as is c => d if c and d are constant.
However, v <=> true with v a discrete variable is not supported, as the computation results in different values for
different values of v.
7.1. BASIC DATA-BASED SUPERVISORY CONTROL PROBLEM
93
Predicates over a single integer variable x (x op n, n op x). The supported operators (in
place of op) are equality (=), inequality (!=), less than (<), less than or equal (<=), greater
than (>), and greater than or equal (>=). n is an integer expression (see assignments above).
Predicates over a single enumeration variable x (x op y, y op x). The supported operators
(in place of op) are equality (=) and inequality (!=). y may be an expression that results in
an enumeration literal (see assignments above).
The basic data-based supervisory control problem is formulated as follows. For a plant a supervisor
is required such that:
1. The controlled system is non-blocking. That is, it is possible to reach a marked state from
all reachable states in the controlled system.
2. The controlled system is controllable. That is, for all reachable states in the controlled
system, the uncontrollable events that are enabled in the same state in the uncontrolled
system are still possible in the controlled system. In other words, uncontrollable events are
not restricted.
3. The controlled system is maximally permissive (or simply maximal). That is, the controlled
system permits all safe, controllable, and non-blocking behaviors.
Note that essentially this is mostly the same supervisory control problem as was presented before.
The only differences are that the plant automata may contain discrete variables with finite domain
and that the supervisor may refer to states of the plant automata and may use the variables of
the plant automata. In Section 7.4 the synthesis procedure is explained in more detail.
The transformation can be started from Eclipse in the following ways:
Right click a .cif file in the Project Explorer or Package Explorer and choose Conversions I
Apply data-based supervisory controller synthesis....
Right click an open text editor for a .cif file and choose Conversions I Apply data-based
supervisory controller synthesis....
If the supervisor has to restrict so much of the behavior of the uncontrolled system that no initial
state remains, the controlled system becomes empty. The synthesis algorithm then ends with an
empty supervisor error, and no output CIF file is created.
If an initial state remains after synthesis, an output CIF file is created. The Synthesis output
contents option can be used to specify the contents of the output CIF file. The contents is either
an external supervisor (with plant skeletons), or the controlled system (input specification, without
requirements, but with the external supervisor).
The supervisor uses the same events as the plants, and refers to plant locations and variables in
its conditions. If only an external supervisor is requested as output, skeletons for the parts of the
plants that are used by the supervisor are added to the resulting specification. This allows the
supervisor file to be merged with the original uncontrolled system to obtain the controlled system.
No skeletons are added if the controlled system is requested as output, as then the uncontrolled
system itself is part of the output.
The resulting supervisor has one or more self loops for each of the controllable events in the alphabet of the controlled system (which is equal to the alphabet of the uncontrolled system). These
self loops represent the possible conditions under which the events may occur in the controlled
system.
94
The resulting supervisor may have an initialization predicate that restricts the states in which
the system may be initialized (may start), on top of the initialization constraints already present
in the uncontrolled system. The synthesis algorithm ensures that in the controlled system, the
requirement invariants hold in all reachable states. It also ensures that in the controlled system,
for all transitions from reachable states, the events only occur if their event requirement conditions
hold. If a variable in the uncontrolled system has a single initial value, and the initialization predicate is restricted to not allow this initial value, initialization will be impossible, causing an empty
supervisor error. For variables with multiple potential initial values, the synthesis algorithm may
restrict initialization to disallow certain initial values, while still leaving possibilities for initialization. For variables declared to initially have an arbitrary initial value, the synthesis algorithm
essentially determines under which conditions the system can be started, and still exhibits only
safe, non-blocking behavior.
7.2
General data-based supervisory control problem
The data-based supervisory control algorithm as it is implemented in CIF allows the specification
of the state-based expressions introduced in Section 5.5, without requiring a transformation into
automata as was the case for the event-based synthesis algorithms used in Chapter 5. As it is
often very convenient to be able to refer to the values of variables in requirements as well as to the
locations the plant automata may be in, the state formulas are extended to also allow predicates
about the values of the variables. Two types of state-based requirements are considered: invariants
or mutual state exclusions, and event requirement conditions.
As a straightforward example consider the unrestricted counter plant from Figure 7.3. We can
formulate a requirement that restricts the counting to the domain from and including 2 to and
including 5 either by stating the invariant 2 count count 5 or by the event requirement
conditions { increment } count < 5 and { decrement } count > 2.
count = 3
increment
count := count + 1
decrement
count := count 1
Figure 7.3: Plant automaton for the unrestricted counter.

In CIF the invariant 2 count count 5 is modelled as
requirement invariant 2 <= Counter.count and Counter.count <= 5;
where Counter is the name of the CIF version of the plant automaton in Figure 7.3.
The event requirement conditions { increment } count < 5 and { decrement } count > 2
are modelled as a requirement automaton with a single anonymous location as follows
requirement req1:
location:
initial;
marked;
edge increment
edge decrement
end
when Counter.count < 5;

when Counter.count > 2;
7.3. AUTOMATA FOR CAPTURING REQUIREMENTS
95
Requirements that have events in their alphabet that are not in the alphabet of any of the plants,
are not supported. Regular invariants, plant invariants, and supervisor invariants are not supported. Only requirement invariants are supported. Requirement automata must have exactly
one location, that is both initial and marked. The edges may not have any updates. Only one self
loop edge for each event is allowed, per requirement automaton.
Data-based supervisory controller synthesis can be used to synthesize a supervisor for an untimed
CIF specification, with data (discrete variables). For a CIF specification with plants and requirements, the tool computes a supervisor. The supervisor restricts the plants in such a way that the
resulting controlled system satisfies the following properties:
1. The controlled system is safe. That is, all reachable states in the controlled system satisfy
the requirements.
2. The controlled system is non-blocking. That is, it is possible to reach a marked state from
all reachable states in the controlled system.
3. The controlled system is controllable. That is, for all reachable states in the controlled
system, the uncontrollable events that are enabled in the same state in the uncontrolled
system are still possible in the controlled system. In other words, uncontrollable events are
not restricted.
4. The controlled system is maximally permissive (or simply maximal). That is, the controlled
system permits all safe, controllable, and non-blocking behaviors.
Exercise 7.2.1. Reconsider the manufacturing process from Exercise 3.4.5, Example 5.1.1, and
Exercise 5.1.1. Formulate the requirements stated in Exercise 3.4.5 as state-based expressions, if
possible. Synthesize a supervisor and compare the result to previous attempts.

Exercise 7.2.2. Reconsider the traffic system from Exercise 5.5.2. This time, develop the required
controller using data-based synthesis.

Exercise 7.2.3 (Workcell with a test unit, continued). Formulate all the requirements of the
workcell from Exercise 5.3.3 with a test unit as data-based requirements. Perform data-based
synthesis.

Exercise 7.2.4 (Workcell with a test unit, data-based buffer). Replace the plant model for the
buffer in the workcell of Exercise 5.3.3 with a plant model for a buffer with a capacity of 20
workpieces. Now, reformulate the requirements and apply data-based synthesis.
7.3
Automata for capturing requirements
In the previous section we have seen that two typical types of data-based state requirements may
be used for data-based synthesis. In the current implementation, data-based synthesis cannot deal
with requirements expressed as automata, not even without using data in those. This means that
requirements such as the ones used in Example 5.3.1 can not be used.
However, in this section we present a method for data-based synthesis of general requirement
automata (with and without variables). The method entails a transformation of such requirement
automata to plant automata and the introduction of new event requirement conditions.
The following steps have to be performed for each requirement automaton:
1. Add the requirement automaton as a plant (i.e., replace the keyword requirement with the
keyword plant. Add the keyword monitor; as a first line to declare the plant automaton to
96

be a monitor automaton. A monitor automaton is an automaton that monitors or observes
one or more events. The events that it monitors, are never blocked (disabled) by that
automaton. By default, automata do not monitor any events. Using a monitor declaration
with one or more events, turns the automaton into a monitor automaton for those events.
2. Introduce a new event condition requirement for each edge from the requirement automaton.
For an edge with event e from location loc with guard g add the event condition requirement
{ e } R.loc g, where R is the name of the plant automaton that was introduced to
replace the requirement automaton. In case there are multiple event condition requirements
with the same event name these need to be combined into one self loop where the when
parts are combined using logical or.
repair M1
breakdown M2
end M1
Empty
Full
start M2
M2notDown
M2Down
repair M2
Figure 7.4: Requirement automata R1 and R2 for the manufacturing process from Example 5.3.1.
Consider, as an example, the requirements that have been modelled by means of automata (without
variables) from Example 5.3.1 as shown in Figure 7.4. In CIF the result of the transformation
explained in general terms above is
plant plant_R1:
monitor;
location Empty:
initial; marked;
edge end_M1 goto Full;
location Full:
edge start_M2 goto Empty;
end
requirement R1:
location:
initial; marked;
edge end_M1 when plant_R1.Empty;
edge start_M2 when plant_R1.Full;
end
for the requirement automaton in the left of Figure 7.4, and
plant plant_R2:
monitor;
location M2notDown:
initial; marked;
edge breakdown_M2 goto M2Down;
edge repair_M1;
location M2Down:
edge repair_M2 goto M2notDown;
end
7.4. BASIC DATA-BASED SYNTHESIS ALGORITHM
97
requirement R2:
location:
initial; marked;
edge breakdown_M2, repair_M1 when plant_R2.M2notDown;
edge repair_M2 when plant_R2.M2Down;
end
for the right requirement automaton in Figure 7.4. Observe that the edges introduced are combined
into one requirement automaton for each of the requirements.
Exercise 7.3.1 (Motor actuation subsystem of the multimover). Apply data-based supervisory
control synthesis for the motor actuation system of the multimover from Chapter 6.
7.4
Basic data-based synthesis algorithm
In the remainder of this section the synthesis procedure that results in a proper supervisor will be
introduced informally. The synthesis algorithm implemented in CIF is based on [29]. Synthesis of
a system consisting of a number of plant automata is defined to be synthesis on the synchronous
product of the plant automata. Therefore, we restrict the treatment of the synthesis approach to
the case of a single plant automaton.
The algorithm operates by adapting the plant automaton repeatedly until the situation arises that
no more changes occur. Each of these iterations consists of three phases:
1. Compute nonblocking conditions for all locations of the plant.
2. Compute bad state conditions for all locations.
3. Adapt guards of transitions with controllable events to obtain an adapted automaton.
Compute nonblocking conditions

The first phase of the algorithm requires to compute for each location of the plant automaton a
predicate that states for which values of the variables3 the location is nonblocking. Recall that a
state is nonblocking if from that state a sequence of transitions is enabled that leads to a maker
state.
Determining the nonblocking conditions is done iteratively as well. The intuition is that in the first
approximation we only consider the locations themselves and in subsequent iterations we refine
the nonblocking conditions. In iteration k we take into account all sequences of k edges from a
location.
1. Initially, associate the predicate true with all marked locations and the predicate false with
all other locations. These marked locations are nonblocking for all possible values of the
variables of the automaton. Non-marked locations are never non-blocking.
(
true if i is a marked location
Ni :=
false if i is not a marked location
3 Note that the state predicates aut.loc are considered Boolean variables in this respect which hold true when
the plant automaton aut is in location loc, and false otherwise.
98

2. In the next iteration, the new nonblocking condition of a location is the disjunction (,
pronounced or) of the old nonblocking condition and, for each outgoing edge of the location a
disjunct of the form gNt [u], where g is the guard of the edge and Nt [u] is the old nonblocking
condition of the target location of the edge where all occurrences of the variables are replaced
by the expressions they are assigned in the update of the edge. Always simplify the resulting
predicates!
Ni = Ni
(g Nj [u])
g e u
i j
g e u
In this formula the notation i j indicates an edge from location i to location j with
guard g, event e and assignment u.
Considering the plant automaton of Figure 7.1, the above algorithm results in the following nonblocking conditions.
Iteration
0
1
2
Location 0
true
true
true
Location 1
false
x<7
x<7
After three iterations we observe that the nonblocking conditions did not change between the
last two iterations. Therefore, the computation of the nonblocking conditions terminates. Note
that these nonblocking conditions are in line with intuitions. In the marker state the nonblocking
condition is, and always will be true. The nonblocking condition for location 1 states that in case
x < 7 a marker state is reachable. This is correct since in such a case the edge to the marker state
is enabled.
From this example it does not seem necessary to use such a complex iterative algorithm to compute
the nonblocking conditions, but for automata in which there is more distance between locations
and marker locations and in which there are more transitions the full generality of the presented
approach is required.
Exercise 7.4.1. For each of the locations in the automaton in Figure 7.5, compute the nonblocking
conditions.

x0
x := x + 2
x3
2
x := x 1
Figure 7.5: Plant automaton with discrete variables.
conditions. Note that the CIF tooling currently does not support data-based synthesis for plant
automata with assignments such as x:=y and y:=y+x.

conditions.
99
y := y 1
0
x7
x := x + 2
x>y3
x := y, y := y + x
3
y >3x5

x = 0, y = 10
x8y 6
e2
x7
e1
x := x + 1, y := y + 1
Compute bad state conditions

The purpose of the computation of the nonblocking conditions is to use these to strengthen the
guards of incoming edges to such an extent that never the location is reached when the nonblocking
condition does not hold. In case the plant would only consist of controllable events it would suffice
to use the nonblocking state conditions for this purpose. However, if uncontrollable events are
present we are not allowed to enforce the required restrictions by adapting the guard of these
uncontrollable events.
The synthesis algorithm does not restrict any uncontrollable events. Instead, such restrictions are
propagated backwards to the source state of the edge with the uncontrollable event, and from
there to the transitions that lead to the source state, etc. They are propagated backwards until
an edge with a controllable event is encountered (for which the guard can be restricted).
This is achieved by the bad state condition computation explained below. Using the plant automaton and the computed nonblocking conditions we compute bad state conditions for each location.
Again, this requires an iterative approach that terminates whenever for each location the bad state
conditions of the last two iterations are identical.
Define the initial bad state condition for each location simply as the logical negation of the
nonblocking condition of that location.
In the next iteration, the new bad state condition of a location is the disjunction (, pronounced or) of the old bad state condition and, for each outgoing edge of the location that
sis labelled with an uncontrollable event a disjunct of the form g Bt [u], where g is the
guard of the edge and Bt [u] is the old bad state condition of the target location of the edge
where all occurrences of the variables are replaced by the expressions they are assigned in
the update of the edge. Always simplify the resulting predicates!
100
Continuing with the results of the nonblocking condition computation for the running example
we obtain the following bad state condition computation. Recall that event e1 is controllable and
event e2 uncontrollable. Since the only outgoing edge of location 0 is controllable, the bad state
conditon of that location will be false in each iteration. For the second iteration (named iteration
1) the bad state condition is x 7 (x < 7 false[x + 1/x]) which is logically equivalent to x 7.
Thus the computation only requires two iterations. See the summary below.
Iteration
0
1
Location 0
false
false
Location 1
x7
x7
Synthesis is successful only in case the bad state condition of the initial location is not satisfied
for the initial values of the variables.
Adapt guards
The bad state conditions computed in the previous phase express which combinations of values of
variables should be avoided in a specific location, taking into account the limitation that guards
of uncontrollable events may not be altered.
The guards of the edges with a controllable event are adapted by adding as a conjunct the expression Bt [u] where Bt [u] is the bad state condition of the target location of the edge where all
occurrences of the variables are replaced by the expressions they are assigned in the update of the
edge. Always simplify the resulting predicates!
The adapted guard for the edge labelled with the controllable event e1 then becomes x < 8(x
7)[x + 2/x] which may be simplified as follows: x < 8 (x 7)[x + 2/x] = x < 8 (x + 2
7) = x < 8 (x 5) = x < 8 x < 5 = x < 5.
The automaton that results after the first iteration of the synthesis algorithm is shown in Figure
7.8. Note that since a guard has changed the three phases have to repeated at least once more.
For the running case, the second iteration provided exactly the same automaton and thus the
x<5
e1
x := x + 2
x=0
1
0
x<7
e2
x := x + 1
Figure 7.8: Adapted plant automaton after the first iteration of the synthesis algorithm.
result shown in Figure 7.8 is actually the result of the synthesis procedure.
Exercise 7.4.4. Compute the supervisor for the automaton in Figure 7.9.
Exercise 7.4.5. Manually perform data-based synthesis for the automaton of Figure 7.7. Repeat
the exercise for the same plant automaton, for all other possible ways of uncontrollable and
controllable events e1 and e2 .

Exercise 7.4.6. Repeat the synthesis of a proper controller for the plant automaton shown in
Figure 7.10.
x<8
e1
x := x + 1
101
x<9
e1
x := x + 1
x=0
2
0
x<7
e2
x := x + 1
Figure 7.9: Plant automaton with variables to which data-based synthesis is to be applied in
Exercise 7.4.4.
x<8
e1
x := x + 2
x=0
1
0
x<7
e2
x := x + 1
Figure 7.10: Plant automaton for Exercise 7.4.6.
102
Bibliography
[1] J. C. M. Baeten, J. M. van de Mortel-Fronczak, and J. E. Rooda. Integration of supervisory
control synthesis in Model-Based Systems Engineering. In Proceedings of ETAI/COSY 2011,
pages 167 178. IEEE, 2011.
[2] J.C.M. Baeten, D.A. van Beek, B. Luttik, J. Markovski, and J.E. Rooda. A process-theoretic
approach to supervisory control theory. In Proceedings of ACC, pages 44964501. IEEE, 2011.
[3] C. Baier and J.P. Katoen. Principles of model checking. MIT Press, 2008.
[4] S. Balemi. Control of discrete event systems: theory and application. PhD thesis, Swiss
Federal Institute of Technology Zurich, 1992.
[5] N.C.W.M. Braspenning, R. Boumen, J.M. van de Mortel-Fronczak, and J.E. Rooda. Estimating and quantifying the impact of using models for integration and testing. Computers
in Industry, 62(1):6577, 2011.
[6] N.C.W.M. Braspenning, J.M. van de Mortel-Fronczak, and J.E. Rooda. A model-based
integration and testing method to reduce system development effort. ENTCS, 164(4):1328,
2006.
[7] E. Brinksma and J. Tretmans. Testing transition systems: An annotated bibliography. In
Modeling and Verification of Parallel Processes, volume 2067 of Lecture Notes in Computer
Science, pages 187195. 2001.
[8] K. Cai and W.M. Wonham. Supervisor localization: A top-down approach to distributed
control of discrete-event systems. IEEE Transactions on Automatic Control, 55(3):605618,
2010.
[9] C. G. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. International
Series on Discrete Event Dynamic Systems. Springer-Verlag, 1999.
[10] M.H. de Queiroz and J.E.R. Cury. Modular supervisory control of composed systems. In
Proceedings of ACC, pages 40514055, 2000.
[11] P. Dietrich, R. Malik, W.M. Wonham, and B.A. Brandin. Implementation considerations
in supervisory control. In Synthesis and Control of Discrete Event Systems, pages 185201.
Kluwer Academic Publishers, 2002.
[12] J.A. Estefan. Survey of Model-Based Systems Engineering (MBSE) methodologies. Technical
report, INCOSE, 2008.
[13] L. Feng and W.M. Wonham. Computationally efficient supervisor design: abstraction and
modularity. In Proceedings of WODES, pages 38, 2006.
[14] H. Flordal, R. Malik, M. Fabian, and K. Akesson. Compositional synthesis of maximally permissive supervisors using supervisor equivalence. Discrete Event Dynamic Systems, 17(4):475
504, 2007.
103
104
BIBLIOGRAPHY
[15] S.T.J. Forschelen. Supervisory control of theme park vehicles. MSc thesis, Eindhoven University of Technology, 2010.
[16] S.T.J. Forschelen, J.M. van de Mortel-Fronczak, R. Su, and J.E. Rooda. Application of supervisory control theory to theme park vehicles. Discrete Event Dynamic Systems, 22(4):511540,
2012.
[17] M. Heemels and G. Muller, editors. Boderc: Model-based Design of High-tech Systems. Embedded Systems Institute, second edition, 2007.
[18] Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. HyTech: A model checker for
hybrid systems. 1(12):110122, 1997.
[19] R.C. Hill, D.M. Tilbury, and S. Lafortune. Modular supervisory control with equivalencebased conflict resolution. In Proceedings of ACC, pages 491498, 2008.
[20] J. Huang and R. Kumar. Directed control of discrete event systems for safety and nonblocking.
IEEE Transactions on Automation Science and Engineering, 5(4):620629, 2008.
[21] R.J. Leduc, M. Lawford, and W.M. Wonham. Hierarchical interface-based supervisory
control-part II: parallel case. IEEE Transactions on Automatic Control, 50(9):13361348,
2005.
[22] J. Lygeros. Lecture notes on hybrid systems. Technical report, Department of Electrical and
Computer Engineering, University of Patras, 2004.
[23] C. Ma and W.M. Wonham. Nonblocking supervisory control of state tree structures. IEEE
Transactions on Automatic Control, 51(5):782793, 2006.
[24] P. Malik. From supervisory control to nonblocking controllers for discrete event systems. PhD
thesis, University of Kaiserslautern, 2003.
[25] R. Malik and H. Flordal. Yet another approach to compositional synthesis of discrete event
systems. In Proceedings of WODES, pages 1621, 2008.
[26] J. Markovski, K.G.M. Jacobs, D.A. van Beek, L.J.A.M. Somers, and J.E. Rooda. Coordination of resources using generalized state-based requirements. In Proceedings of WODES,
pages 297302, 2010.
[27] J.N. Martin. Systems Engineering Guidebook. CRC Press, 1996.
[28] G.J. Muller. Coupling enterprise and technology by a compact and specific architecture
overview. In Proceedings of INCOSE, 2007.
[29] Lucien Ouedraogo, Ratnesh Kumar, Robi Malik, and Knut
Akesson. Nonblocking and safe
control of discrete-event systems modeled as extended finite automata. IEEE T. Automation
Science and Engineering, 8(3):560569, 2011.
[30] P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event processes.
SIAM Journal on Control and Optimization, 25(1):206230, 1987.
[31] P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event processes.
SIAM J. Control and Optimization, 25(1):206230, 1987.
[32] E. Rechtin and M.W. Maier. The Art of Systems Architecting. CRC Press, 1997.
[33] E. Rechtin and M.W. Maier. The Art of Systems Architecting. CRC Press, 2000.
[34] R.R.H. Schiffelers, R.J.M. Theunissen, D.A. van Beek, and J.E. Rooda. Model-based engineering of supervisory controller using CIF. Electronic Communication of the European
Association of Software Science and Technology, 21(9):110, 2009.
BIBLIOGRAPHY
105
[35] SE Group, Eindhoven University of Technology. SuSyNA package, 2010.

[36] A.C. Shaw. Real-Time Systems and Software. John Wiley & Sons, Inc., 2001.
[37] R. Su and J.G. Thistle. A distributed supervisor synthesis approach based on weak bisimulation. In Proceedings of WODES, pages 6469, 2006.
[38] R. Su, J. van Schuppen, and J. Rooda. Synthesize nonblocking distributed supervisors with
coordinators. In Proceedings of the 17th Mediterranean Conference on Control and Automation, pages 11081113, 2009.
[39] R. Su, J.H. van Schuppen, and J.E. Rooda. Aggregative synthesis of distributed supervisors
based on automaton abstraction. IEEE Transactions on Automatic Control, 55(7):16271640,
2010.
[40] R. Su, J.H. van Schuppen, and J.E. Rooda. The synthesis of time optimal supervisors by
using heaps-of-pieces. IEEE Transactions on Automatic Control, 57(1):105118, 2012.
[41] D. A. van Beek, Wan Fokkink, D. Hendriks, A. Hofkamp, Jasen Markovski, J. M. van de
Mortel-Fronczak, and Michel A. Reniers. CIF 3: Model-based engineering of supervisory
controllers. In Erika Abrah

am and Klaus Havelund, editors, Tools and Algorithms for the
Construction and Analysis of Systems - 20th International Conference, TACAS 2014, Held
as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2014,
Grenoble, France, April 5-13, 2014. Proceedings, volume 8413 of Lecture Notes in Computer
Science, pages 575580. Springer, 2014.
[42] D.A. van Beek, M.A. Reniers, J.E. Rooda, and R.R.H. Schiffelers. Concrete syntax and
semantics of the Compositional Interchange Format for hybrid systems. In Proc. of the 17th
IFAC World Congress, 2008.
[43] M.P.W.J. van Osch. Automated model-based testing of hybrid systems. PhD thesis, Eindhoven
University of Technology, The Netherlands, 2009.
[44] J.W.H. Verhoeven. Robust supervisory control of a patient support system. Technical Report SE Report 2014-SE-420768, Manufacturing Networks Group, Department of Mechanical
Engineering, Eindhoven University of Technology, 2014.
[45] K.C. Wong and W.M. Wonham. Hierarchical control of discrete-event systems. Discrete
Event Dynamic Systems: Theory and Applications, 6(3):241273, 1996.
[46] W.M. Wonham. Supervisory control of discrete-event systems. Technical report, University
of Toronto, 2010.

Fronczak, Reniers - Model-Based Systems Engineering - 4TC00 Dictaat 2014-2015 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fronczak, Reniers - Model-Based Systems Engineering - 4TC00 Dictaat 2014-2015 PDF

Cargado por

Copyright:

Formatos disponibles

Model-Based Systems Engineering Lecture Notes 4TC00

J.M. van de Mortel-Fronczak

2 Introduction to Model-Based Systems Engineering

3 Modelling Plants and Controllers/Supervisors

Continuous-time behaviour and mode switching . . . . . . . . . . . . . . . . . . . .

Networks of hybrid automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Supervisory control of a patient support system

The ideal patient support system . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Model of the ideal patient support system . . . . . . . . . . . . . . . . . . .

Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Model of the errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Controller with error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Real world model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Model of the controller with error handling . . . . . . . . . . . . . . . . . .

5 Supervisory Control Theory

Notions and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Basic supervisory control problem . . . . . . . . . . . . . . . . . . . . . . . . . . .

General supervisory control problem . . . . . . . . . . . . . . . . . . . . . . . . . .

Overview of advanced synthesis techniques . . . . . . . . . . . . . . . . . . . . . . .

6 Applications of Supervisory Control Theory

Theme Park Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Plant and requirement models

Supervisor synthesis and validation . . . . . . . . . . . . . . . . . . . . . . .

Basic data-based supervisory control problem . . . . . . . . . . . . . . . . . . . . .

General data-based supervisory control problem . . . . . . . . . . . . . . . . . . . .

Automata for capturing requirements . . . . . . . . . . . . . . . . . . . . . . . . . .

Basic data-based synthesis algorithm . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to High Tech

1. common language and background between multiple engineering disciplines is lacking

3. dynamic and time-depending aspects are complex to grasp

4. out-of-phase evolution of design in the mono-disciplines

CHAPTER 1. INTRODUCTION TO HIGH TECH SYSTEMS DESIGN

According to INCOSE (International Council on Systems Engineering, www.incose.org), Systems

1.1. SYSTEMS ENGINEERING

CHAPTER 1. INTRODUCTION TO HIGH TECH SYSTEMS DESIGN

CHAPTER 1. INTRODUCTION TO HIGH TECH SYSTEMS DESIGN

CHAPTER 2. INTRODUCTION TO MODEL-BASED SYSTEMS ENGINEERING

Figure 2.1: Positioning supervisory control.

Figure 2.2: Traditional engineering process.

Figure 2.3: Model-based engineering process.

CHAPTER 2. INTRODUCTION TO MODEL-BASED SYSTEMS ENGINEERING

Figure 2.4: Engineering process with supervisory control synthesis.

2.2. APPLICATIONS OF MODELS

CHAPTER 2. INTRODUCTION TO MODEL-BASED SYSTEMS ENGINEERING

Modelling Plants and

CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS

3.1. CONTINUOUS-TIME BEHAVIOUR AND MODE SWITCHING

Figure 3.1: Screenshot of a CIF session. Source: http://cif.se.wtb.tue.nl/index.html.

Continuous-time behaviour and mode switching

CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS

3.1. CONTINUOUS-TIME BEHAVIOUR AND MODE SWITCHING

towards zero degrees, according to the differential equation

Figure 3.3: Hybrid automaton for the simple thermostat system.

CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS

3.1. CONTINUOUS-TIME BEHAVIOUR AND MODE SWITCHING

CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS

Figure 3.5: The water tank system, copied from [22]

3.2. DISCRETE VARIABLES

edge increment goto C1;

Figure 3.6: (Hybrid) Automaton for the counter.

CHAPTER 3. MODELLING PLANTS AND CONTROLLERS/SUPERVISORS

do count := count + 1 goto on;