Design of the supervisory control layer for electron
microscopes
T.M.W. Janssen
SE 420712
Master’s thesis
Supervisor:
Prof.dr. J.C.M. Baeten
Advisors:
Dr.ir. J.M.van de Mortel-Fronczak
Ir. M.J.A.M. van Gerwen (FEI Company)
Technische Universiteit Eindhoven
Department of Mechanical Engineering
Systems Engineering Group
December 19, 2012
iv
Summary
Manufacturing companies are continuously seeking for improvements in their control software
development process to be able to deal with more complex software and shorter time-to-market
while maintaining the quality. This trend also holds for FEI Company, which produces advanced
electron microscopes. A recent change in the FEI software development process is the introduction
of the model-based engineering tool ASD Suite from the Dutch company Verum Software
Technologies BV, which introduces formal methods in the development process. The advantages
are faster development times, lower cost, and higher quality of the developed software.
To check if the software is correct with respect to the requirements specified, the developed software
is currently functionally verified using unit tests and manual testing which is time intensive
and error prone. Therefore, FEI is investigating whether formal methods also can be used for
functional verification. Supervisory control theory is a theory that automatically synthesize a
supervisor based on models of the system components and requirements specified as automata
or formal expressions. The advantage is the clear connection between the requirements specified
in documents and the requirements used for the synthesis. Moreover, the resulting supervisor is
correct with respect to these requirements. Because of this, a further reduction in number of unit
tests and manual testing time can be established. The goal of this project is to investigate how
the supervisory synthesis tooling of Eindhoven University of Technology can help FEI Company
in developing correct control software for its electron microscopes.
Using a small example, the differences and similarities of the currently used software development
package ASD and the supervisory control synthesis tooling are researched. The CmosProtector
that protects a highly sensitive camera of a electron microscope from a too high electron dose
is elaborated as a case study. This software component is explained and the requirements are
gathered by reading the design notes and unit tests, and by talking to developers.
A coordinated distributed supervisor has been synthesized for the CmosProtector. A new modeling
technique that results in a run-to-completion controller is used to reduce the state-space of the
supervisor. A comparison between the synthesized controller and the existing controller developed
using ASD shows that the latter has some inconsistencies in its specification. Optimizations are
done inconsistently, and not all state-based decisions are done by the CmosProtector. Therefore,
some of the gathered requirements are adapted to synthesize a more consistent behaving controller
compared to the existing controller. The resulting supervisor is verified by using the simulation
option of the tooling. By transforming the synthesized supervisor to a sequence-based specification,
the last error is found in the models that was not found earlier by simulation. This shows that
simulation is not satisfactory for functional verification and other options need to be researched.
However, it is estimated that a factor seven of reduction in unit tests can be established by using
supervisor synthesis instead of ASD.
A controller specified with ASD is error prone because it is easy to make specification errors and
inconsistencies, for example due to sloppy repetitive work and copying errors. Although ASD has
a built in model checker, not all of these errors are found as verification is limited. When a model
becomes larger, the sequence-based specification can also become difficult to read. Furthermore,
requirements can be specified at more places which reduces maintainability.
vi
Summary
A synthesized supervisor is highly maintainable, but it can be difficult to get the requirements
complete in the first place. To verify the synthesized supervisor during the iterative development
process, manual simulation is suggested. This, however, is time intensive. Furthermore, the
supervisor synthesis tooling gives the developer a lot of freedom in modeling and specifying
requirements. This gives a lot of ways to synthesize a particular controller, of which some are
more clear than other.
For developing a controller, supervisor synthesis and ASD have exactly the opposite starting
point. When using supervisor synthesis, the developer initially builds a maximum permissive
system model that is restricted by adding requirements. When using ASD, the initial controller
is empty and has to be specified completely by the developer. Both tools can produce the same
controller which makes them equivalent in the result but different in the approach.
In addition to synthesizing a supervisor, the requirements are also used to see if the existing ASD
model can be verified against those requirements using the supervisor synthesis tooling. Although
it is possible, the lack of a trace is when verification fails makes the supervisor synthesis tooling
unusable as verification tool. However, it does show that all requirements specified for synthesis
can be used to functionally verify ASD models.
Samenvatting (Dutch)
Omdat software steeds complexer wordt zijn bedrijven voortdurend op zoek naar verbeteringen
in hun software ontwikkeling traject. Daarnaast moet de software ook steeds sneller ontwikkeld
kunnen worden, terwijl de kwaliteit moet worden gehandhaafd. Deze trend geldt ook voor FEI
Company, een bedrijf dat geavanceerde elektronenmicroscopen produceert. Voor deze microscopen
is besturingssoftware nodig die binnen het bedrijf wordt ontwikkeld. Een recente wijziging in het
FEI software ontwikkelproces is de introductie van het model-based engineering pakket ASD suite
van het Nederlandse bedrijf Verum Software Technologies BV, die formele methoden introduceert
in het ontwikkelingsproces. Het voordeel van dit pakket is een snellere ontwikkelingstijd, lagere
kosten en een hogere kwaliteit van de ontwikkelde software.
Om te controleren of de gemaakte software correct is met betrekking tot de gespecificeerde eisen,
wordt deze momenteel functioneel geverifieerd met behulp van unittesten en handmatige controles.
Dit kost echter veel tijd en is foutgevoelig. Daarom onderzoekt FEI of formele methoden ook
kunnen worden gebruikt voor functionele verificatie. Supervisory control theory is een theorie
die het mogelijk maakt om automatisch een deel van de besturingssoftware (supervisor) te
synthetiseren. Hiervoor gebruikt het modellen van de systeem componenten en eisen in de vorm
van automaten of formele uitdrukkingen. Het voordeel van deze automatische synthese is dat er een
duidelijk verband is tussen de gespecificeerde eisen en de formele eisen die worden gebruikt als input
voor de synthese. Dit resulteert in een vermindering van het aantal benodigde unit- en handmatige
testen. Het doel van dit project is om te onderzoeken hoe het supervisor synthese pakket van de
Technische Universiteit Eindhoven, FEI Company kan helpen bij het ontwikkelingsproces van de
besturingssoftware voor hun elektronenmicroscopen.
Met behulp van een voorbeeld zijn de verschillen en overeenkomsten van het ASD pakket en
het supervisor synthese pakket besproken. De case study die gebruikt is voor dit project is de
CmosProtector: een software component die een zeer gevoelige camera in de elektronenmicroscoop
beschermt tegen een te hoge dosis elektronen. De eisen die aan deze software component worden
gesteld zijn verzameld door de documentatie te lezen, de unittesten te bestuderen, en door te
praten met ontwikkelaars.
Een coordinated distributed supervisor is gesynthetiseerd voor de CmosProtector.
Een
nieuwe modelleertechniek die resulteert in een run-to-completion controller is gebruikt om de
state-space van de supervisor te verkleinen. Wanneer de gesynthetiseerde controller en huidige
controller worden vergeleken, blijkt dat de laatste enkele inconsistenties in de specificatie heeft.
Optimalisaties zijn inconsequent gedaan, en niet alle state-based beslissingen worden gedaan door
de CmosProtector. Om een meer consistente controller te krijgen zijn enkele eisen aangepast. De
resulterende controller is geverifieerd door middel van de simulatie tool van het synthese pakket.
Ook is de supervisor omgezet naar een sequence-based specificatie zodat deze vergeleken kan
worden met de huidige controller. Na de omzetting is de laatste fout in de modellen gevonden
die onopgemerkt is gebleven tijdens the simulatie. Hieruit blijkt dat de simulatie van het
syntheseproces niet voldoende is en andere verificatie opties moeten worden onderzocht. Het
synthese proces heeft wel tot gevolg dat, in vergelijking met het huidige ASD model, het aantal
unit test benodigd voor verificatie met een factor zeven kan worden gereduceerd.
viii
Samenvatting (Dutch)
Een controller gemaakt met ASD blijkt foutgevoelig omdat er vaak een specificatie fout of
inconsistent gedrag gemodelleerd is, als gevolg van repeterend werk en kopieerfouten. De
ingebouwde model checker is beperkt en vindt niet al deze fouten. Wanneer een model groter
wordt, kan de sequence-based specificatie ook moeilijk leesbaar worden. Verder kunnen eisen
gespecificeerd worden op een of meerdere plaatsen in het model, dat voor onduidelijke software
kan zorgen die slecht te onderhouden is.
Een gesynthetiseerde supervisor is makkelijker te onderhouden, maar het initieel compleet krijgen
van de eisen is lastig. Om de gesynthetiseerde supervisor tijdens het iteratieve ontwikkelproces
te verifiëren, wordt handmatige simulatie voorgesteld wat echter tijdrovend is. Het supervisor
synthese pakket geeft de ontwikkelaar ook veel vrijheid in het modelleren en specificeren van
eisen. Dit geeft veel manieren om een bepaalde controller the synthetiseren, waarvan sommigen
duidelijker zijn dan andere.
Supervisor synthese en ASD hebben precies het tegenovergestelde uitgangspunt. Bij het gebruik
van supervisor synthese bouwt de ontwikkelaar in eerste instantie een maximaal tolerant systeem
model dat wordt beperkt door eisen toe te voegen. Met ASD is de controller initieel leeg en
moet deze volledig worden gespecificeerd door de ontwikkelaar. Beide pakketten kunnen dezelfde
controller produceren waardoor ze gelijk in het resultaat, maar verschillend in de aanpak.
Naast het synthetiseren van een supervisor zijn de eisen ook gebruikt om het bestaande ASD
model te verifiëren gebruik makende van het supervisor synthese pakket. Het blijkt dat alle
eerder gespecificeerde eisen kunnen worden gebruikt om het huidige ASD model functioneel te
verifiëren. Het probleem is het ontbreken van een trace wanneer de verificatie mislukt. Dit maakt
het supervisor synthese pakket momenteel onbruikbaar als verificatie programma. Het toont wel
aan dat functionele verificatie van ASD mogelijk is, en dat het een besparing zal opleveren in de
test tijd.
Contents
Assignment
Summary
Samenvatting (Dutch)
1 Introduction
iii
v
vii
3
1.1
Transmission electron microscope . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Evolution of the software development process at FEI . . . . . . . . . . . . . . . .
5
1.3
Project objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4
Project outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2 Model-based engineering
9
2.1
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
ASD tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Supervisory control theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3 Case study: the CmosProtector
19
3.1
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
CmosProtector specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4 Supervisor design for the CmosProtector
25
4.1
Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2
Modeling aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3
Creating a modular supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4
Supervisor synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5
Verifying the synthesized supervisor . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.6
Reduction in unit tests in comparison with ASD . . . . . . . . . . . . . . . . . . .
33
4.7
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2
Contents
5 Using supervisory control for functional verification of ASD models
35
5.1
Functional verification tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2
Verification using SuSyna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.3
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6 Conclusions and Recommendations
41
6.1
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.2
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Bibliography
45
A Models for CmosProtector
47
A.1 Safety module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
A.2 Updating the ProtectorDevices . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
A.3 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
A.4 ChangeMaxDose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Chapter 1
Introduction
Nowadays, products have become more and more complex because of demands from the market
and increasing competition between companies. As a result, the control software of these products
is also increasing in complexity. At the same time, companies want a shorter time-to-market to be
more competitive without compromising on the quality of the control software. These demands
could be fulfilled by increasing the number of people that work on the control software, but this
would result in higher development cost. Therefore, organizations are continuously seeking for
improvements in their control software development process.
This evolution also holds for FEI Company, which is a world leader in transmission and scanning
electron and ion microscopy for researchers, scientist and engineers [Com12]. A picture of its most
advanced microscope can be seen in Figure 1.1. These microscopes require control software to be
able to control the microscope and protect the highly sensitive devices. This software is developed
in house by a team of software engineers.
Figure 1.1: FEI Titan Transmission Electron Microscope
4
1.1
Chapter 1. Introduction
Transmission electron microscope
A microscope is an instrument to magnify objects that are too small to see. Most microscopes can
be classified as optical, charged particle (electron and ion) or scanning probe. Optical microscopes
use visible light and lenses to magnify objects as small as one micrometer. A scanning probe
microscope uses a very small needle to scan a sample and is capable of atomic scale resolution.
The electron microscope works according to the same principle as an optical microscope. It uses
an electron beam instead of light and has electromagnetic or electrostatic lenses to produce a
magnified image. Because electrons have smaller wave lengths than visible light, the resolution
of the magnified image is better. The electron microscope can obtain a resolution smaller than a
tenth of a nanometer. Two types of electron microscopes are SEM (Scanning Electron Microscope)
and TEM (Transmission Electron Microscope). In SEM, the amount of backscattered electrons
from a surface is measured, whereas in TEM the amount of electrons going through a sample is
measured. More information about electron microscopy can be found in [Ege05] and [Com10].
This project considers a transmission electron microscope which is explained in more detail in the
next section.
A schematic view of a TEM can be seen in Figure 1.2. The main part of it is the column
which is completely in vacuum, because the molecules in the air would diffuse the electron beam.
The electron beam is generated by an electron gun at the top of the column and is transformed
by electrostatic and electromagnetic lenses into an almost parallel beam at the specimen. The
specimen has to be very thin for the electrons to go through. After passing through the specimen,
the electron beam is focused by the objective lenses and the image of the specimen is magnified with
the projection lenses. Building an image of the specimen can be done by, for example, measuring
the amount of electrons that reach the viewing device or the angle in which the electrons got
scattered by the specimen.
Figure 1.2: Schematic view of a TEM
1.2. Evolution of the software development process at FEI
5
This beam of electrons is then projected onto a viewing device, such as a hinged fluorescent screen.
This is a screen that emits light when an electron impacts the screen. The image created by this
screen can be observed through a window in the column. When the operator needs to capture an
image of the specimen, the fluorescent screen pivots away and a CCD (Charge-Coupled Device)
camera captures the image. A CCD camera uses a scintillator material to make the electrons
visible. This introduces some loss of resolution in the resulting image and more electrons are
needed to create a sufficient image. When a specimen is sensitive for damage by the electron
beam, this is not a satisfactory solution.
Therefore, a CMOS (Complementary Metal Oxide Semiconductor) camera that can directly detect
electrons is nowadays used in some of the transmission electron microscopes. The problem of this
new camera is the high sensitivity for electrons. If the received dose of electrons is too high, the
camera will damage. To prevent this, a blanker is introduced in the microscope which can deflect
the electron beam with a magnetic field such that the beam does not hit the highly sensitive camera.
This deflecting of the beam is called blanking. Control software needs to be able to determine
when the blanker needs to blank the beam to protect the CMOS camera. To accomplish this, the
control software has to communicate with a number of other components of the TEM, such as the
column which controls the electron gun.
1.2
Evolution of the software development process at FEI
The control software for the electron microscopes is developed by engineers at FEI. The methods
and techniques used when developing the control software changes over time. The evolution of
the software development process at FEI Company can be seen in Figure 1.3. The different stages
are numbered and explained below:
1. Traditionally, software is coded informally which results in errors due to unclear or ambiguous
code. Most of the time, errors are not discovered until testing of the software. Manual testing,
however, is time intensive because many test scenarios have to be validated.
2. Automated tests (unit tests) are introduced which replace a part of the manual tests. These
automated tests can verify certain scenarios automatically and because these tests only have
to be coded once, the total development time decreases. The disadvantage of automated
testing is that the scenarios covered by the automated tests need to be maintained during
the development process, and that the automated tests cover only a part of the code.
3. The latest evolution at FEI is developing parts of the control software with model-based
engineering, which introduces formal models in the development process. According to
[BvdMFR11], these models have a couple of advantages over the traditional engineering
approach. First, they bring more structure in the design process of the system. Second, the
dynamical system behavior can be verified against the formal models. Finally, by simulating
and validating the models, errors in the model can be detected in an early stage of the design
process. Introducing model-based methods thus decreases coding time, automated testing
time and manual testing time.
The currently used model-based tooling at FEI is the commercially available software package
Analytical Software Design (ASD) from the Dutch company Verum Software Technologies
BV, see [BH]. This package combines formal methods developed by academics with current
programming methods. When a component is modeled, the built-in model generator uses
the process algebra CSP (Communicating Sequential Processes) of [Hoa85] to generate
mathematical models. The model checker FDR from Formal Systems Ltd. is used to analyze
and verify the model. It can, for example, check for deadlocks, live locks, race conditions,
and if the design model is deterministic. Finally, the ASD code generator generates code
6
Chapter 1. Introduction
Effort(not to scale)
1
2
3
2012
4
5
Manual
testing
Manual
Manual
Manual
testing
testing
Manual
testing
Automated
testing
testing
Automated
Automated
testing
Coding
Automated
testing
Functional
verification
ASD
Modeling
ASD
Modeling
Coding
Coding
testing
Supervisor
Synthesis
ASD
Modeling
Coding
Coding
Roadmap
Figure 1.3: FEI evolution software development process
automatically from the ASD specifications. The ASD package will be explained in more
detail in Section 2.2.
Advantages of the ASD platform are the faster development time, lower costs because errors
are found earlier in the process and higher quality because the design models are formally
verified. At the end of the design process, code is easily generated by the software.
The ASD tooling uses formal methods only to verify if the coded components are compliant. If
the coded software could also be functionally verified using formal methods, further reduction of
the total testing time is possible as can be seen on the roadmap.
4. FEI is currently investigating new functional verification techniques for ASD. In co-operation
with ESI (Embedded Systems Institute), FEI initiated a project in which Uppaal of [Uni12]
was applied to functionally verify an ASD model, as described in [DHvV12]. In this project
ASD models were manually converted to Uppaal models, and functional verification was
used to check the models. More research and an automatic conversion tool are needed to
have the advantage of both tools combined.
5. One step further than functional verification is controller synthesis. Model-based engineering
uses models in the development process and for functional verification requirements need to
be specified. When these requirements can be specified completely, they could be used
to automatically generate the required supervisor. Introducing this technique could, for
example, reduce the modeling effort and the testing time of the final controller.
The supervisory control theory of [RW87] is an academic theory providing a method to
synthesize the functional design of discrete event control components from one or more
1.3. Project objectives
7
models of the functional interface behavior and of the requirements. The system is modeled
as one or more untimed and discrete automata that represent uncontrolled behavior of the
system. Requirements restricting this uncontrolled behavior can be modeled as automata
or written down as formal expressions. The uncontrolled system models together with the
specified requirements are used to synthesize a supervisor which controls the system fulfilling
the requirements. This supervisor can be simulated to validate its behavior. If there is
unwanted behavior, the plant models or the requirements are not correct or incomplete.
Supervisory control theory is explained in more detail in Section 2.3.
Advantages of the supervisory control synthesis is that the resulting supervisor is behaving
according to the admissible behavior defined by the requirements. The requirements needed
for supervisor synthesis have a clear connection with the requirements stated in design notes.
Because the system can be modeled and synthesized modularly, changes to the system can
be done relatively fast and overview is maintained.
1.3
Project objectives
The purpose of this project is to investigate how supervisory control theory can help FEI company
in developing correct control software for its electron microscopes. To this end, the software that
protects the highly sensitive camera of an electron microscope from a too high dose of electrons is
chosen as a case study. With this case study, a number of questions need to be answered.
• Are the documented requirements complete?
For synthesizing supervisors, proper models of the plants and formal requirements are
needed. These requirements need to be made based on requirements documented in
documents made by FEI.
• Is supervisory control synthesis complementary with the manual design supported by ASD
or do these two methods have overlap?
What are the differences and similarities between both techniques?
• Is supervisory control synthesis useful for developing control software for electron
microscopes?
Can supervisory control synthesis contribute in any way to the development of the control
software of electron microscopes?
• When are there enough requirements in supervisory control synthesis?
Is it possible to know when the synthesized supervisor is complete and correct?
• Are only state-based requirements enough for supervisor synthesis?
Can we have a set of complete, formal requirements that can be understood by system and
software developers?
• Can supervisory control theory be used for functional verification of ASD models?
1.4
Project outline
In Chapter 2, the software package ASD and the supervisor synthesis tooling are explained in more
detail and demonstrated with a small example. Chapter 3 presents the case study of this project.
The components involved are described and the system architecture is explained. Finally, the
chapter describes which specifications over the components need to be enforced by the controller.
8
Chapter 1. Introduction
In Chapter 4, a synthesis method is used to provide a supervisor for the case study. The chapter
describes the solutions used to overcome the problems encountered during the supervisor design
process. For successful synthesis, design choices are made and some special modeling techniques
are used. To be able to synthesize modular supervisors, requirements are divided into groups.
Two verification techniques used during the synthesis process are explained and the specification
of the resulting supervisor is presented. By counting the unit tests not needed anymore when
using supervisor synthesis the advantage over ASD is quantified. The chapter concludes with a
small discussion about the advantages and disadvantages of both supervisor synthesis tooling and
ASD.
A feasibility research on using supervisor synthesis tooling for verification is discussed in Chapter
5. First, an idea is proposed and some of the problems encountered are explained and solved.
Next, the possibilities of the tooling are discussed and a comparison with a currently available
formal verification tool is done.
The report concludes with conclusions and recommendations for further research which can be
found in Chapter 6.
Chapter 2
Model-based engineering
This chapter goes into more detail on both model-based engineering techniques introduced in
Chapter 1, namely the software package ASD and the supervisory control synthesis tooling. Both
engineering tools are explained with a simple case study in the field of transmission electron
microscopes.
2.1
Example
The example case study consists of a simplified version of the control software that protects the
CMOS camera in a electron microscope from a too high electron dose. In this example, only the
column which contains the electron gun and the blanker that protects the highly sensitive camera
of a microscope are considered and can schematically be seen in Figure 2.1. The only safety
requirement for this system is that the column is only allowed to activate the electron gun if the
blanker is blanked. The controller that controls this system satisfying the requirement has to be
built.
Column
Controller
Legend
Software
component
Hardware
component
Blanker
Figure 2.1: Example case study
The column contains an electron gun that can be activated by an external trigger. Before
activating the electron gun, the column sends an event DoseWillGoHigh to the controller. When
the controller returns an empty reply, a void reply, the column knows it can activate the column1 .
1 Due to the historic architecture of the control software, a call cannot be blocked but can only be delayed by
the controller
10
Chapter 2. Model-based engineering
When the column deactivates the electron transmitter, an event DoseWillGoLow is sent to the
controller and will be again replied with a void reply. The controller can control the blanker by
sending the event SetForcedBlankOn to blank the beam and SetForcedBlankOff to unblank the
beam.
In the next two sections, a general introduction to both modeling tools are given with for each
tool a possible solution for the example case study.
2.2
ASD tooling
Modeling in ASD requires a model of the functional interface behavior and a model of the functional
design of a component. Both models are specified as a Sequence-Based Specification(SBS). The
SBS forces the user to specify the sequence of actions that need to be executed after each trigger
at each state. This approach ensures a complete system and each sequence of triggers map only
to one set of actions.
The interface model is the abstraction of the system components implementation. It consists of
externally visible system behavior of the component, independent of any specific implementation.
It shows what a component does under every circumstance but not how the component
accomplishes it. Each component has his own interface model. The design model describes a
complete implementation of the behavior described by its interface model. It covers the interaction
of the component with its clients and its servers. A hierarchical decomposition is possible with
the use of sub machines within a design model to be able to handle more complex designs.
Between components boundaries, information is sent in the form of triggers and actions. A trigger
is either a call event coming from a client, a reply event coming from a server or a notification
event coming from a server. An action can be a call event sent to the server, a reply event sent
to a client or a notification event that is sent to the client. Notifications can occur unsolicited: at
any time. Call and reply events can be synchronous or asynchronous. Synchronous means that
the client waits for a void reply and is blocked during this waiting time. Asynchronous means that
the client can work concurrently while waiting for a reply from another component.
Component boundary
Column
Service
Column
Component
Legend
Interface
model
Design model
Blanker
Service
Blanker
Component
Figure 2.2: ASD component design
2.2. ASD tooling
11
Implementation of example case study with ASD
Now, the example is modeled with the ASD software. A layout of how the system is built is shown
in Figure 2.2. The controller that has to be built to be able to protect the camera, is in ASD the
design model over the column. The blanker is a device that can be controlled to achieve this goal.
Therefore, the blanker is considered as a server of the column and only the interface model of this
component is needed. The component boundary of the column thus includes the interface model
of the blanker but excludes the design model of the blanker.
First, the interface client of the blanker is made and shown in Figure 2.3. The only two triggers
that the blanker can receive are the synchronous events SetForceBlankOn and SetForceBlankOff.
For each trigger at each state the sequence of actions that need to be performed have to be
inserted and to which state the interface model has to go to. If an event is not allowed, the Illegal
action is inserted which means that this event is not allowed to happen in that state. Next, the
interface model of the column is built and can be seen in Figure 2.4. The column has two triggers:
DoseWillGoHigh and DoseWillGoLow.
Figure 2.3: Interface model of the Blanker in ASD
Figure 2.4: Interface model of the DoseProtector in ASD
Now the interface models of the column and its server blanker are ready, the design model of
the column can be built using these two interfaces. This design model has to be built with the
safety requirement in mind. Initially, the design model is in its initial state DoseLow. After
a DoseWillGoHigh trigger, the safety requirement states that the blanker has to be enabled.
Therefore, the first action is to send a SetForceBlankOn event to the blanker. As soon as
the blanker sends a void reply back, the design model knows that the blanker is blanking
the beam. Then permission to the client can be sent by using the void reply as reaction on
the DoseWillGoHigh trigger and the design model can advance to the DoseHigh state. The
SetForceBlankOff event is in the initial state still illegal, as the design model is an implementation
of the interface model of the column.
In DoseHigh, the DoseWillGoHigh trigger is illegal. When the DoseWillGoLow trigger occurs,
the controller knows the electron beam is disabled. Although it is not explicitly stated in the
requirement, disabling the blanker in this case is preferable for usability of the system. Therefore,
the action SetForceBlankOff is sent to the blanker. After the void reply from the blanker, a void
12
Chapter 2. Model-based engineering
reply can be sent back to the client and the DoseProtector can advance to DoseLow. The design
model of the DoseProtector can be seen in Figure 2.5.
Figure 2.5: Design model of the DoseProtector in ASD
When all the models are ready, they can be verified by the ModelChecker. When this verification
completes successfully, ASD can automatically generate code of the models to use in software.
From this example case study some advantages and disadvantages of ASD are revealed. One of
the advantages is that the ASD platform uses a sequence-based specification which forces the user
to think about which action has to be done on all triggers possible in each state which ensures
completeness of the created design. Because actions are coupled to triggers in a sequenced based
specification, overview is comfortable for small systems. Code can be generated directly from the
verified model giving code that has completely identical behavior as the designed model.
When the models become larger it will be more difficult to maintain overview of the models
designed with ASD, particularly when a patch has to be done in a later stage. In that case, all
states have to be checked by hand to verify whether the patch changes anything in that state. If
one specific action or sequence of actions occurs more often, these occurrences could be handled by
one sub-state machine. Some of the design decisions can already be incorporated in the interface
model. The advantage of this approach is that components using this interface model can be
checked more thoroughly for modeling errors. The disadvantage is that a change of a requirement
could require a remodeling of both the interface model and design model. Furthermore, the ASD
ModelChecker performs only a verification of the design model against its interface model. The
resulting behavior could therefore still not be desirable.
2.3
Supervisory control theory
Supervisory control theory provides a method to synthesize supervisors for discrete-event systems.
It is based on feedback control on the observed events in the system controlled. There are two
frameworks for supervisory control currently available: the event-based framework of [RW87] and
the state-based framework of [MW06]. Event-based supervisory does both support monolithic
and modular supervisory whereas state-based supervisory currently only support monolithic
supervisors. Because in an industrial setting projects can grow fast, a modular composed
supervisor is preferable. Therefore, the event-based tooling SuSyNA, described in [vRH12], is used.
This is a collection of programs to manipulate automata and synthesize supervisors. Input for this
tooling are automata that define the behavior of the system under control and automata that define
requirements over the system. Although the tooling is event-based, state-based requirements can
be used that can automatically be transformed to event-based requirements before synthesizing
the supervisor.
2.3. Supervisory control theory
13
Automata
An automaton is a state-transition diagram that represents a language of a discrete-event system
and contains states and events. From each state, zero or more events are possible that can lead
to another state or self-loop back to the same state. An automaton has one initial state and one
or more marker states. The marker states are states that have a special meaning, for instance the
completion of a task or an emergency state. If all states in an automaton have equal importance,
all states can be made marked. The marker states are used to verify whether an automaton is
non-blocking. An automaton is non-blocking if all reachable states are co-reachable. A state is
reachable if it can be reached from the initial state and co-reachable if a marker state can be
reached from that state. In practice, not all events of the system under control are observable.
Therefore, events in automata can be unobservable. An unobservable event cannot be noticed by
the supervisor, and thus no control decisions can be made based on these events. This distinction
is not used in this project, so all events mentioned in this report are observable events.
Depending on the observations, events can be enabled or disabled by the supervisor. Supervisory
control theory distinguishes two types of events: controllable events and uncontrollable events.
Controllable events are the events that can be controlled by the supervisor and can be compared
with the action events in ASD. This can, for example, be the event that activates or deactivates
the blanker or a notification to the user. The second kind of events are the uncontrollable events
which can just occur depending on the state of the system under control. Typically, these events
are a failure of a machine, user input or sensor output and can be compared with the triggers in
ASD.
An example of an automaton can be seen in Figure 2.6. The initial state is labeled with a sourceless
incoming arrow and marker states are filled points. Transition labels are italic and controllable
events are denoted by solid edges and uncontrollable events are denoted by dashed edges. State
labels are bold. This notation is used in the remainder of this report.
Activate
state 1
state 2
is Activated
Figure 2.6: Example automaton
Plants
The uncontrolled system can now be modeled with one or multiple finite automata. In supervisory
control theory these system models are called the plants. The parallel composition of all plants
results in the complete uncontrolled modeled system behavior. In this composition, events shared
by automata are synchronized. Thus a shared event can only happen when it is allowed in all
automata that have this event in this alphabet.
Requirements
The requirements for this project can be specified in two ways. The first one is to describe a
specification as an automaton that can directly be used as an event-based requirement for the
SuSyNA tooling. Comparable to the plants, the requirements have an initial state and one or
more marker states. Requirements specified as automata are particularly useful when specifications
demand a certain order of events. In that case an automaton can be built that only allows those
events in that specific order.
14
Chapter 2. Model-based engineering
Another way to specify the requirements is to use logical expressions over states as described in
[JMvB+ 09]. The expressions that can be used are briefly explained below.
• The first expression is the state formula (SF). The operators (Op) allowed in this expression
are conjuction ∧, disjunction ∨ or implication ⇒. Let Pr be the state predicate s ↓, then
the state-formula is defined as follows:
SF ::== P r | ¬ SF | SF Op SF
(2.1)
This definition allows formulating logical expressions with state predicates.
• The second definition is the state-transition exclusions which specify that a set of events E
must be disabled by the supervisor when the plant is in a certain state.
SF ⇒ 9 E
(2.2)
• The last definition is the generalized transition-state formula which only allow a certain set
of events E if the state-formula is valid.
→ E ⇒ SF
(2.3)
Prior to synthesis with SuSyNA, these requirements can automatically be transformed to
requirement automata.
Supervisor synthesis
The plants and the requirements can now be used to synthesize correct and optimal supervisor.
A correct supervisor makes sure the system behaves according to the requirements specified,
is non-blocking, and does not disable uncontrollable events allowed in the plant. An optimal
supervisor does not restrict more of the systems behavior than necessary to satisfy the
requirements.
A supervisor disables controllable events of the system under control to match the behavior desired
by the requirements. This is done by placing the synthesized supervisor in parallel with the plants.
Requirements could also demand to block uncontrollable events. This can only be achieved by
blocking the controllable events that lead to states that enable any uncontrollable event that needs
to be disabled. The controllability property guarantees that there is no sequence of events that
leads to a state where the system can trigger an uncontrollable event while the supervisor blocks
this event. Specifying conflicting or too strict requirements will results in a empty supervisor or a
supervisor that blocks more actions than necessary.
Originally, the event-based framework could only synthesize monolithic supervisors using all plant
and requirements at once. A disadvantage of this monolithic approach is that the number of
states of the supervisor grows fast. This causes problems in computational power required, memory
required, and the overview of the system is lost. Therefore, several distributed synthesis techniques
are developed resulting in less complex supervisor synthesis because local supervisors can be
synthesized. This also creates more flexibility in the system because a small change in the system
only requires that a few local supervisors have to be updated. The individual modules contain less
requirements and plant models which makes them more clear and each module can be simulated
separately.
Disadvantage of a modular supervisor is that each supervisor controls only a part of the whole
plant. Because each supervisor acts independently on local information, they could come into
conflict at the global level resulting in, for example, deadlocks. Whether a supervisor is non
conflicting with its plant can be verified with a computationally expensive nonconflicting test.
2.3. Supervisory control theory
15
This test can be avoided by smart modeling techniques, for example by adding coordinators or
using a distributed method.
There are a couple of distributed synthesis techniques like the hierarchical approach of [Won10],
hierarchical interface approach of [LLW05] and the distribute approach of [ST06]. Two distributed
approaches are discussed now: the coordinated distributed approach of [SvSRH10], and the
aggregative distributed approach of [SvSR10a].
1. Figure 2.7 illustrates the coordinated distributed synthesis approach. The system is divided
into several modules. For each module, automata of the components and requirements over
those components are made. With these plant and requirement models, a local supervisor
is built. The product of all those local supervisors result in the final supervisor. This
supervisor need to be verified to check whether it is nonconflicting with the complete system;
all the automata of all modules together. When the supervisor is conflicting with the plants,
a coordinator can be created. The coordinator is created by taking the product of the
abstractions of each local supervisor with its plant. An abstraction simplifies an automaton
by removing specified transitions and only needs to contain the events that are important in
any other local supervisor. From these abstractions a coordinator can be synthesized with
optional higher level requirements. The product of all supervisors and the coordinator then
gives the final supervisor which is now nonconflicting.
Coordinator
Abstraction1 × ... × Abstractionn × Reqm
Abstraction1
P lants1 , Req1
Supervisor1
. . .
. . .
Abstractionn
P lantsn , Reqn
Supervisorn
Figure 2.7: Synthesis of coordinated distributed supervisor
The difficulty of the coordinated distributed approach, is the correct choice of the abstraction
alphabet. If only a couple of transitions are removed, the abstraction is still a large
automaton. When too many transitions are removed, transitions needed for synthesis later
on are lost.
2. The aggregative distributed approach is graphically shown in Figure 2.8. Again, the system
is divided in modules. First, a local supervisor is synthesized of one of those modules using
automata and requirements. From the product of the resulting supervisor and the used
automata, an abstraction is made over the shared events. Now, the next local supervisor is
synthesized using the local automata, local requirements, and the abstraction made before.
This supervisor is now nonblocking with the product of all the plant automata used thusfar.
When all modular supervisors are synthesized, the product of all supervisors gives the overall
supervisor which is now non blocking by design. The difficulty with this approach is to
determine the order of synthesis such that a result is obtained.
16
Chapter 2. Model-based engineering
. . .
Abstraction1
P lants1 , Req1
. . .
Supervisor1
. . .
P lantsn × Abstractionn−1 , Reqn
Supervisorn
Figure 2.8: Synthesis of aggregative distributed supervisor
Synthesizing the example case study
First, the blanker model is built and can be seen in Figure 2.9. Initially, the blanker is not activated
and is in the ForcedBlankOff state. When it receives a SetForcedBlankOn event, it will advance
to the state ForcedBlankOn. From here it can be deactivated by sending a SetForcedBlankOff
event to the blanker on which it will go back to its initial state.
ForcedBlankOff
SetForcedBlankOn
ForcedBlankOn
SetForcedBlankOff
Figure 2.9: Blanker plant
Next, the column is modeled and can be seen in Figure 2.10. Initially, the column is in the
DoseLow state. The only outgoing event is the uncontrollable event DoseWillGoHigh to the
state ReqDoseHigh. The resulting supervisor has to give the reply DoseWillGoHigh VoidReply
before the column will arrive in the state DoseHigh. From here, the uncontrollable event
DoseWillGoLow can happen, which has to be replied on with a DoseWillGoLow VoidReply event.
After this event, the column is back in its initial state.
DoseWillGoHigh
ReqDoseHigh
DoseLow
DoseWillGoLow VoidReply
DoseWillGoHigh VoidReply
ReqDoseLow
DoseHigh
DoseWillGoLow
Figure 2.10: Column plant
Now the models are made, the requirements needed for the supervisor synthesis can be formulated.
Both automata requirements and logical expressions could be used, but for this example only
logical expressions are sufficient.
• The safety requirement stated that when the dose is high, the blanker should always be
activated.
DoseHigh ↓ ⇒ ForcedBlankOn ↓
(2.4)
2.3. Supervisory control theory
17
• For usability issues, another requirement has to be added to make sure the beam is not
blanked when the dose is low.
DoseLow ↓ ⇒ ForcedBlankOff ↓
(2.5)
• Simulation shows that when the column is in the ReqDoseHigh or ReqDoseLow state,
the blanker can be switched on and off an infinite number of times. This is because the
synthesized supervisor is maximal permissive controller and the used requirements do not
restrict this behavior. To avoid this, two extra requirements are added that define when the
blanker is allowed to switch on or off.
→ { SetForcedBlankOn } ⇒ ReqDoseHigh ↓
(2.6)
→ { SetForcedBlankOff } ⇒ ReqDoseLow ↓
(2.7)
Because these requirements are normally not specified in a design note, a system designer
has to add these requirements where needed. These kind of errors are likely to show up in
other supervisors and will influence the behavior of the supervisor. This can be seen as a
disadvantage of supervisor synthesis, because it is difficult to see when the requirements are
complete.
With these two models and four requirements, a correct and optimal supervisor can be synthesized
using the SuSyNA tooling. The automaton of this supervisor can be seen in Figure 2.11 and indeed
shows the intended behavior.
DoseWillGoHigh SetForcedBlankOn
DoseWillGoLow VoidReply
DoseWillGoHigh VoidReply
SetForcedBlankOff DoseWillGoLow
Figure 2.11: Synthesized supervisor
18
Chapter 2. Model-based engineering
Chapter 3
Case study: the CmosProtector
In the previous chapter, the ASD tool and the supervisory control synthesis tool SuSyNA are
explained using a simple example. In this chapter, the case study used in this project is explained.
The case study is related to the development of a part of the control software for the TEM
microscopes of FEI Company. Currently, this control software is built with the ASD tooling.
Before a supervisor can be synthesized based on supervisory control theory, the system has to be
analyzed and then formally modeled. In this chapter, an introduction to the case study is given
by describing all components involved and the system architecture is explained. At the end, the
specifications are formulated.
A schematic view of a TEM can be seen in Figure 3.1(a). The part considered is the control
software, called the CmosProtector, that protects the CMOS camera(the image recording system)
from a too high electron dose by controlling protection hardware of the TEM. The CmosProtector
is pro-active and makes sure all the components interact in such a way that all specifications are
satisfied. Pro-active means, in this context, influencing the system in advance of a future situation.
This can be done because the components involved sent an event to the CmosProtector when it
is going to be adjusted and wait for a reply of the CmosProtector before they continue. Due to
historical built up of the TEM software, it is not possible to simply abort a system change when
it is not safe according to the system specification. The only influence the CmosProtector has, is
delay this reply and thus delay the system change.
3.1
Components
For this case study, the for the CmosProtector relevant parts of a TEM can be seen at the right
hand side of Figure 3.1(b). At the top of the column the gun is positioned that generates the
electron beam. When a user changes the electron dose of the gun, the column sends the target
dose level to the CmosProtector. When the CmosProtector is ready with preparing the system for
the new dose, it sends a reply back and the gun can start alter its dose. During this altering, a
user could could request another dose. In that case, the CmosProtector receives another request
with a new target dose level. Because it can happen that due to circumstances this target dose
level is not exactly reached, the column sends a message to the protector to communicate the final
dose level when the latest requested dose level is stabilized.
Below the magnetic lenses and the specimen holder a couple of devices can be inserted on certain
positions in the column. Devices that block the electron beam are called shielding devices, for
example the fluorescent screen. There can be more than one shielding device inserted. When a
shielding device is inserted, it sends its name and its position in the column to the CmosProtector.
Inserting a shielding device will never cause a decrease of the safety and therefore it can be inserted
20
Chapter 3. Case study: the CmosProtector
(a) Schematic view of a TEM
(b) Components relevant for this case study
Figure 3.1: Case study TEM
without a control action from the CmosProtector. When the shielding device needs to be removed,
the system could transit into an unsafe situation. This can for example happen when a CMOS
camera is inserted just below the shielding device, and the electron dose can damage the camera.
When removing the shielding device, the sensitive camera will be exposed to an unsafe dose of
electrons. Therefore, a shielding device can only be removed after a reply from the CmosProtector.
Another kind of device that can be inserted below the specimen holder is a highly sensitive camera,
for example the CMOS camera. Sensitive devices are used for viewing the sample on a computer
or making a digital recording. When a sensitive device has to be inserted, the CmosProtector
receives the maximum dose it can handle, the position in the column and its name. After a reply
from the CmosProtector, the insertion can continue.
Some sensitive devices can act as shielding devices for other sensitive devices. For example, two
sensitive devices can be inserted from which the top one can handle a higher dose than the bottom
one. If the top device blocks the electron beam from the devices lower in the column, it can act as
a shielding device. If the dose level is between the maximal allowed dose level of each of the two
sensitive devices, the top sensitive device acts as a shielding device for the bottom sensitive device.
If a sensitive device also acts as a shielding device, it will register itself to the CmosProtector being
both a sensitive and a shielding device.
The environment safety for a sensitive device inserted is thus influenced by a sensitive or a shielding
device insertion or retraction or a change of the dose by the column. From now on, the sensitive
devices, shielding devices and column are called the ProtectorDevices. Currently, the only way
the CmosProtector can make an unsafe environment safe is using a blanker situated below the
specimen holder. The blanker is a device that can deflect the electron beam coming from the
column such that a sensitive device below it does not receive a too high electron dose. A schematic
view of this blanking can be seen in Figure 3.2. Whenever the CmosProtector decides the column
state would become not safe, it will perform a forced blank. The blanker will stay closed until
the CmosProtector deactivates the blanker. The CmosProtector deactivates the blanker when the
electron dose is safe for the sensitive devices.
A safe environment for an inserted sensitive device depends on the maximum dose it can receive,
3.1. Components
21
(a) Blanker disabled
(b) Blanker enabled
Figure 3.2: BlankerShutter
its position, other sensitive devices inserted and its position. Also, as discussed earlier, a sensitive
device can act as a shielding device for a sensitive device on a lower position. There can also
be more than one shielding or sensitive device inserted. Because all these system variables are
parametrized, it is difficult to implement this decision in a discrete-event controller. Therefore, the
safety calculation based on these factors is done by an external (foreign) software component called
the SafetyList. This SafetyList compares the actual state of the system with a list of predefined
safe and unsafe situations and determines the exposure safety of the sensitive devices based on
this. Furthermore, users have to be able to poll for the current state of the CmosProtector, and
when the state changes the CmosProtector should send a notification to the user. The complete
layout of the interaction of the control software with its environment can be seen in Figure 3.3.
Figure 3.3: CmosProtector connections
22
Chapter 3. Case study: the CmosProtector
3.2
CmosProtector specification
Some of the specifications are documented in internal design notes of FEI Company concerning
the design aspects of the CmosProtector. Because this note is outdated, conversations have been
conducted with employees of FEI to verify and complete the specifications documented. Another
source from which specifications can be obtained, are the unit tests. Unit tests are tests that
verify a part of a source code made by developers. These tests include all special cases that can
happen and the response a controller should give. For the initialization and activation part, the
existing ASD model is used as source because there is no documentation about these operations.
From these sources, the specifications for the CmosProtector can be determined.
The more general specifications of the CmosProtector are summed up here. They state which
control decisions can be made by the CmosProtector based on the current system configuration.
1. If a sensitive device is going to be exposed to a dose which can damage the device, the
CmosProtector should to blank the beam.
2. When the electron dose is safe for the sensitive device exposed, the blanker should be
deactivated such that a user can use the microscope.
3. When no sensitive device is inserted, the exposure is obviously always safe for the sensitive
devices. This means that the beam should not be blanked in this case, even when the
environment is unsafe.
4. When the column is changing the dose of the electron beam, the beam is always considered
unsafe for the sensitive devices exposed to the beam. Although the start and end level of
the dose level could be safe, during the change the dose level could be temporarily too high
due to changing focus by changing the lenses.
5. Inserting or retracting a sensitive or shielding device can change the safety of the system
environment.
6. Activating and deactivating the blanker can fail because of a malfunction in the blanker.
When this happens,it still sends a reply to the ProtectorDevices, thus an unsafe situation
could possibly happen. From this state, normal operation can continue, but when the
CmosProtector has to change its state, the blanker should always be controlled with an
enable/disable action. If this action succeeds, the current state of the blanker is known
again and system operation can continue. If it fails again, the CmosProtector will be back
in the error state.
7. Before the system can terminate or deactivate, it has to make sure the blanker is deactivated
even when the electron beam is unsafe for an exposed sensitive device. This is because the
CmosProtector is a security layer on the microscope, but the microscope should also work
without the CmosProtector. In that case it is up to the user to determine what is safe or
unsafe to do with the electron microscope and its ProtectorDevices.
When a control decision has to be made based on parameters, the CmosProtector has to consult
the SafetyList. The following specifications state how to handle this consult.
8. After a change of one of the ProtectorDevices parameters, the changed parameters have to
be sent to the SafetyList.
9. When a parameter of the SafetyList has been updated, the CmosProtector can consult
the SafetyList to see whether the upcoming exposure conditions of the system are safe or
unsafe for the sensitive devices. This has to be done before it sends a reply back to the
ProtectorDevices. Based on the response coming from the SafetyList, the CmosProtector
can decide to activate or deactivate the blanker.
3.2. CmosProtector specification
23
The CmosProtector has to interact with the user and the operating system environment in the
form of notifications and replies on polls. The following specifications state the interactions.
10. The system has to be able to initialize and terminate the CmosProtector for an electron
microscope. This is the creation of the controller in the operating system environment.
11. When initialized, the user has to be able to activate and deactivate the controller for testing
purposes to see whether the CmosProtector has influence on the real system.
12. The user wants to test if changing the maximal dose level of a certain sensitive device inserted
has consequences for the system.
13. The user wants information about the current dose of the electron beam which is only allowed
after initialization.
14. The user has to be able to poll for the actual state of the microscope when idle. The idle
states of the CmosProtector can be deactivated(Off), or activated and either blanking the
beam(ForcedBlankOn), not blanking the beam(SafeExposure), or in a error state in case the
blanker fails(Error).
15. Whenever the CmosProtector changes from one state to another it also has to notify the
user automatically. The same states as used for specification 14 can be used.
24
Chapter 3. Case study: the CmosProtector
Chapter 4
Supervisor design for the
CmosProtector
In the previous chapter, the case study for this project is explained. In this chapter, the supervisor
synthesis tooling is used to synthesize a supervisor. As shown in Chapter 1, this tooling can
possibly reduce the modeling effort and testing time of the resulting controller and can help FEI
in reducing the total development time. This chapter highlights the lessons learned during the
supervisor design process. The complete models and the explanation of these models can be found
in Appendix A.
4.1
Design choices
The existing CmosProtector is built by a team of engineers who made a couple of design decisions.
Two of these decisions turned out to be inconsistent and illogical, and for the supervisor synthesis
these design decisions are adapted. As these adapted design choices do change the behavior of the
CmosProtector, they are explained here.
4.1.1
Building a robust controller
When an event is coming from one of the ProtectorDevices, the CmosProtector has to forward this
reply to the SafetyList. Based on the response from the SafetyList, the CmosProtector influences
the system in such way that the system is prepared for the new situation. It is not always necessary
to consult the SafetyList, for example because inserting a shielding device in a safe exposure state
will never make the system unsafe. With ASD, this can be specified easily because for every
state the actions following an event can be specified. However, for the current CmosProtector this
optimization is not applied consistent as in some cases the SafetyList is still unnecessary consulted.
Besides the possible inconsistent usage, a disadvantage of this approach is that knowledge from
the SafetyList is copied to the CmosProtector which can introduce copying errors. It also reduces
the maintainability because a change in the specification requires both the SafetyList and the
CmosProtector to be adapted.
Modeling exceptions with supervisory control theory is rather difficult because requirements are
specified as automata or logical expressions which makes it easier to specify general cases then to
specify exceptions. If exceptions have to be modeled, extra automata need to be designed that
specify when the SafetyList needs to be consulted. Because consulting the SafetyList is not a
26
Chapter 4. Supervisor design for the CmosProtector
costly operation and the SafetyList is assumed to be correct, the CmosProtector in this project is
designed such that it always checks the SafetyList after a change of one of the ProtectorDevices.
The only exception is when the CmosProtector is not activated yet. The resulting requirement
needed to model this exception can be seen in Figure 4.1. State CheckDose Needed has a
CheckDose event back to the initial state, while CheckDose NotNeeded immediately gives a
void reply back. The logical expressions (4.1) now always block one of the two outermost states,
based on whether the system is activated according to the LifeCycle automaton of Appendix A.3.1.
ProtectorDevices VoidReply SafetyList events
CheckDose NotNeeded
CheckDose Needed
SafetyList events
CheckDose
ProtectorDevices VoidReply
Figure 4.1: CheckDose requirement
CheckDose Needed ↓ ⇒ Activated ↓
CheckDose NotNeeded ↓ ⇒ ¬ Activated ↓
4.1.2
(4.1)
Separate state-based decisions and parameter decisions
The supervisor synthesis tooling cannot cope with parameters. Therefore, only the transition
names without the parameters are used during the supervisory synthesis. After the synthesis, the
original parameters can again be added to the supervisor. This can be done because all decisions
based on parameters are done by the SafetyList and decisions based on state information are done
by the CmosProtector.
However, the existing CmosProtector designed with ASD is not consistent in this approach.
Specification 4 states that the electron beam is always unsafe when the column is changing the dose
level and a sensitive device is directly exposed to the beam. The existing CmosProtector handles
this by the SafetyList. When the column wants to change the electron dose and a sensitive device
would be directly exposed, the SafetyList will always mark the system environment unsafe till
the column has settled its final dose. But in that case the SafetyList keeps track of the state of
the column, namely whether it is altering the dose or not. As this is state-based behavior, the
CmosProtector should handle this part.
Therefore, in this project this specification is handled by a combination of the SafetyList and the
CmosProtector. To be able to correctly determine whether the beam should be blanked after a
prepare call from the column, the SafetyList now has to give one of the following three replies
• Unsafe exposure
• Safe exposure because there is a shielding device in front of the sensitive device
• Safe exposure because the preparation dose is low
In the first and the latter case the beam should be blanked, while in the second case the beam
should not be blanked because the sensitive device is protected by the shielding device.
When the CmosProtector is created in its operating environment, it already processes changes of
the system. It now also has to keep track of whether the column is preparing a new dose level or
not. If, after activation, the system is deactivated this state information of the column has to be
saved, while after termination the state information of the column can be discarded.
4.2. Modeling aspects
4.2
27
Modeling aspects
During modeling of the components of the CmosProtector, some techniques are used to simplify
the models. They are covered in this section.
4.2.1
Building a run-to-completion controller
The existing CmosProtector is a run-to-completion controller. A run-to-completion controller
executes the sequence of controllable events after an uncontrollable event before a new
uncontrollable event is processed. This is different from the maximally permissive supervisors
generated by supervisor synthesis which can have a huge amount of different paths. The problem
of the resulting large state space is, besides calculation time, the problem of checking whether the
supervisor has the right behavior in all possible paths.
In this project, all unsolicited uncontrollable input events wait for a reply from the CmosProtector.
All controllable actions following such uncontrollable events happen before this reply. This
gives, with smart design choices of the plant automata, the opportunity to generate a
run-to-completion controller with supervisor synthesis. The advantage of modeling the controller
as a run-to-completion system are smaller supervisors, reduced supervisor synthesis time, and
the more clear simulation. Another advantage for this project is that building the synthesized
controller as a run-to-completion controller makes it easy to compare with the existing ASD model
and when the synthesized supervisor is transformed to an ASD model code can be generated by
ASD.
Building a run-to-completion controller can only be done with the assumption that no
uncontrollable events are arriving when an uncontrollable event is being processed. Therefore,
it is assumed that there is a buffer in front of the supervisor implementation that collects all
uncontrollable events. When a reply is given on a previous uncontrollable event, the controller
now can check if there is another uncontrollable event in the buffer that needs to be processed. In
modeling terms, this means that all input events have to be in one automaton. When one of these
events happens, all other events cannot happen until a reply is given back to that uncontrollable
event. A small, not complete, example of it can be seen in Figure 4.2.
ProtectorDevices
ProtectorDevices VoidReply
Activate
Prepare
Settled
RefreshMaxDose
Activate
RefreshMaxDose
Initial
Activate OK
Activate NotAllowed
RefreshMaxDose VoidReply
Figure 4.2: Example input automaton for run-to-completion controller
This input automaton now guarantees that only one input event is processed at a time. As the
replies are different for each input event, a state is introduced for each type of reply. The complete
input automaton used for the CmosProtector can be found in Appendix A.2.1.
To avoid state-space explosion it is preferable that the controllable actions are only possible in
one particular order for each case. If this sequence is not specified for a case, a smart choice on
the order of events has to be made and modeled with an extra requirement automaton.
28
4.2.2
Chapter 4. Supervisor design for the CmosProtector
Modeling observers
The actual state of a component has to be known to be able to specify certain requirements. An
example is the column, of which the CmosProtector wants to know whether it is changing the
electron dose (Preparing) or not (Settled). As the designed input automaton does not keep track
of the last known state of a component, the actual state of the column is not known.
As discussed in [FvdMFSR], it is therefore easier to create an observer such that logical expressions
are easier to link to the actual state. The observer used for the column can be seen in Figure
4.3. Because multiple Prepare events can happen in a row, this event is self-looped in the
Column Unsafe state. This automata now has a clear distinction between a safe and an unsafe
column and this information can be used for logical expressions. It is important to realize that
every plant automaton has to be able to terminate such that no state information is saved by the
supervisor after termination. Therefore, each state of a plant, including the initial state itself,
needs a Terminate OK back to its initial state.
Terminate OK
Prepare
Prepare
Column Safe
Column Unsafe
Settled
Terminate OK
Figure 4.3: Column automaton
The CmosProtector has to be able to send notifications to the user when the system changes state
and be able to reply on a status request from a user. These states are based on the combination
of states of the components. Logical expressions could be specified based on these components,
but it is more convenient to built an observer that keeps track of the system state. This makes
the logical expressions readable and allows to build modular supervisors because requirements can
now be specified over a small subset of the automata. The drawback of adding an observer is the
reduced maintainability of the models because a change of one of the components automata now
also means that the observer needs to be adapted. Furthermore the direct relation between some
requirement, specified as a logical expressions, and the component automata is lost.
The observer can stay in sync with the components involved by sharing important events. The
events have to be carefully picked, such that the states of the observer always represent the correct
status of the system. When the CmosProtector is waiting for a reply from one of its servers, the
observer should for example be in a ’waiting’ state. The specified notifications that have to be sent
to the user after a state change are also not specified in any component of the system, because
it is purely a software event. Therefore, it is convenient to add these events to an observer. The
observer designed for this case study can be seen in Appendix A.1.4.
4.2.3
Modeling components
The components of the physical system can be modeled in different ways, depending on the
requirements that need to be specified later on. When the actual state of one of the components
of the system is required for specifying logical expressions, the state names of the respective
automaton have to refer to the real state of that component. If only some events of the physical
system are important for the controller, a simplified version of the model can be enough.
Component knowledge has to be extensive to be able to correctly model the components. An
example is the question what the physical behavior of the BlankerShutter will be if it fails to
activate or deactivate. One could argue that the blanker did not move and remains at the last
4.2. Modeling aspects
29
known state or the blanker almost completed its task and did switch state. In these cases, no error
state is needed. But as the blanker is an important component of the safety, such assumption
involves a risk. A more used solution is to add an error state in which the actual state of the
BlankerShutter is not known. When the BlankerShutter is in this state, specifications tell which
action the CmosProtector can take.
Furthermore, an automaton can also be divided into smaller automata if that is more convenient
for synthesis or clarity of the automata. In this project, for example, the observer that covers all
the possible idle states of the CmosProtector is modeled by two automata. Although they can
be merged into one large automaton, this is not done to keep each of the automata as small as
possible. Now, each automaton can be included separately when needed in a module resulting in
smaller supervisors. Smaller automata are also more convenient to read and understand but the
disadvantage is that sometimes the connection between two automata is difficult to see.
4.2.4
Modeling requirements
A lot of specifications stated in the previous chapter are based on the state of the system, for
example, when the user is allowed to request information about the dose. Specification 13 states
that on a GetDoseInfo event the CmosProtector should reply with a NotAllowed event before
initialization and OK event after initialization. Such specification can be specified in more than
one way. An option is to add these events as a self-loop to the corresponding states of a requirement
automaton as can be seen in Figure 4.4.
GetStatus NotAllowed
GetStatus OK
Initialize OK
Terminate OK
Figure 4.4: Example requirement for GetDoseInfo
For only a few self-loops this is convenient, but automata clutter up fast with more than one
self-loop. Therefore, this specification can also be modeled by a logical expression as can be seen
in Formula (4.2). Now, the events NotAllowed and OK following on a GetDoseInfo are coupled to
states of the LifeCycle automaton of Appendix A.3.1. When the LifeCycle automaton is at state
Created a NotAllowed will be replied, and in all other cases a OK will be replied.
→ { GetDoseInfo NotAllowed } ⇒ Created ↓
→ { GetDoseInfo OK } ⇒ ¬ Created ↓
(4.2)
The advantage of this requirement is that it is clearly connected to the specification. For supervisor
synthesis it does not matter which of the techniques is used, because the logical expressions will be
transferred to automata automatically. The synthesized CmosProtector cannot be built by only
using logical expressions. Requirement automata are also needed to model a sequence of events
or to block certain events. Which kind of requirement has to be used for a specified requirement,
depends on what kind of requirement it is.
In this case-study, the specifications are modeled as logical expressions where possible. When a
logical expression depends on multiple large automata, automatic transformation to automata can
take a while. In this case, it is not a problem, but this can be avoided by having a modular design
and transform smaller sets of logical expressions to automata.
30
4.3
Chapter 4. Supervisor design for the CmosProtector
Creating a modular supervisor
As discussed in Chapter 2, the event-based framework allows synthesizing a supervisor in a modular
way. For this project, the coordinated distributed approach is used.
For this approach, the components and requirements have to be grouped. This grouping can be
difficult in the beginning, but some techniques can help. The grouping is mostly based on the
kind of requirements. If a requirement couples two automata together, these automata plus the
requirement should be in one module. Each automaton can be in more than one module. It can
be smart to build an observer that tracks the systems state. This observer is in general small,
and can easily be incorporated in all modules. Now, the requirements can possibly be coupled
to the observer instead of a real component of the system, making it possible to build a modular
supervisor.
The CmosProtector is split up in four modules shown in Figure 4.5. The first module Safety
keeps the observer StateTracker in sync with the other relevant plant automata of the system and
it makes sure that all safety requirements are met. To accomplish this it uses information from
BlankerShutter, Column and the SafetyList. Second, the Updater module handles the exchange
of parameter information between the SafetyList and the ProtectorDevices, controls when the
CmosProtector should consult the SafetyList and regulates when a void reply can be given back
to the ProtectorDevices. To achieve this, it needs the automata SafetyList, StateTracker, and
Input.
Legend
ChangeMaxDose
Module
Plant model
Updater
SafetyList
User
StateTracker
Input
LifeCycle
Safety
Column
BlankerShutter
Figure 4.5: Modular design of CmosProtector
The third module, Input, controls the actions and response on a request coming from a user
for which it uses information from the User, StateTracker, and LifeCycle. The last module
ChangeMaxDose handles the cases when, for testing purposes, a user changes the maximum allowed
dose for a particular sensitive device. This is a sequence of events that is always possible. This
means it could be added to an arbitrary other module, but separating these events keeps the other
modules smaller. The complete design of each module with its components and requirements can
be found in Appendix A.
4.4. Supervisor synthesis
31
4.4
Supervisor synthesis
4.4.1
Synthesized supervisor
The approach used for synthesizing the supervisor can be seen in Figure 4.6. The logical
expressions are converted to requirement automata using the component automata. The final
supervisor is a product of the local supervisors. As the distributed coordinated method is used, a
non-conflicting check has to be done.
nonconflict
check
Physical
components
components
automata
make
product
Logical
expressions
LogExpr2cfg
Specifications
Requirement
automata
Legend
Generated
file
Requirement
automata
Documents
Supervisor
Synthesis
Supervisor
module
Final
supervisor
minimization
SuSyNA
Manual file
Figure 4.6: Synthesizing the CmosProtector
The final CmosProtector is minimized and has 208 states and 354 transitions. A summary of the
number of requirements and automata used for synthesis can be seen in Table 4.1. This combined
supervisor is non-conflicting with the product of all plants which means no coordinator has to be
made. Now all the requirements and plants are complete, the CmosProtector can also be generated
monolithically. This monolithic synthesis results in the same supervisor.
No.
No.
No.
No.
No.
of
of
of
of
of
components
states per component
control requirements
states per requirement
logical expressions
6
2-8
11
2-3
23
Table 4.1: Summary of the supervisor synthesis input
4.5
4.5.1
Verifying the synthesized supervisor
Simulation and visualization
The simulator of the SuSyNA tooling can step manually or automatically through the supervisor
and create a message sequence chart or a visual representation of the current state of an automaton.
This simulation can be used to verify the synthesized supervisor for correct behavior. However,
the synthesized supervisor can grow large fast which makes extensive verification time intensive.
32
Chapter 4. Supervisor design for the CmosProtector
Because in this project a modular approach is used, it is useful to simulate the modules separately.
The problem, however, is that some automata are partly used in multiple modules of the supervisor.
As each module has requirements that only restrict a part of the automaton, all unrestricted events
are always allowed which reduces clarity during simulation of the individual modules.
The solution used for the CmosProtector is to project out all the unnecessary events of a module
before simulation. Now, only the events of interest remain and the modular supervisors can
be visualized and simulated more easily. The size of the modular supervisor before and after
projection can be seen in Table 4.2. For example, the number of transitions in the Safety module
decreases from 636 to 55. Notice that the modules with projection are only used for simulation
and that the original modular supervisors are used for building the composed supervisor. When
all the modules individual are correct, the complete supervisor can be composed and verified to
get the last errors out.
Module
Safety
Updater
Input
Change MaxDose
Combined supervisor
# states/transitions
58/636
192/1110
64/196
30/307
212/358
# states/transitions after projection
29/55
79/358
52/130
not needed
208/354
Table 4.2: Distributed coordinated supervisor
4.5.2
Generating a sequence-based specification
The supervisor synthesized in this chapter is designed as a run-to-completion controller. A feature
of a run-to-completion controller is that no new uncontrollable event can be processed as long as
the sequence of controllable events following on the previous uncontrollable event is not finished.
The resulting synthesized supervisor therefore has a lot of states that have only one outgoing
controllable event to another state. Although this modeling method vastly reduces the number
of states of the supervisor, it still clutters up fast which makes a comparison with the existing
controller made with ASD difficult.
Therefore, a script is made that transforms the synthesized supervisor automatically into a
sequence-based specification, similar as used in the ASD software package. In an SBS, the sequence
of controllable events is replaced by a list of actions following on a uncontrollable event. Where
simulation is useful for the first steps of finding modeling errors, this SBS has been particularly
useful for finding errors at the end of the modeling process.
Converting the synthesized CmosProtector to an SBS reduced the number of states with almost
a factor 10 and revealed an error. Although the system can terminate, not all the plants models
were able to terminate. This causes saving of state information during termination and increases
the state-space of the supervisor. The problem has been solved by redesigning the automata of
the SafetyList and Column such that they can terminate.
After correcting this error, the synthesized CmosProtector reduces to 28 states in a SBS. The
existing DoseProtector has nine states and a substate machine. When the substate machine is
substituted, the DoseProtector consists of only 14 states. This can be explained because of the
design choices made for the synthesized CmosProtector imply that it has to save information about
the state of the column. In ASD this would be solved by adding a state variable but because
supervisory control theory does not have variables, information is saved by creating different
states. When this design choice is removed, the synthesized model has the same number of states
as the existing CmosProtector. Their behavior, however, is not the same because the synthesized
supervisor is a more robust controller than the existing CmosProtector.
4.6. Reduction in unit tests in comparison with ASD
33
Now the synthesized supervisor can be converted into a sequence-based specification, the ASD
software can be used to generate defect-free code. To do this, the existing implementation is
replaced by the synthesized implementation while maintaining the interfaces, variables e.a.. As
a defect-free code generator is currently not available for the supervisor synthesis tooling, the
combination of both tooling is interesting.
4.6
Reduction in unit tests in comparison with ASD
FEI Company uses unit tests to verify whether their developed software meet the specifications.
Unit tests can run automatically and verify the real code, but are labor intensive and can only cover
a part of the state space. As a sequence can occur in more than one state of the CmosProtector,
a lot of unit tests have to be made to verify just one response in the different states. Therefore,
writing unit tests is currently the major part in the software developing time using ASD. With
supervisor synthesis, these sequences are now already included during generation of the supervisor.
This means that a certain sequence always occur in the same way, and therefore only needs to
be tested once. This can possibly reduce the unit tests needed tremendously. The SafetyList is
assumed to behave correctly because it is a foreign component that has been tested separately.
The possible advantage of using supervisor synthesis can be measured by counting the number
of unit tests that are not needed anymore when using supervisor synthesis and compare these
numbers to the current situation. The result can be seen in Table 4.3. Instead of the current 52
tests needed, only an estimate of seven tests are needed. This is a factor seven in reduction which
bring down the programming time of the unit tests.
Unit test
ProtectorForcedBlanking
BlankerShutter
CmosProtector
ProtectorStateChanges
ProtectorDeviceInsertRetract
Total
Current
7
7
22
7
9
52
after synthesis
2
1
3
0
1
7
Table 4.3: Number of unit tests
4.7
Discussion
This chapter demonstrated some of the key aspects of the supervisor design process and showed
some positive and negative aspects of both the supervisor synthesis and the ASD tooling.
At the start of this project it was already clear that the documents of the CmosProtector were
not complete and incorrect. As supervisor synthesis requires a complete set of requirements, extra
work and time was required to complement the requirements by reading the unit tests, asking
employees, and doing additional simulation of the synthesized controllers. In the end, this extra
effort do give a complete set of requirements used for the controller which can be used to update
the documents.
A problem that surfaced during this project it that for even the simple button-lamp example of
Chapter 2, it is difficult to get a complete set of requirements. Documented requirements state
when the blanker has to be activated, but activation and deactivation itself is not restricted which
can cause unnecessary switching of the blanker in some states. This unwanted behavior is only
visible by simulating the model which can be time-intensive for large controllers. Simulation can
only show that the system might have the correct behavior but cannot guarantee the correctness
34
Chapter 4. Supervisor design for the CmosProtector
of the model because it is not feasible to check every possible state of the supervisor because of
time. The synthesized CmosProtector is relatively small because of the run-to-completion layout
and can be validated by hand using simulation. If the supervisor is larger, formal verification has
to be used.
Because supervisor synthesis has a different view on a system, some interesting design points of
the existing CmosProtector surfaced. First of all, the CmosProtector does not always consult
the SafetyList because the answer is known on forehand. Safety decisions are thus copied which
reduces maintainability and can be error prone. Furthermore, the existing CmosProtector is not
consistent with leaving out this consulting to the SafetyList. Some optimizations are not applied
on every moment they could be applied which makes the specification illogical. The synthesized
CmosProtector is therefore a more robust controller, but will therefore consult the SafetyList more
often. Furthermore, the existing CmosProtector does not handle all state-based decisions. Some of
them are handled by the SafetyList, which require that the SafetyList keeps track of the state of the
CmosProtector. As this is superfluous, the synthesized CmosProtector does handle all state-based
decisions and these decisions could be removed from the SafetyList. The last interesting thing is
a modeling preference. When the electron dose never becomes unsafe, the BlankerShutter of ASD
will never leave its initial state when activated while it would be preferred that it goes to the Off
state. As initially is assumed that the blanker is off, it would be better to have the Off state of
the BlankerShutter as the initial state. This, however, does not influence the final behavior of the
CmosProtector.
The advantage of ASD is that the developer has to think about the actions that follow on each
trigger at each state. This approach can deal with initially incomplete documented requirements.
When a requirement is missing, the developer is forced to decide what would happen in that case.
This, however, can create inconsistency in the model when the decisions made are local and badly
documented. These inconsistencies can also be found in the existing CmosProtector built with
ASD. Related to this problem, ASD does not have a clear point where to input the requirements.
Requirements can be both in the interface models and the design models. This is done such that
clients using the interface model as a service can be checked more thoroughly because of the more
strict interface models. Drawback is that when a requirement in the system changes, both the
interface model and design model have to be changed and often it is not clear which requirements
are handled where in the design model of ASD. Supervisor synthesis will create more consistent
controllers because it is synthesized based on requirements and when a requirement or model
changes, a controller synthesized with supervisory can be adapted more quickly than a controller
made with ASD.
Although with both tools controllers can be made successfully, both tools have their drawbacks.
A combination of the best parts of both tooling could be a good solution, for example using the
code generator of ASD to generate code from models synthesized with the supervisory tooling.
Another option is to check whether ASD models can be functionally verified using the supervisor
synthesis tooling. This will be explained in more detail in the next chapter.
Chapter 5
Using supervisory control for
functional verification of ASD
models
When a component is modeled with the ASD suite, a number of properties are verified, e.g.
deadlocks, livelocks, race conditions, and determinism of the design models. However, the behavior
of the modeled component could still be undesired. Examples are wrong notifications, wrong
actions on a trigger, or a wrong destination state. To verify this functional behavior of such a
software component, FEI currently uses unit tests. These unit tests require coding and are difficult
to maintain which results in higher costs for development. They also only cover a part of the
software components behavior. Therefore, FEI is looking for an automatic verification technique
that can replace a number of unit tests. As discussed in Chapter 1, functional verification can
possibly reduce the automated testing time and the manual testing time, and thus the total
development time.
5.1
Functional verification tools
Currently available tools that can functionally verify discrete-event systems are µCRL2 of
[GMU+ 07], SPIN of [Hol97], and Uppaal of [Uni12]. For this project, only Uppaal is explained
in more detail. Uppaal is a commercial tool in which a system consisting of automata with data
and clocks can be modeled, simulated, and verified by specifying requirements. As mentioned in
the introduction, a project has been performed by FEI to explore whether Uppaal can be used
to functionally verify ASD models. The project was carried out by manually transforming the
ASD models to a form suitable for Uppaal. It showed that Uppaal is able to functionally verify
requirements over ASD models using temporal logic and observers, although automated translation
to Uppaal and systematic methods to generate verification expressions are needed.
The SuSyNA tooling can also be used to verify an existing controller. This candidate controller can
be verified for controllability and non-conflicting with respect to the plant. Currently, the tooling
does not have an option to functionally verify an existing controller by specifying requirements.
As both requirements specified over states and over events can be used for supervisory control
theory, the tooling could have an advantage over Uppaal which can only specify requirements over
states. This chapter evaluates if it is possible to use the SuSyNA tooling to functionally verify
existing controllers built with ASD. First, the approach will be explained. Using this approach,
functional verification is done using the current CmosProtector designed with ASD. At the end,
the results are discussed.
36
5.2
Chapter 5. Using supervisory control for functional verification of ASD models
Verification using SuSyna
As discussed in 2.2, a component in ASD requires a model of the functional interface behavior
and a model of the functional design. This interface model is the abstraction of the components
implementation. The design model interacts with other components using their respective interface
models. For supervisor synthesis, plants are created that represent the external visible behavior
of (a part of a) component, and the implementation of the controller is the synthesized supervisor.
These models can thus be compared with their ASD counterpart. A synthesized supervisor
contains all restrictions imposed by all requirements specified. This supervisor can thus also
be seen as one large requirement over the plant models. Now, the interface models can be used
as plant models and the design model can be used as requirement to synthesize a supervisor. It
is expected that this supervisor accepts the same language as the design model. If this is not the
case, the design model is incomplete and/or not correct.
Next, requirements can be made to verify certain specifications like sequence of events or
state-based expressions. With these requirements, another supervisor can be synthesized. This
supervisor can be compared with the previous synthesized supervisor. If they both accept the
same language, the added requirements are superfluous which means they are already enforced by
the design model. If the languages differ, the design model does not incorporate the specification
and the functional verification fails. This approach is depicted in Figure 5.1. The purple blocks
are data files containing the models, the red blocks refer to SuSyNA tooling, and the white blocks
are actions that can be done manually or automatically.
Specified
requirements
ASD
Design
model
Conversion
to cfg
Requirement
automaton
Interface
models
Conversion
to cfg
Plant
automata
Supervisor
synthesis
Supervisor
2
Compare
Supervisor
synthesis
Supervisor
1
Legend
File
New steps
SuSyNA
Figure 5.1: Overview of the approach
The requirements that need to be verified can be based on information on both the design model
and the interface models, which is called white-box testing. White-box testing mainly focuses
on the internal working of a model and is normally performed by developers. Testing the whole
internal working is nearly impossible because of the large amount of paths internally possible.
However, for functional verification the internal working is not important. It is only important
that the requirements specified are indeed enforced by the controller, how this is achieved is not
important. Therefore, functional verification with only using the interface models is preferred,
which is called black-box testing. Black-box testing focuses on the functionalities and can be
done by testers who have no knowledge of the internal working. The test cases can be designed
early in the development process, and do not change when the internal working of the design
model changes. A disadvantage of black-box testing is when a verification fails, the causes of this
problem is hard to find. Another disadvantage is that not all paths can be tested. For functional
verification of ASD models, black-box testing is thus preferred because now the internals of the
5.2. Verification using SuSyna
37
design model are not important anymore. This means the added requirements can only be based
on states of the interface models and events between all the interface models and the design model.
The structure of event notation is different between ASD and supervisory control theory. In
ASD, an event that the controller can send to its server is modeled as a controllable event for
the controller and modeled as an uncontrollable event for the server. A reply from the server
back to the controller is controllable for the server, but uncontrollable for the controller. For
supervisory control theory each event is either controllable or uncontrollable, seen from the
controllers perspective. Therefore,when an ASD component is converted to an input model for
supervisor synthesis, all controllable events of the servers have to be transfered to uncontrollable
events and vice versa. Furthermore, supervisory control theory needs at least one marker state per
automaton. As ASD does not have marker states, one or more states should be selected. Although
the initial state is a good candidate, some of the interface models have an initial state which is
not reachable from any other state. In that case, at least one other state should be marked.
The existing CmosProtector is used to show how SuSyNA can be used to verify certain
requirements. The CmosProtector is the design model and has an interface used by other
clients. The CmosProtector makes use of two server interface models: the BlankerShutter and
the SafetyList. Although the implemented SafetyList component is either safe or unsafe, the
interface model of the SafetyList consists of only one state. To be able to specify requirements
over the safety state, the current interface model is extended with both a safe and unsafe state.
Although this is not intuitive in the beginning, it is useful during functional verification of the
CmosProtector.
5.2.1
Nondeterminism of the interface model
If a supervisor is synthesized with the interface models as plants and design model as requirement,
the supervisor turns out to be empty because of a non-deterministic interface model of the
CmosProtector.
Supervisory control theory is a theory based on languages which, according to [FL96], implicitly
assumes that the automata involved are deterministic. In [SvSR10b] , modular synthesis is
described with nondeterministic plants using automata abstractions, but in our case there is
only one requirement over all plants which makes modular supervisor synthesis impossible. If the
supervisor needs to track the state of the plant, it has to be state controllable which means only
the knowledge of the current state is enough to predict the future (no information on the past has
to be known). When there are nondeterministic automata, there can be a difference between the
language controllability and the state controllability of the supervisor.
This phenomenon is best explained with an example model shown in Figure 5.2. All events of
the automata are controllable. If in ASD the nondeterministic automaton of 5.2(a) is used as
interface model and 5.2(c) as its implementation, the design model, the model checker of ASD
verifies whether the design model is compliant to its interface model. This is indeed the case, as
the sequence {a,b} is possible in the interface model.
As discussed in Chapter 2.3, supervisory control theory has also checks for controllability and
marked states. Now, when the nondeterministic automaton of 5.2(a) is used as plant and 5.2(c)
as requirement, the synthesis will yield and empty supervisor because of these extra properties.
After accepting an a, the requirement does not allow a c to happen. When this transition is
blocked, state 2 becomes a deadlock state because there is no path to a marked state anymore
and therefore the transition a has to be removed which results in an empty supervisor. When
the nondeterministic automaton is transformed into a deterministic automaton, see 5.2(b), after
blocking transition c state 6 still has a path to a marker state and a valid supervisor will come
out.
38
Chapter 5. Using supervisory control for functional verification of ASD models
0
a
1
b
3
5
a
9
a
2
a
6
c
c
b
4
10
7
(a) Nondeterministic
b
8
11
(b) Deterministic
(c) Requirement
Figure 5.2: Automata for explaining difference ASD and supervisor synthesis with respect to
nondeterminism
All nondeterministic models can be made deterministic by combining states that can be reached by
the same string. When this is done for the nondeterministic interface model of the CmosProtector,
a non-empty supervisor can be synthesized which accepts the same language as the requirement.
The problem, however, is that due to combining states, state information is lost which reduces the
applicability of logical expressions over states during the verification.
This can be resolved by introducing an observer that keeps track of the states of the interface model.
Now, when the interface model is made deterministic, state information can still be obtained from
the observer. For the interface model of the CmosProtector, the LifeCycle automaton of A.9 can
be used as observer for the activation and deactivation of the controller. When the CmosProtector
is activated, its actual state (ForcedBlankOn, SafeExposure or Error) can be obtained by looking
at the state of the BlankerShutter.
5.2.2
Status of the CmosProtector
ASD models are run-to-completion, which mean no new trigger is accepted before the actions
following on the previous trigger are processed. During this processing the controller is busy, and
after sending a reply on this trigger the controller becomes idle again. For functional verification,
some state-based requirements need to hold only when the controller is idle; it is not important
what the state combination is when the controller is busy. To know when the controller is idle, an
extra automaton is modeled as shown in Figure 5.3.
trigger
Busy
Idle
response
Figure 5.3: Status of the CmosProtector
Trigger consists of the set of uncontrollable events the controller can receive from a client, and
response consists of the replies on those triggers. Later on, the state Idle can be used to verify
certain allowed state combinations.
5.2.3
Verifying the CmosProtector
With the observers and the deterministic interface models, certain requirements can be verified.
The requirements used for supervisor synthesis of the CmosProtector can partly be reused. For
5.2. Verification using SuSyna
39
now, the most important ones are explained.
First, state-based requirements are used to verify the response on a certain trigger by a user.
When the CmosProtector receives a GetStatus event, it responds with an event based on the
current configuration of the system. Such reply can now be verified using the following expression.
→ { GetStatus Off } ⇒ Off ↓
(5.1)
The requirement states that a GetStatus Off event is only allowed at the LifeCycle automaton
state Off. A different reply is given when the system is activated and the environment is safe for
the camera. The reply can be based on the state of the BlankerShutter.
→ { GetStatus SafeExposure } ⇒ BS ForcedBlankOff ↓
(5.2)
This, however, results in an empty supervisor because of a bad designed BlankerShutter. When the
CmosProtector is activated and the environment has never become unsafe, the BlankerShutter will
stay in its initial state. It would be better to set the BlankerShutter to the BS ForcedBlankOff
state such that the model represents the actual state of the blanker in the system. For now, the
current implementation can be successfully verified by using the following logical expression.
→ { GetStatus SafeExposure } ⇒ BS ForcedBlankOff ↓ ∨ BS Initial ↓
(5.3)
Now, a GetStatus SafeExposure reply is only accepted when the system is activated and the blanker
is in the state BS ForcedBlankOn or BS Initial.
Using the Idle state of the observer, the allowed state combination when the CmosProtector is
idle can be verified using a logical expression. This expression do have to be complete because it
specifies when Idle is allowed. If a combination is missing, verification will fail.
Idle ↓ ⇒ (
∨(
∨(
∨(
¬ Activated
Activated ↓
Activated ↓
Activated ↓
↓
∧
∧
∧
∧ BS ForcedBlankOff ↓)
BS ForcedBlankOff ↓ ∧ BS SafeExposure ↓)
(5.4)
BS ForcedBlankOn ↓ ∧ BS UnsafeExposure ↓)
BS Error ↓)
Caution has to be taken when logical expressions only based on state information are used. A
conversion tool is used to convert these logical expressions to automata that can be used as input
for the supervisor synthesis tooling. The logical expressions specified are in most cases, if the
controller is correct, already enforced by the controller. The conversion tool is currently designed
in such way that in those cases it will notice this and does not generate an automaton. The
solution for now is to add at least one requirement over an event, for example by adding an extra
event at the initial state and specifying this event may only happen in the initial state.
Sequences can be verified using event-based requirements. These automata are in general the same
automata as used for synthesizing the CmosProtector. An example is verifying that the settling
dose of the column is successfully communicated to the SafetyList by adding the automaton of
Figure 5.4 as requirement.
All requirements that are used for synthesizing the controller of Chapter 4, can now be used
to functionally verify the controller designed with ASD. This shows that black-box functional
verification of ASD models is possible using the supervisor synthesis tooling.
40
Chapter 5. Using supervisory control for functional verification of ASD models
Settled
DoseSettled
Figure 5.4: Validating a sequence
5.3
Discussion
This chapter demonstrates that it is possible to functionally verify ASD models. In this project,
the supervisor synthesis tooling has been used for functional verification of ASD components.
Before the supervisor synthesis tooling can be used for verification, the ASD models have to be
transformed to automata. This could be done manually or automatically. With these automata
different kinds of requirements can be verified, such as sequences and state or event exclusions.
The requirements can be specified with automata and/or logical expressions. The advantage
of functional verification is that a requirement is checked for the whole state space at once. If
unit tests are used, this requirement need to be verified for each state separately. Functional
verification, however, only works when the sequence is the same every time. If optimizations are
applied by, for example, removing certain events, it is difficult or even impossible to specify a
general requirement that also successfully verifies all those optimizations .
The greatest disadvantage of using the supervisor synthesis tooling for functional verification is
the lack of a counter example in case the proposed verification fails. In such a case Uppaal will
give a trace to the moment the requirement is violated. When a requirement is not satisfied, the
new supervisor will not accept the same language as the original supervisor. For now, finding the
requirement that is not valid for the model can be done by verifying only one requirement at a
time. Because of the black-box testing, the cause of a non valid requirement is hard to find in the
design model . Another option could be to make all states marked. In that case, a requirement
that is not valid for the model only removes a part of the state space of the resulting supervisor.
This missing part could then possibly be found using simulation and visualization. This, however,
is again a manual step that is labor intensive and error prone.
The advantage of using the supervisor synthesis tooling for verification over Uppaal is that both
automata and logical expressions can be used for verification. This gives a larger freedom and
more clarity of the requirements to be verified. The only way to specify requirements in Uppaal
is to use logical expressions over states. For Uppaal, the straightforward automaton requirements
have to be transformed into a combination of an automaton and a logical expression over the
states of this automaton.
Chapter 6
Conclusions and
Recommendations
The goal of this project is to investigate how supervisory control theory tooling of Eindhoven
University of Technology can help FEI Company in developing correct control software for its
electron microscopes. The CmosProtector that protects the highly sensitive camera of a electron
microscope from a too high electron dose is chosen as a case study which is currently built with
ASD. Section 6.1 contains the conclusions that can be drawn from this project, and Section 6.2
proposes a couple of ideas for further research.
6.1
Conclusions
Both the ASD tooling and the supervisor synthesis tooling have their advantages and
disadvantages. With ASD, the developer fully specifies the controller in a sequence-based
specification which ensures completeness of the controller. However, this specification is error
prone because errors are easily made and inconsistencies due to possible sloppy repetitive work
and copy errors can arise. The ASD verification will not find all of these errors as verification
is only done component-wise against the respective interface model. When the ASD models
become larger, it can also be difficult to maintain a clear overview of the whole component.
Furthermore, requirements are incorporated in both the design and interface models which reduces
maintainability.
For supervisory control theory, the synthesized controller is correct with respect to the component
models and the requirements specified. The advantage of generating the controller is the high
maintainability. However, it can be difficult to get the requirements complete in the first place. The
only way to verify whether the requirement set is complete is simulation which is time intensive.
As there is a lot of freedom in modeling and specifying requirements a lot of solutions are possible,
of which some are more clear than other.
This project showed that for designing a controller, supervisor synthesis (everything is possible,
except what is restricted by requirements) and ASD (specify what happens for each case) have
exactly the opposite starting point. Both tools can produce the same controller which makes
them equivalent in the result but different in the approach. By comparing the synthesized
supervisor with the existing controller built with ASD, some interesting questions about the
existing CmosProtector came to the surface. Not all state-based decisions are done by the
CmosProtector, and optimizations are done inconsistently.
42
Chapter 6. Conclusions and Recommendations
This project also showed that for supervisory control synthesis, a combination of both automata
and logical expressions for requirements specification is most convenient. By modeling the
controller as a run-to-completion controller, the state space of the resulting supervisor is reduced.
This is because no new trigger (uncontrollable event) is handled as long as the actions (controllable
events) on the previous trigger are not finished yet. This resulted in a more clear overview of the
supervisor. Moreover, simulation can be used more effectively during the iterative steps of the
design process. By transforming the synthesized supervisor to a sequence-based specification, the
last error was found in the models that were not found earlier by simulation. This shows that
simulation process is not satisfactory for verifying the synthesized controller and other options
need to be researched. Furthermore, the sequence-based specification is similar to the model
specification of ASD which makes a comparison easier. In the end, ASD can be used to generate
code from the synthesized model.
For supervisor synthesis, a complete requirement set is needed. Investigation shows that the
number of unit tests needed can possibly be reduced with a factor of seven compared to the
original ASD model because the synthesized supervisor is already correct with respect to the
requirements. This means less time is spent on programming the unit tests, which is a major part
of the software development time with ASD. It is also possible to verify ASD models using the
supervisor synthesis tooling, but because a trace is not produced when verification fails the current
tooling is not usable as verification tool. However, it does show that all requirements specified for
synthesis can be used to functionally verify ASD models.
6.2
Recommendations
The current requirement specification language is limited which means a lot of extra requirements
need to be specified to complete the set of requirements. Research in the field of requirement
specification could help in reducing the number of less obvious requirements. This could, for
example, be done by introducing importance of states and/or events. The current four state-based
expressions needed to specify the requirements of the example elaborated in Chapter 2 could, for
example, be reduced to a single one by making the state ForcedBlankOff dominant and specifying
only requirement 2.4. A new supervisor control modeling language is already under development
at the Eindhoven University of Technology called SEAL of [SEG12] which can do supervisor
synthesis with models containing variables, conditions and equations. It also supports events with
guards, updates and urgency which will make requirement specification easier.
This project shows that because of specifying the requirements for synthesis a reduction of a factor
of seven in unit tests can be established. If these requirements are used for functional verification,
the same result applies. Therefore, Verum should investigate the possibilities of using functional
verification in their tooling. During this project the synthesis tooling is used to check if the earlier
defined requirements can be used to functionally verify an existing ASD model. Research has to
be done to check if this verification also works on other ASD models which contain more features.
Using the supervisory control synthesis tooling for verification of ASD models turned out to be not
useful because error-trace generation is missing when a requirement is not satisfied by the ASD
model. By adding this trace generation, the tooling can possibly be used to verify ASD models.
This makes the tooling applicable in more phases during the software development at companies.
Another interesting thing is that, using smart modeling methods, the synthesized supervisor works
as a run-to-completion controller. As this run-to-completion model is similar to the model used for
controller specification in ASD, code generation from synthesized models via ASD is possible. For
this project, the original ASD design model is replaced by the synthesized model while maintaining
the interfaces, variables e.a. from the original model. An automatic transformation to the format
that can directly be read by the ASD code generator could be developed to make it possible to
easily generate defect-free code from supervisor models. To be able to convert the synthesized
6.2. Recommendations
43
model, a modeling guide should be written which explains what modeling techniques have to be
used to obtain a supervisor as a sequence-based specification layout.
44
Chapter 6. Conclusions and Recommendations
Bibliography
[BH]
Guy H. Broadfoot and Philippa J. Hopcroft. Analytical Software Design. Technical
report, Oxford University Computing Laboratory, Verum.
[BvdMFR11] J.C.M. Baeten, J.M. van de Mortel-Fronczak, and J.E. Rooda. Integration of
supervisory control synthesis in model-based systems engineering. Se report 2011-04,
Eindhoven University of Technology, Systems Engineering Group, Department of
Mechanical Engineering, Eindhoven, The Netherlands, 2011.
[Com10]
FEI Company. Introduction to electron microscopy. 2010.
[Com12]
FEI Company. Electron microscopes. http://www.fei.com/, 2012.
[DHvV12]
R. Doornbos, J. Hooman, and B. van Vlimmeren. Complementary verification
of embedded software using ASD and Uppaal. In Proceedings of Innovations in
Information Technology (IIT), 2012 International Conference on, pages 60 –65,
2012.
[Ege05]
Ray F. Egerton.
Physical Principles of Electron Microscopy.
Science+Business Media, Inc., New York, 2005.
[FL96]
M. Fabian and B. Lennartson. On non-deterministic supervisory control. Technical
report, Control Engineering Department, Chalmers University of Technology,
Göteborg, Sweden, 1996.
[FvdMFSR]
S.T.J. Forschelen, J.M. van de Mortel Fronczak, Rong Su, and J.E. Rooda. In 10th
International Workshop on Discrete Event Systems, Systems Engineering Group,
Department of Mechanical Engineering, Eindhoven, The Netherlands.
[GMU+ 07]
J. F. Groote, Aad H. J. Mathijssen, Y. S. Usenko, M. A. Reniers, and Muck J.
Weerdenburg. The Formal Specification Language MCRL2. In E. Brinksma,
D. Harel, A. Mader, P. Stevens, and R. M. A. Wieringa, editors, Proc. Methods
for Modelling Software Systems (MMOSS), volume 06351 of Dagstuhl Seminar
Proceedings, pages 1 – 15. Internationales Begegnungs- und Forschungszentrum fuer
Informatik (IBFI), Schloss Dagstuhl, Germany, 2007.
[Hoa85]
C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood
Cliffs, 1985.
[Hol97]
Gerard J. Holzmann. The model checker spin. IEEE Transactions on Software
Engineering, 23(5):279–295, 1997.
[JMvB+ 09]
K.G.M. Jacobs, J. Markovski, D.A. van Beek, J.E. Rooda, and L.J.A.M. Somers
(Oce). Specifying state-based supervisory control requirements. Se report 09-06,
Eindhoven University of Technology, Systems Engineering Group, Department of
Mechanical Engineering, Eindhoven, The Netherlands, 2009.
Springer
46
Bibliography
[LLW05]
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):1336 – 1348, 2005.
[MW06]
Chuan Ma and W.M. Wonham. Nonblocking supervisory control of state tree
structures. IEEE Transactions on Automatic Control, 51(5):782 – 793, 2006.
[RW87]
P. J. Ramadge and W. M. Wonham. Supervisory control of a class of discrete
event processes. volume 25, pages 206–230. Society for Industrial and Applied
Mathematics, 1987.
[SEG12]
Eindhoven The Netherlands Systems Engineering Group, Department of
Mechanical Engineering. Seal. http://seal.se.wtb.tue.nl/, 2012.
[ST06]
Rong Su and J.G. Thistle. A distributed supervisor synthesis approach based on
weak bisimulation. In 8th International Workshop on Discrete Event Systems, pages
64 –69, 2006.
[SvSR10a]
Rong 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):1627 –1640, july 2010.
[SvSR10b]
Rong Su, J.H. van Schuppen, and J.E. Rooda. Model abstraction of nondeterministic
finite-state automata in supervisor synthesis. IEEE Transactions on Automatic
Control, 55(11):2527 –2541, 2010.
[SvSRH10]
Rong Su, J.H. van Schuppen, J.E. Rooda, and A.T. Hofkamp. Nonconflict check
by using sequential automaton abstractions based on weak observation equivalence.
Automatica, 46(6):968–978, June 2010.
[Uni12]
Aalborg University. Uppaal. http://www.uppaal.com/, 2012.
[vRH12]
H.W.A.M. van Rooy and D. Hendriks. Event-based supervisory toolchain manual.
Technical report, Eindhoven University of Technology, Systems Engineering Group,
Department of Mechanical Engineering, Eindhoven, The Netherlands, 2012.
[Won10]
W.M. Wonham. Supervisory control of discrete-event systems. pages 189–243,
Systems Control Group, Department of Electricial and Computer Engineering,
Toronto, Canada, 2010.
Appendix A
Models for CmosProtector
This appendix contain all models for synthesizing the CmosProtector. For each of the four modules,
the plant automata and the requirements are discussed.
A.1
Safety module
The first module syncs the StateTracker with the Column, the BlankerShutter, and the SafetyList
and makes sure the system is safe. The component automata are introduced and the requirements
needed are specified.
A.1.1
Plant Column
To be able to specify requirements over the state of the column, an automaton of the column is
built and can be seen in Figure A.1. When the column is going to change the beam intensity, it
sends a Prepare event with the new dose level to the protector. When the column has reached its
final dose level, it sends a Settled event with the settled dose level. Between those two events, the
column is considered unsafe.
Terminate OK
Prepare
Prepare
Column Safe
Column Unsafe
Settled
Terminate OK
Figure A.1: Column automaton
A.1.2
Plant SafetyList
The model of the SafetyList can be seen in Figure A.2. For some of the requirements, the actual
state of the SafetyList has to be known. Therefore, the states of the SafetyList automaton represent
the actual state of the SafetyList. Chapter 4.1.2 states that the SafetyList can send back one of
three responses: anUnsafeExposure, a SafeExposure because there is a shielding device in front
of the sensitive device, or a SafeExposure lowdose because the preparation dose is low enough for
the sensitive device. The corresponding states are SL UnsafeExposure, SL SafeExposure,
48
Appendix A. Models for CmosProtector
and SL SafeExposure LD. Because the SafetyList will only return an answer about safety after
receiving a CheckDose event, this has to be modeled with an extra state SL CheckDose.
SafetyList event
Terminate OK
Terminate OK
SL SafeExposure
Terminate OK
SafetyList event
CheckDose
CheckDose Activation
SL UnsafeExposure
SafeExposure
UnsafeExposure
CheckDose
CheckDose Activation
CheckDose
CheckDose Activation
SL SafeExposure LD
SL CheckDose
SafeExposure lowdose
SafetyList event
Terminate OK
Figure A.2: SafetyList automaton
After receiving a parameter from the protector devices, the CmosProtector has to
send a corresponding SafetyList event1 to the SafetyList.
When activating the system,
CheckDose Activation is used instead of CheckDose. This simplifies the logical expressions needed
because there is a clear distinction between a CheckDose due to a parameter change in the system
and a CheckDose Activation due to activation of the system. Because the supervisor remembers
the last known location of the SafetyList after deactivation, a CheckDose Activation is leaving
from all idle states. The different events used for checking the exposure safety, CheckDose and
CheckDose Activation, can after synthesis be substituted by one event CheckDose. The SafetyList
also has to go back to its initial state after a successful termination.
A.1.3
Plant BlankerShutter
In Figure A.3, the automaton of the BlankerShutter is given. The state of the blanker is BS On
when the blanker blanks the electron beam and is BS Off when it is not influencing the electron
beam. During switching the blanker is in a switching state, and when switching fails the blanker
is in the BS Error state.
A.1.4
Plant StateTracker
The StateTracker is coupled to only controllable events of the system and can be seen in Figure
A.4.
Initially, the system is in Not Activated. When the CmosProtector is activating, it needs
to consult the state of the SafetyList with a Checkdose Activation event. In the state tracker,
this event goes to the state Changing. It can exit this state by the events nft ForcedBlankOn,
nft Error and nft SafeExposure that respectively go to the states ForcedBlankOn, Error and
SafeExposure. These nft events represent the notifications the CmosProtector has to give to
1 SafetyList Event
includes AddDoseTarget,
AddSensitiveDevice,
RemoveSensitiveDevice, and RemoveShieldingDevice
AddShieldingDevice,
DoseSettled,
A.1. Safety module
49
BS Switching Off
BS OK
SetForcedBlankOff
SetForcedBlankOff
BS Failed
BS Error
BS Off
BS Failed
BS On
SetForcedBlankOn
BS OK
SetForcedBlankOn
BS Switching On
Figure A.3: BlankerShutter automaton
the user when switching state. If in one of these three states again the SafetyList is consulted with
a CheckDose event, the observer goes back to the state Changing.
If the system needs to terminate or deactivate, an internal Ending event goes to Ending. When
deactivating a notification has to be given and when the system is terminating, no notification
is needed. In both cases the StateTracker needs to go back to Not Activated. This is done
by modeling two events nft Off and Terminate OK back to the initial state. When the system
is deactivating or terminating, the blanker has to be disabled. According to Requirement 6 this
can fail. Therefore, the internal event nft Error also goes from Ending to Error. In the initial
state, Terminate OK and Ending are self-looped to be able to terminate the system when it is not
activated.
A.1.5
Requirements for safety module
First, a safe system can be defined. According to requirement 1 and 3, the system is safe when
the exposure is safe or if there is no sensitive device inserted. The SafetyList keeps track of these
variables, and will report a safe exposure in both cases. Because of requirement 4 and the design
choices of Chapter 4.1.2, the system is also safe when the Column is safe and the SafetyList reports
a safe exposure because the dose is low. The system is unsafe in all other cases. The busy state
SL CheckDose state of the SafetyList is a state that is not safe or unsafe because the protector
is at that point waiting on an answer following up on a CheckDose consult. As long as this answer
is not given, the protector should not make decisions.
SafeSystem = SL SafeExposure ↓ ∨( SL SafeExposure LD ↓ ∧ Column Safe ↓)
UnsafeSystem = ¬ SafeSystem ∧ ¬ SL CheckDose ↓
(A.1)
According to requirement 1, the state ForcedBlankOn means that the system is unsafe and
the blanker is blanked. SafeExposure represents a safe system which means, according to
requirement 2, the blanker has to be off. Requirement 6 states that blanking of the beam can fail
50
Appendix A. Models for CmosProtector
Not Activated
Terminate OK
Ending
ForcedBlankOn
Terminate OK
nft Off
CheckDose
CheckDose Activation
nft ForcedBlankOn
nft Error
Error
Ending
Ending
Changing
Ending
nft Error
CheckDose
nft SafeExposure
Ending
CheckDose
SafeExposure
Figure A.4: StateTracker automaton
and the CmosProtector should notify the user about this.
→ { nft ForcedBlankOn } ⇒ UnsafeSystem ∧ BS ForcedBlankOn ↓
→ { nft SafeExposure } ⇒ SafeSystem ∧ BS ForcedBlankOff ↓
→ { nft Error } ⇒ BS Error ↓
(A.2)
Simulation shows that these requirements are not sufficient. First of all, the blanker can switch
unnecessarily switch on and off in the state SL CheckDose. To prevent the BlankerShutter from
unnecessarily switching on and off, an extra usability requirement has to be added that tells that
the BlankerShutter should only be activated when the system is Unsafe and the state tracker
is at Changing. Again, for usability, the blanker should only be deactivated when the state
tracker is at Changing and the system is considered safe. But according to requirement 7 the
blanker should also be off before deactivating or terminating the system, even when the system
is considered unsafe. Therefore, the SetForcedBlankOff event is also allowed in Ending of the
state-tracker.
→ { SetForcedBlankOn } ⇒ UnsafeSystem ∧ Changing ↓
→ { SetForcedBlankOff } ⇒ (SafeSystem ∧ Changing ↓) ∨ Ending ↓
(A.3)
The requirement for the Error state is incomplete because BS Error has the two outgoing
controllable events SetForcedBlankOn and SetForcedBlankOff. When entering this state, the
system is either safe or unsafe and according to the previous requirements one of the two events
is still possible as long as the state tracker is in Changing which voids the run-to-completion
design of the CmosProtector. To overcome this problem, an event-based requirement is added to
the requirements and can be seen in Figure A.5. After a failure of the BlankerShutter only the
event nft Error is possible before the events SetForcedBlankOn and SetForcedBlankOff are possible
again.
A.2. Updating the ProtectorDevices
51
BS Failed
SetForcedBlankOff
SetForcedBlankOn
nft Error
Figure A.5: Req Error
A.2
Updating the ProtectorDevices
For this module, one more automaton is needed and the automata of the SafetyList and
StateTracker are re-used in this module.
A.2.1
Plant Input
The automaton of Input can be seen in Figure A.6. It models the uncontrollable events coming
from the user and the ProtectorDevices2 in such way that the resulting CmosProtector will have
a run-to-completion behavior as discussed in Chapter 4.2.1. From the initial state it has all
uncontrollable events as outgoing transitions to unique states. In these states, the automaton
waits for reply from the CmosProtector before another uncontrollable event can happen.
GetDoseInfo
GetDoseInfo OK
GetDoseInfo NotAllowed
GetDoseInfo
GetStatus
RefreshMaxDose
RefreshMaxDose
GetStatus
GetStatus NotAllowed
GetStatus Off
GetStatus ForcedBlankOn
GetStatus SafeExposure
GetStatus Error
Deactivate
RefreshMaxDose VoidReply
Deactivate
Initial
Activate
Deactivate OK
Deactivate NotAllowed
Deactivate Failed
Terminate OK
Terminate NotAllowed
Terminate Failed
Activate
Activate OK
Activate NotAllowed
Terminate
Initialize
Initialize OK
Initialize NotAllowed
Terminate
Initialize
ProtectorDevices VoidReply
ProtectorDevices event
ProtectorDevices
Figure A.6: Input automaton
2 ProtectorDevices event represents Prepare, PrepareInsertionSensitiveDevice, InsertedShieldingDevice, Settled,
RetractedSensitiveDevice and PrepareRetractionShieldingDevice
52
Appendix A. Models for CmosProtector
A.2.2
Requirements for updater module
According to requirement 8, a change of one of the parameters of the ProtectorDevices has to be
passed on to the SafetyList. This is a sequence of events, and can be modeled with automata that
couples a ProtectorDevices event to its corresponding Safetylist event, as shown in Figure A.7.
Settled
Prepare
DoseSettled
AddDoseTarget
RetractedSensitiveDevice
PrepareInsertionSensitiveDevice
RemoveSensitiveDevice
AddSensitiveDevice
PrepareRetractionShieldingDevice
AddShieldingDevice
RemoveShieldingDevice
InsertedShieldingDevice
Figure A.7: Sending parameters to SafetyList
Requirement 9 states the SafetyList has to be consulted to see if the exposure is safe or not after
one of the parameters of the ProtectorDevices has changed. This action does not have to occur
every time. As long as the system is not activated, the CmosProtector does not have to check
whether the SafetyList thinks the system is safe. This is modeled with an automaton and a
logical expression and can be seen in Figure A.8 and Requirement (A.4). If the CmosProtector is
activated, the state CheckDose Needed is activated which implies a CheckDose has to be done
after a SafetyList events. In all other cases the other state is activated, and no CheckDose is done.
ProtectorDevices VoidReply SafetyList events
CheckDose NotNeeded
CheckDose Needed
SafetyList events
CheckDose
ProtectorDevices VoidReply
Figure A.8: CheckDose requirement
CheckDose Needed ↓ ⇒ Activated ↓
CheckDose NotNeeded ↓ ⇒ ¬ Activated ↓
(A.4)
A void reply for a ProtectorDevice after a parameter update can be given when the CmosProtector
is idle again. The system is idle when it is in one of the states of the system as discussed in
specification 14. The resulting requirement can be defined as follows.
Idle = SafeExposure ↓ ∨ ForcedBlankOn ↓ ∨ Error ↓ ∨ Not Activated ↓
(A.5)
→ { ProtectorDevices VoidReply } ⇒ Idle
A.3
User
The third module is the part that handles the events between the CmosProtector and a user. This
part requires, besides the StateTracker and the Input automaton, one additional plant.
A.3. User
A.3.1
53
Plant LifeCycle
Requirement 10 and 11 state that the CmosProtector has to be able to initialize and activate.
This can be called the life cycle of the CmosProtector. The LifeCycle plant can be seen in Figure
A.9. It keeps track of the life cycle of the CmosProtector by switching state when a specific event
is successfully processed.
Initialize OK
Off
Activate OK
Created
Activated
Terminate OK
Deactivate OK
Terminate OK
Figure A.9: LifeCycle automaton
A.3.2
Requirements for the user module
Automaton LifeCycle specifies when the CmosProtector can be initialized, terminated, activated
and deactivated according to Requirement 10 and 11. When one of these actions is requested by
the user but not allowed or possible, the CmosProtector should reply with an event NotAllowed.
→ { Terminate
→ { Initialize
→ { Activate
→ { Deactivate
NotAllowed
NotAllowed
NotAllowed
NotAllowed
}
}
}
}
⇒
⇒
⇒
⇒
Created ↓
¬ Created ↓
¬ Off ↓
¬ Activated ↓
(A.6)
As stated in Requirement 7, the CmosProtector has to make sure the blanker is off before the
system can terminate or deactivate. The events Terminate OK and nft Off from the StateTracker
are only allowed when the blanker is off. Activation is completed when the system is in one of the
idle states defined earlier. Because the blanker can fail, terminating and deactivating can fail too.
When the blanker fails, the state tracker will be in Error.
→ { Terminate OK, nft Off } ⇒ BS ForcedBlankOff ↓
→ { Activate OK } ⇒ Idle ↓
→ { Terminate Failed,Deactivate Failed } ⇒ Error ↓
(A.7)
According to Requirement 14 the user has to be able to requests the state of the system.
→ { GetStatus NotAllowed
→ { GetStatus Off
→ { GetStatus SafeExposure
→ { GetStatus ForcedBlankOn
→ { GetStatus Error
}
}
}
}
}
⇒
⇒
⇒
⇒
⇒
Created ↓
Off ↓
SafeExposure ↓
ForcedBlankOn ↓
Error ↓
(A.8)
Requirement 13 states that when the user request information about the dose, the CmosProtector
should reply with the DoseInfo. Before initialization it is not allowed to request doseinfo.
→ { GetDoseInfo NotAllowed } ⇒ Created ↓
→ { GetDoseInfo OK } ⇒ ¬ Created ↓
(A.9)
54
Appendix A. Models for CmosProtector
When activation is allowed, the SafetyList should be consulted to determine if the blanker needs
to be blanked and the state tracker has to advance to Changing before a reply is sent back.
This is again a sequence of events and can be specified by an automaton. When activation is not
allowed, the action Activate NotAllowed will happen to bring the requirement back to its initial
state. In Figure A.10 the resulting automaton can be seen.
Terminate NotAllowed
Deactivate NotAllowed
Terminate, Deactivate
Activate NotAllowed
Deactivate OK
Activate
Activate OK
Ending
Terminate Failed
Deactivate Failed
Terminate OK
CheckDose Activation
Figure A.10: Activate requirement
nft Off
Figure A.11:
requirements
Terminate and Deactivate
The same holds for deactivation or termination. When it is allowed, the CmosProtector has
to make sure the blanker is off before sending an OK back. This can be done by sending the
StateTracker to Ending by doing an internal Ending event. When deactivation or termination
is not allowed, the corresponding NotAllowed events will send the requirement back to its initial
state. After an Ending event, termination and deactivation can fail or succeed. When deactivation
succeeds, a notification nft Off is triggered before a Deactivate OK. When termination is successful,
a Terminate OK can be done and when the blanker fails when it is disabling, a Failed event is
done. The requirement automaton can be seen in Figure A.11.
A.4
ChangeMaxDose
The last module is a small one. It only contains the ability to change the maximum allowed dose
that is safe for the camera as stated in Requirement 12. As this is allowed in any state of the
system, it can be added to for example the updater module or, as has been done for this case
study , as a separate module. Now, when a RefreshMaxDose event is received from the user an
event is sent to the SafetyList before a void reply can be sent back. This implies sequencing of
events and can be modeled by an automaton and can be seen in Figure A.12.
RefreshMaxDose VoidReply
RefreshMaxDose
SRefreshMaxDose
Figure A.12: RefreshMaxDose requirement