Microprocessing

and
Microprogramming
EISVIER Microprocessing and Microprogramming 41 (1996) 737-756

A graphical simulator for programmable logic controllers based

on Petri nets
H.A. Barker, P.W. Grant *, J. Song
Departments of Electrical and Electronic Engineering and of Computer Science, Uniuersiry of Wales, Swansea, Singleton Park, Swansea,
SA2 8PP, UK

Received 6 February 1994; revised 2 June 1994; accepted 27 October 1995

Abstract

In this paper an extended Petri net, the programmable logic controller net (PLCNet) is defined. A rule-based PLCNet
simulator has been designed based on the semantics of PLCNets, with facilities provided to set up and control simulation.
Both step and time responses are provided for the presentation of simulation results. A graphical environment is provided for
the construction of the PLCNet, simulation and the presentation of simulation results.

Keywords: Programmable logic controller; Discrete event dynamic system; Simulation; Rule-based systems; Petri nets

1. Introduction

It has been over a decade since Petri nets [12] were first applied in process control. As early as 1980, a
compiler which maps a Petri net description into Intel 8085 assembly language was designed for control
purposes [6]. In the same year, a simulator and controller, implemented on a minicomputer with a primitive
graphical display, were developed, based on a marked flow graph, a subset of the Petri net model. The simulator
was used to eliminate deadlock in control systems [ 111. Later this work was transferred to programmable logic
controllers (PLCs), the first application of this type being described by 191.Based on their work, a C-net was
proposed at Hitachi to design a station controller, the cell level of their factory automation project [lo]. Petri
nets have also been used to replace conventional ladder diagrams in the design of programs for PLCs [7]. This

l Corresponding author. Email: p.w.grant@swansea.ac.uk

0165-6074/%/%15.00 0 1996 Elsevier Science B.V. All rights reserved

SSDI 0165-6074(95)0003 1-3
738 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

work shows that the Petri net is a powerful representational method for the modelling, simulation and
programming of PLCs.
There are, however, still many important aspects which have not been fully investigated. PLC applications
are mainly restricted to sequential control processes, and modelling often depends on the user’s personal
understanding of the system and interpretation of the Petri net, resulting in different representations for the same
system. A systematic modelling methodology is not yet available and the method of presentation of simulation
results is limited to the flow of tokens.
In this paper an extended Petri net, the programmable logic controller net (PLCNet), will be introduced and
a set of operational rules used to simulate PLCNets. A rule-based simulator is designed which follows closely
the definitions of the PLCNet and its operational rules. Various facilities are used to set up and control the
simulation and time and step responses are used to present the simulation results. The simulator is embedded in
an interactive graphical environment, the Control Engineering workstation (CES) [ 1,3,4]. This has been
developed as a general purpose graphical environment for the design, simulation and implementation of
dynamic systems, particularly for control. More recently, a thorough redesign and reimplementation of CES
using the X windows environment has been undertaken which is called extended X-based Control engineering
workstation (eXCeS) [2].

2. eXCeS

eXCeS makes full use of modem computer graphics workstation technology conforming to the OPEN LOOK
‘look and feel’. A tool-based design policy separates the user-interface from the applications. The tools can run
concurrently on a single workstation or on several remote workstations across the network using the X-protocol.
In particular, eXCeS provides an integrated environment to prototype discrete event dynamics systems [3,4]
for each level of a flexible manufacturing system. At the job-shop level, simulation and analysis tools have been
developed based on Petri nets. At the cell level, modelling, simulation, implementation and transformation tools
have been designed for PLC applications based on three graphical models - Petri nets, ladder diagrams [ 141and
Grafcet [8]. The modelling tools allow users to construct control processes graphically. The simulation tools
allow logical errors to be detected and corrected before the implementation phase. The implementation tools
provide a graphical programming environment in which various PLC codes can be generated directly from the
graphical models. Transformation tools allow one kind of graphical model to be converted into another so that
users can work with their preferred representation, yet still access others [13]. This paper, however, describes
only the design of the simulation tool for PLCs based on Petri nets.

3. Programmable logic controller nets

To introduce the programmable logic controller net (PLCNet), a simple wagon control process is used as an
example. A wagon is initially at rest. When the start button Xl is pressed, the wagon moves forward. As a
result, both states Sl and Y 1 receive a token. The token at Sl indicates the system reaches the system state Sl,
the token at Y 1 that the motor is energised. The movement of the wagon will eventually cause it to encounter
the limit switch X2. This external event is modelled by e3. When the limit switch X2 is encountered, the
 HA. Barker et al./ Microprocessing and Microprogramming 41 (1996) 737-756 739

Xl

Fig. I. Petri net for the sequential process.

wagon moves backward, adding a token to both S2 and Y2. This simple sequential control process can be
modelled by using a Petri net, Fig. 1.
Initially, a token is added to the state Xl representing the action that the start button has been pressed.
According to Petri net firing rules, the event el is enabled. The firing of el removes the token at X 1 and adds a
token to Sl and Y 1. The removal of the token by el indicates that the button has been released, the token at Sl
that the system reaches a new stage. This system stage denotes that the wagon is moving forward. The token at
Y 1 models the motor being energised. The enabling conditions for e3, require a token at Y 1 and no token at
X2. These two conditions are met by the current status of the system illustrated in Fig. 1. Event e3 is therefore
enabled, which means the wagon encounters the limit switch X2. The firing of e3 will remove the token at Y 1
and add a token to X2 and Y 1. As the token at Y 1 is removed and added at the same step, the total number of
tokens remains constant. The token at X2 represents that the limit switch is energised, the token at Y 1 the
motor is still energised when the wagon encounters the limit switch X2. This observation conforms with the
physical reality. Now the event e2 is enabled. The firing of e2 removes the tokens at Sl, Y 1 and X2 and adds
a token to S2 and Y2. The firing of e2 models the wagon’s movement backwards. The removal of the token at
Y 1 indicates that the motor is de-energised. The removal of the token from Sl and the addition of the token to
S2 models that the system status is transformed from the wagon moving forward to the wagon moving
backward. The addition of the token to Y2 models that the reversing motor is energised.
Notice there are three types of states in Fig. 1: the system states (SYS) Sl and S2, the physical output states
(PHYOUT) Y 1 and Y2, and the physical input states (PHYIN) X 1 and X2. As some physical input states are
initiated by users and others by the actions of physical output states, two sub-categories are identified - user
driven physical input states (USERDRIVEN), such as Xl, and physical driven physical input states
(PHYDRIVEN), such as X2. Two types of events can be identified - internal events and external events.
Internal events occur in PLCs and external events take place in the environment. In Fig. 1, el and e2 are
internal events and e3 is an external event.
The disadvantage of the representation above is its complexity. Even for the simplest of control systems the
complexity of the resultant model is evident. The size of a model soon becomes overwhelming in modelling real
life control systems. A complicated model is not only hard for users to understand, but also requires more
computational resources. However, these disadvantages can be overcome by transforming the Petri net to a
simplified form. The idea behind the transformation is to remove some parts of the Petri net and to
automatically generate the missing components from the existing ones. The corresponding semantics, defined by
the Petri net operational rules, has to be modified to reflect these structural changes.
740 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

YI e3 x2 Y2
Fig. 2. Petri net for the sequential process with a virtual event.

The first technique is to simplify the structure of models by introducing a new type of event called a virtual
event (E, ). Ordinary events in a Petri net are then referred to as concrete events (Ec). The semantics of virtual
events are informally stated as follows:
a the enabled conditions for a virtual event are the same as those for a concrete event,
l the firing of a virtual event will not, however, remove the tokens at its input states, but will add tokens to its
output states as usual.
The semantics of virtual events precisely model the behaviour of external events such as e3 in Fig. 1. The
firing of e3 will remove the token at Y 1 and add a token back to Y 1 at the same step. A virtual event is
represented graphically as a vertical hollow rectangle, in contrast to the solid vertical bar for the concrete event.
The simplified Petri net is shown in Fig. 2, with fewer connections than Fig. 1.
Further simplifications can often be carried out by applying simple rules, which are illustrated in the next two
examples.
Fig. 2 can be simplified by omitting the arc from Y 1 to e2. This arc can be synthesised by tracing e2
backward to X2, from X2 to e3 and finally from e3 to Y 1. The derived Petri net for the sequential process is
therefore as shown as Fig. 3.
This synthesis technique is, however, not applicable to the situation where the physical output state will
energise the physical input state of another process. Fig. 4 shows such an example.
According to the synthesis technique introduced above, finding the input states for e6 involves the following
procedure: trace from e6 backwards to Y4, from Y4 to e3 and e5, from e3 to Y 1 and from e5 to Y3. Two
missing input states are found - Y 1 and Y3. However, according to Fig. 4 only Y3 is a missing input state and
so a modified search strategy has to be devised. This time an additional search is required, which involves

Yl e3 x2
Fig. 3. PLCNet for the sequential process.
 HA. Barker et al. /Microprocessing and Microprogramming 41 (19961 737-756 741

el e2

Fig. 4. An example with a remote connection.

searching from e6 to S5, from S5 to e4 and from e4 to Y3. By intersecting the results of the two searches, Y3
is returned as the required correct result.
In contrast to this example, in the situation illustrated in Fig. 5, the connection from Y 1 to e6, marked in
gray, cannot be omitted because the above synthesis technique will exclude Y 1 as not being an input state of
e6.
The introduction of new states such as physical input and physical output and new events such as virtual

el e2

Fig. 5. An example with a non-removable remote connection.

742 H.A. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

events require that a more specific Petri net, named PLCNet, be defined. The formal definition of the PLCNet is
given in Definition 1 of the Appendix A.

4. Synthesis of operational rules

Generally speaking, whenever the syntax of a modelling language is simplified, the semantics of the
language will be more complicated in order to achieve the same modelling capability. The simplification of the
Petri net structure requires the following extensions to the operational rules:
l The firing of a virtual event will not remove its input tokens, but will still add the tokens to its output states;
l The firing of a concrete event not only removes its input tokens, but also removes the tokens from the output
physical states of the previous event.
In what follows, the generic operational rules are formally synthesized. In addition, time is also taken into
consideration. Rule 1 is applied to concrete events. Rules 2-5 are applied to virtual events. Rules 2 and 3 are
applied to a virtual event with no timer state as input. Rules 4 and 5 are used for a virtual event with a timer
state as input.

Rule I
This rule is defined for concrete events. Two sub-rules are defined for Rule 1 which are applicable for e E EC
when the following condition holds:

where p is the current marking of the net.

This condition is the enabling condition for a concrete event. The sub-rules distinguish two situations
depending upon whether the concrete event has zero or greater than zero previous events. Here and below, p’
indicates the update in the marking resulting from the execution of the rule:

Rule 1.1
PREVEVE( e) = # -+VpEL(e)U0,(e)(d(p)=dp)-V(p3e)+V(e9p))

Rule 1.2
PREVEVE( e) f d

-+VpE4Ae)U%(e)(CL)(p)=4p)-V(p9 e) +V(e, P))A

ife’E PREVEVE( e)Vq E (O,( e’) - SYS)( p’(q) = p(q) - 1)

When the input states of an event are live (with tokens) and the output states are dead (without tokens), the
event is enabled. Rule 1.1 applies to an event with initial states as its input states. Event el in Fig. 2 is such an
example where Xl is an initial state.
Applying Rule 1.l removes the tokens in the input states and adds a token into each output state. Rule 1.2 is
applied to an event with previous events. In addition to the operations performed by Rule 1.1, it also removes
the tokens from the latched output physical states of the previous events. e2 in Fig. 2 is such an example in
 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756 143

which the previous event of e2 is el. Suppose in the current system status, a token is at Sl, Y 1 and X2 and no
token at the remaining states of the system. Applying the rule will not only remove tokens at Sl and X2, but
also remove the token at Y 1. Intuitively, after the wagon encounters the limit switch X2, the motor causing the
wagon to move forward will be de-energised and the wagon will leave X2.

Rule 2
For eEE,,

TIMnI,(e) =d AW%(e)( P(P)>~) AW=O&)( E.L(P)=~)

A O,( e) n USERDRIVEN Z 0
--j wait users action

Rule 2 means if e is a virtual event without timer states as input, all input states of e are live, all output
states of e are dead and some output states are user-driven, then wait for users to add a token for output states to
proceed with the simulation.

Rule 3
For eEE,,

TIM%(e) =d AVpE&(e)( p(p)>O)AvpEO,(e)(~(p)=O)

A O,( e) G PHYDRIVEN
-+VpEO,(e)(d(p) = 1)

The conditions of Rule 3 are the same as those in Rule 2 except the output states of a virtual event are driven by
physical input states. Applying the rule will add a token to each output state of the virtual event. In Figure 2,
X2 is not driven by users. Applying Rule 3 adds a token to X2 and the tokens at S2 and Y 1 remain unchanged.

Rule 4
For GEE,,
vpE~a(e)(CL(p)>O)AvqE~~~n~,(e)(r,(q)=O)
AO,(e)GlJSERDRrVENAVpEO,(e)( p(p)=O)

+ wait user’s actions

where r,( p> is the amount of time left on the state p before the timer is timed out.
Rule 4 applies to a virtual event whose input states contain timers. The conditions for applying this rule are
that the input states are live, output states are dead, timers are time-out and the output states are driven by users.
Under these conditions, users have to add tokens to user driven states in order to proceed with the simulation.

Rule 5 There are three sub-rules in Rule 5. The following conditions are the same for all the three rules:
For eEE,,
144 HA. Barker e! al./Microprocessing and Microprogramming 41 (1996) 737-756

The rule states that if for a virtual event, its input states contain timers, the input states are live, its output states
are dead and the timers are still timing. Each sub-rule can then be defined as:

Rule 5.1

O,(e)~USERDRZVENAVpEZ,(e)nTZM(t,(p)2r,)

-+VpE&(e) nTZM(&(p) =&(P) -t,)

Rule 5.2

O,(e)nPHYDRZVENf$ AVpEZg(e)nTZM(t,(p)>f,)

+VpEZ&) nTZM(C(p) =&(P) -4)

Rule 5.3

O,(e)nPHYDRZVEN#@AVpEZ,(e)nTZM(t,(p)=t,)+

Rule 5.1 applies to the case where the time in the time left in input timer states is greater than or equal to the
smallest event life time. I,, and its output states are all driven by users. Applying Rule 5.1 will reduce timer’s
time by c,. The timer clock of a system will tick forward by the period of t,.
The action part of Rule 5.2 is the same as that of Rule 5.1. The difference is that the time left in input timer
states is greater than the smallest event life time, r, and at least one output state of a virtual event is a physically
driven state.
The condition part of Rule 5.3 differs with Rule 5.2 in that the time left in the input timer states is equal to
the smallest event life time. As a result, applying Rule 5.3 to the virtual event will not only reduce the timers’
time by t,, but also add a token to each of the physically driven states of the virtual event.

5. Rule-based PLCNet simulator

Rule-based techniques have been successfully applied in the design of PLC implementors (Barker et al.,
1989c). Each rule-based system is composed of two basic components, the knowledge base and the data base.
The operational rules constitute the knowledge base and the data representing the graphical model forms the
data base. The data base is composed of the Prolog assertions using the predicate symbols state, evein,
eveot and arc. We indicate the type of the parameters we are intending to store as such facts.
The state facts are of the form:

state(StateIdentifier, PLCflag, Type, DrivenType, StartTime,

EndTime, Token, Parameter, LifeTime)
 H.A. Barker et al./ Microprocessing and Microprogramming 41 (1996) 737-756 745

where
StateIdentif ier: The unique name of the state.
PLCf lag: The name of the input, output port timers, self-latching state provided in the PLC hardware. The
numbering systems used for the PLC Flag differ between manufacturers.
Type : [1..51 where
1. initial state
2. system state
3. junction input
4. junction output
5. physical state
DrivenType: Another attribute of the physical state:
1. physically driven
2. user driven
Physically driven means that the physical state is activated as the result of firing other events in the
system. User driven means the physical state is activated by external actions such as button pressing.
Token: Indicates whether the current state is ‘power on’ or ‘power off
StartTime: The start clock time of the current shortest event life time
EndTime: The end clock time of the current shortest event life time, EndTime= StartTime f t,, where t, is
the shortest life time defined in the appendix
Parameter: Time defined for the timer state
LifeTime: The time value left on a timer. The initial time value, t(p) for p E TIM is the physical time
associated with timer states.
The evein and eveot relations are of the form:

evein(EventIdentifier, InputStateIdentifier).
eveot(EventIdentifier, OutputStateIdentifier).

The arc relation is defined as:

arc(ArcIdentifier, Weight, Type, InputState/EventIdentifier,

OutputState/EventIdentifier)

Weight: The weight associated with each arc.

Type : Defined as:
1. ordinary
2. inhibitor
The simulator is implemented in both C and Prolog. The calling part is written in C, and forms the main
control loop. The called part is written in Prolog, and consists mainly of the realisation of the rules given in
Section 4. The communication between C and Prolog is achieved by interprocess communication.
The calling part consists of the following essential steps:
(1) Assert the data extracted from the C data structure into the Prolog data base
746 HA Barker et aL/Microproceaing and Microprogramming 41 (1996) 737-756

(2) Invoke the predicate assert_enableEves_conflictEves_usertStas_and_flags to form

the current enable, conflict events, user driven states and corresponding flags
(3) If there are pending states driven by the user, wait for the tokens to be provided
(4) If there are conflict events, redesign the system to eliminate the conflict structure.
(5) If there are no events enabled, terminate the simulation
(6) If there are normal enabled events, invoke the predicate simulation to fire the system
(7) Feed back the updated states into the C data structure
There are two basic Prolog modules. The first module contains the predicate:

assert_enableEves_conflictEves_usertStas_and_flags

which causes the current enable, conflict events, user driven states and corresponding flags to be asserted in the
database. The main predicates concerned are defined in the Appendix B. 1.
The second module is invoked with the predicate simulation which starts the simulation according to the
PLCNet operation rules defined in Section 4. The reason that the knowledge is separated into two modules is
that the simulation has to be halted by the main control loop when the conflict events, user driven states, and all
events in the system are dead. The second module is applied only when there are enabled events available. It is
worthwhile pointing out that the implementation mirrors the specification of the PLCNet and its operational
rules in the sense that each predicate can find its counterpart in the formal definition, making the production of a
prototype simulator straightforward.

6. Simulation of PLCNets

The simulation of a PLCNet is defined as follows:

(1) The number of tokens at each state is initialized to CL,- the initial marking of the system.
(2) A sequence of event firings takes place according to operational rules; Execution halts in the following
circumstances
l no event is enabled
a waiting for a user to provide a token in user driven states
l p = Pi, that is the system reaches the final system marking Pi.
The desktop of the simulation tool based on Petri nets is shown in Fig. 6.
The pull-down menu activated by the Setup button is used to define all data necessary for the simulation.
The system can be simulated in either automatic or interactive mode. The interactive mode allows users to
simulate the system by choosing one event at a time. Whenever the automatic simulation is started, the pop-up
window shown in Fig. 6 is used to control the current session of the simulation. The life time associated with
each timer state is updated when the current shortest event life time elapses. The updated system states are
animated by the flow of tokens in the net. After the simulation, the system behaviour can be viewed or plotted
by selecting the Data View or Data Plot button on the pop-up window, activated by the Statistics button in the
Activities pull-down menu. The options System Dynamics or State Dynamics allow a user to view and plot the
token distribution of either a whole system or a specific state at a time.
 HA. Barker et al./Micraprocessing and Microprogramming 41 (195%) 737-756 747

Fig. 6. Desktop of Petri net simulation tool.

The example shown in the Fig. 6 serves to show how the simulation is carried out under the operational
rules. The simulation is composed of following steps:
(1) A token is added into state X401, which sets the initial condition for the system.
(2) Rule 1.l is used to fire the enabled event el. As a result, the token at X401 is removed and two tokens
are added to the two output virtual states,
(3) The events e2 and e4 are enabled simultaneously. After applying Rule 1.2 to each of these event, the
tokens at the input states are removed and a token is added to each of states S600, T450, S603, T451.
(4) Two virtual events are enabled simultaneously. The shortest event life time is set to 2 minutes. As the
physical state X402 is driven by the user, Rule 5.1 is applicable to the virtual event between T450 and
X402. Having fired this event, the timer 7’450 is timed out. As the physical state X403 is driven by the
output physical state T451 and t,(T451) = 5.0 > 2.0, Rule 5.2 is applicable to the virtual event between
T451 and X403. After firing the event, the life time in T451 is updated to 3.0.
748 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

X401
I I I I I I I I \
1 2 3 4 5 6 7 B 9 Slep

S600 T450

4 8 step

X402

4 step

S603 T451
I I I 5mn I t
I
1 2 3 4 5 6 7 8 9 _ step

1 2 3 4 5 6 7 a 9 slep

1 I)
S601 Y430
I I I I r I I
1 2 3 4 5 6 7 8 9 step

S604 Y431 1 1

1 2 3 4 5 6 7 8 9 - step

5605

1 2 3 J 5 6 7 8 9 step

Fig. 7. Step response.

(5) Since r,(T450) = 0.0 and X402 is driven by the user, Rule 4 is applied, which results in the state being
highlighted to prompt a token that should be added in order to proceed to the next event. After a token is
supplied in X402, there are two events enabled simultaneously, the event e3 and the virtual event
between T451 and X403. The shortest event life time t, between two events is min(0.0, 3.0}. Using Rule
1.2 to fire event e3 results in the token being removed from T450, S600, X402 and a token being added
into each of states S601 and Y430. Although the virtual event fits the firing conditions of Rule 5.2,
applying Rule 5.2 does not affect the parameter of related states because the t, is 0.0.
(6) The virtual event between T451 and X403 is the only enabled event in the system. tl is the time of the
virtual event itself. Applying Rule 5.3 results in the time in state T451 being updated as t,(T451) = 0.0
and a token added to X403.
(7) After applying Rule 1.2 to the only enabled event e5, the tokens in the states S603, T451, X403 are
removed and a token is added to each of states S604 and Y431.
(8) Event e6 is the enabled event. After applying Rule 1.2, the tokens in S601, Y430, S604, Y431 are
removed and a token is added to the state S605.
(9) The final state is reached, the current session of simulation is terminated.
The step response is shown in Fig. 7; the X axis is the simulation step and the Y axis is the token
distribution.
Another way to present the system dynamics is to use the time response in which the X axis is time instead
of the simulation step. Part of the time response for the same example is displayed in DataPlot pop-up window
 HA Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756 749

shown in Fig. 6. Both methods of presenting the output are useful for analysis of the system behaviour. In the
limiting case where no timer is involved, the time response for each state reduces to the start point, r = 0.0, and
the step response must then be used. The time response for each state shows how long the token resides in that
state and the step response for each state indicates whether or not the state is active at a certain step. By
comparing different states’ time and step responses, the time dependency and the logical dependency among
states can be clearly evaluated. Any deviations from the desirable system behaviour imply that design errors
have occurred during previous stages. By tracing back from the abnormal state the errors can be easily located.

7. Conclusions

In this paper, an integrated design approach has been taken for the construction of a simulation tool for
PLCs, which not only takes the requirements of the simulation tool into consideration, but also integrates other
tools, e.g. for modelling, implementation and transformation, and allows the use of other representations such as
ladder diagrams and Grafcet. The aim is to achieve the greatest acceptability from users who have experience
with ladder diagrams and Grafcet, without losing the information required for each tool. The PLCNet has
simpler structures, but requires more complicated operational rules, than the Petri net. A rule-based PLCNet
simulator has been designed based on the formal definitions of PLCNet and operational rules. Various facilities
are provided to set up and control the simulation. Both step and time responses are provided for the presentation
of simulation results, a facility which has proved to be useful in the analysis of system behaviour and in fault
diagnosis. In particular, the step response can be used to evaluate logical dependencies when time is not
involved in the system. The construction of PLCNets, simulation and presentation of simulation results are
embedded in the eXCeS graphical environment.

Appendix A. PLCNet definitions

A.I. Dejhition

A PLCNet is a structure (P, E, I,, I,, 0,) O,, V, t,) where P is a finite set of states which can be
partitioned into subsets
P=INIUSYSUPHY
where
IN1 is a finite set of initial states, which are usually physical components,
!5’YSis a finite set of system states, representing internal status, and
PHY is a finite set of physical states, representing physical components such as buttons, limit switch etc, which
can be further subdivided into
PHY = PHYIN V PHYOUT
where
PHYIN = USERDRIVEN U PHYDRNEN
150 HA. Barker et nl./Microprocessing and Microprogramming 41 (1996) 737-756

is a set of input physical states and PHYOUT is a set of output states

TIM G PHYOUT
is a finite set of timer states.
E=E,UE,
where EC is the set of concrete events and E, the set of virtual events.
Pr-lE=@
The connections in the graph are given by
V:(PXE)U(EXP)+{O, I}
where V has value 1 if there is an arc between states and events or vice versa and 0 otherwise.
Z, : E -+sd( P) gives the set of input states to event e
I,(e) = { P I V( P, e) = 1)
0, : E +9(P) gives the set of output states from event e
qe)={PlV(e,P)=l}
Z, : P +.9(E) gives the set of input events to state p
I,(P) = {elV(e, P) = 1}
0, : P +9(E) gives the set of output events from state p
O,(P) = {elv( p, e) = 1)
f : TIM +9’+ is the physical time associated with timer states, t(p) is the initial time value on a timer and its
value is set by users. t, : TIM *9’+ is the time left on a timer.

A.2. Definition

PHYOUT= U Z,(e)
c?CE,

A.3. Dejinition

PHYZN= u O,(e)
&E,

A.4. Definition

For eEE
PREVEVE(e) = {e’I(gsEZ,(e) flSYS)(e’EZ,(s))}
PREVEVE( e] is the finite set of immediately previous events to e.
 HA. Barker et al./ Microprocessing and Microprogramming 41 (1996) 737-756 751

A.5. Dejinition

The number of tokens at a state is given by the function:

Z.&:P+“4f
where Jy is the set of natural numbers. We call this a marking. p, and z+, are used to denote the initial and
final markings of a system.

A.6 Dejhition

E,., is the set of enabled concrete events in a system, which is defined as follows:

E,, = (e E Ec IMP E ZV(e)( 4 P) > 0) * VP E Q,(e)( P( P) = 0))

The enabling condition for the concrete event, e, is that the number of tokens in the input states of e is at least
one and the number of tokens in the output states of e is zero.

A.7. Definition

The set of enabled virtual events is defined as follows:

E,,=(eEE,IVpEZ,(e)(CL(p)>O)A~‘pEO,(e)(tL(p)=O)}

A.8. De$nition

t,(e) is the event life time for a single event e and for e E E defined as:
0 if e E EC,
t,(e) = 0 if eEE,, and Z,(e) nTZM=@

i max{t,(p)lpEZ,,(e)}
if eEE,,andZ,(e)nTIM#@

The use of the mu operator means that the event e is not ready to be fired until the longest timer in its input
states is timed out.

A.9. Dejhzition

t, is the event life time of a system, where

t, = min{ tC(e) I e E E,, U E,,)

tl is the event life time of the whole system, which is the shortest event life time among all current enabled
events. In other words after the time period t, has elapsed, at least one event in the system is ready to fire.
752 HA Barker et al./Microprocessing and Microprogramming 41 (19%) 737-756

B. Prolog modules

B.I. Module

assert_enableEves_conflictEves_userStas_and_flags:-
assert_enableEves_conflictEves_userStas,
assert-flag.

enable_concrete_event(Event):-
input_states(Event,InStas),
!r is_input_state_enable(Event,InStas),
output_states(Event, OtStas),
!, is_state_dead(OtStas),
preveve(Event, PrevEves),
(PrevEves \ == [I+
% Rule 1.2, PREVEVE(Event) \ == [}
otPhyStas_of_prevEves(PrevEves,OtPhysStasTmp),
flatten(OtPhyStasTmp, OtPhyStas),
% InStas is the input states of the current event,
% OtPhyStas is the output physical states of last events
assert(live_concrete_event(Event,O.O,InStas,OtPhyStas));
% Rule 1.1, PREVEVE(Event) ==
assert(live_concrete_event(Event,O.O,InStas,[l))

1.
% Rule 2, 3, TIM and PHYOUT(SysSta) == 11
process_one_enableVirEves_and_userStas(InStas,OtStas) :-
is_input_without_time_states(InStas),
% mu(p)> 0
!, is_state_enable(InStas),
% mu(q)=0
!, is_state_dead(OtStas),
phyin_userdriven(OtStas, PHYIN_USERDRIVEN),
(PHYIN_USERDRIVEN \ == [I-’
% Rule 2, PHYIN_USERDRIVEN(SysSta) \ == 11
assert_user_driven_state(PHYIN_USERDRIVEN);
% Rule 3, PHYIN_USERDRIVEN(SysSta) == 1)
update_virtual_event_index(No),
form_virtual_event_name(No,VirEve),
% VirEve is the name of virtual event, InStas
% and OtStas are input and output of virtual event
assert(live-virtual_event(VirEve,O.O,InStas,OtStas))
).
 HA. Barker et ul./ Microprocessing and Microprogramming 41 (1996) 737-756 153

% Rule 4, 5, TIM and PHYOUT(SysSta)=

process_one_enableVirEves_and_userStas(InStas,OtStas):-
% mu(p)>0
!, is_state_enable(InStas),
% mu(q)=0
!, is_state_dead(OtStas),
time_states(TimStas),
intersection(TimStas,InStas,InterSets),
(is_time_out(InterSets) +)
% Rule 4, ts(p')=O
phyin_userdriven(OtStas, PHYIN-USERDRIVEN),
PHYIN_USERDRIVEN=[],
assert_user_driven_state(PHYIN_USERDRIVEN);
% Rule 5, ts(p')>O
get_te(InterSets,Te),
update_virtual_event_index(No),
form_virtual_event_name(No,VirEve),
assert(live_virtual_event(VirEve,Te,InStas,OtStas))
).

B.2. Module

simulation :-
% get the shortest event life time
get_min_concurrent_time(MinConTm),
% update the clock start and end time
assert_new_clock(MinConTm),
% proceed one time piece of MinConTm
simulation_one_step(MinConTm),
% check the consistency
consistency_processing.

% Rule 1.1
simulation_one_step(_) :-
live_concrete_event(Event,O.O,InStas, [I),
rm_input_marks(InStas),
output_states(Event, OtStas),
add_output_marks(OtStas),
retract(live_concrete_event(Event,O.O ,InStas,[l)), fail.
754 HA Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

% Rule 1.2
simulation_one_step(_) :-
live_concrete_event(Event,O.O,InStas,OtPhyStas),
rm_input_marks(InStas),
output_states(Event, OtStas),
add_output_marks(OtStas),
rm_marks(OtPhyStas),
retract(live_concrete_event(Event,O.O, InStas,OtPhyStas), fail.

% Rule 3
simulation_one_step(_) :-
live_virtual_event(Event,O.O,PHYOtJT,PHYIN),
add_output_marks(PHYIN),
retract(live_virtual_event(Event,O.O,PHYOUT,PHYIN), fail.

% Rule 5.1
simulation_one_step(MinConTm) :-
live_virtual_event(Event,Ts,PHYOUT,PHYIN),
phyin_userdriven(PHYIN, PHYIN_USERDRIVEN),
PHYIN_USERDRIVEN=[],
Ts>=MinConTm,
update_ts(MinConTm,PHYOUT),
retract (live_virtual_event(Event,Ts,PHYOUT,PHYIN)), fail.

% Rule 5.2
simulation_one_step(MinConTm) :-
live_virtual_event(Event,Ts,PHYOUT,PHYIN),
phyin_userdriven(PHYIN, PHYIN_USERDRIVEN),
PHYIN_USERDRIVEN == [I,
Ts>MinConTm,
update_ts(MinConTm,PHYOUT),
retract(live_virtual_event(Event,Ts,PHYOUT,PHYIN)), fail.

% Rule 5.3
simulation_one_step(MinConTm) :-
live_virtual_event(Event,Ts,PHYOUT,PHYIN),
phyin_userdriven(PHYIN, PHYIN_USERDRIVEN),
PHYIN_USERDRIVEN == [I,
Ts =:= MinConTm,
update_ts(MinConTm,PHYOUT),
add_output_marks(PHYIN),
retract(live_virtual_event(Event,Ts,PHYOUT,PHYIN)), fail.

simulation_one_step(_) :- !.
 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756 755

References

[1] H.A. Barker, M. Chen, P.W. Grant, C.P. Jobling and P. Townsend, Interactive graphics for the computer-aided design of dynamic
systems, IEEE Control Systems Mag. 7(3) ( 1987) 19-25.
[2] H.A. Barker, M. Chen, P.W. Grant, C.P. Jobling and P. Townsend, Graphical user interfaces in computer-aided control system design,
in: D.A. Linkens, ed., CAD for Control Systems, ch. 23 (Marcel Dekker, New York, 1993) 561-578.
[3] H.A. Barker, M. Chen, C.P. Jobling and P. Townsend, Development of an intelligent man-machine interface for computer-aided
control system design and simulation, Automatica 25(2) (1989) 3 1l-3 16.
[4] H.A. Barker, P.W. Grant, C.P. Jobling, J. Song and P. Townsend, A Graphical man-machine interface for discrete-event dynamic
systems, in: Proc. 3rd European Simulation Congress, Edinburgh, U.K (1989) 356-361.
[5] H.A. Barker, J. Song and P. Townsend, A rule-based procedure for generating programmable logic controller code from graphical input
in the form of ladder diagrams, hr. J. Engineering Applications of Artificial Intelligence 2 (1989) 300-306.
[6] D. Chocron and E. Cemy, A petri net based industrial sequencer, in: Proc. IEEE Inr. Conf. and Exhibirion on Indusrrial Conrrol and
Insrrumenration (1980) 18-22.
[7] S.M. Cotter and A.T. Woodward, Designing better programs for controllers, Control and Insrrumenrarion 18(11) (1986) 75-83.
[8] GRAFCET, Function chart GRAFCET for the description of logic control systems, Technical Report Standard: NF CO3-190, Norme
Fran$aide Enregistre, 1982.
[9] K. Hasegawa and H. Ohno, Gn programming of conventional programmable controller by using mark flow graph, in: Proc. ISCAS 85
(1985).
[lo] N. Komoda, K. Kern and T. Kubo, An autonomous, decentralized control system for factory automation, Computer 17(12) (1984)
73-83.
[l 11 R. Masuda and K. Hasegawa, Mark flow graph and its application to complex sequential control system, in: Proc. Z3rh Hawaii Inr.
Co@ on Sysrem Science (1980) 194-203.
[ 121 J.L. Peterson, Perri Ners: Theory and Mode&g of Systems (Prentice-Hall, 1981).
[13] J. Song, A graphical enuironmentfor rhe design of discrere event systems, Ph.D. thesis, University of Wales, Swansea, Wales, U.K.,
1993.
[14] I. Wamock, Programmable Controllers Operation and Application (Prentice-Hall, 1988).

H. Anthony Barker was born in 1931 in Nottingham, UK, where he lived until he completed a B.Sc. degree at
Nottingham University in 1952. After periods spent in the Army, and as a graduate apprentice and project
engineer with Rolls Royce Aero Engines, he joined Cambridge University to do research in control engineering,
and obtained his Ph.D. degree in 1963. Since then he has worked in University Departments of Electrical and
Electronic Engineering, as a Lecturer at Glasgow University, a Professor at Aston University, and a Departmental
Head at the University of Wales Swansea, where he has also held the posts of Head of the School of Engineering,
Dean of the Faculty of Engineering and Vice Principal. His research interests have focused mainly on system
identification and computer-aided control engineering. An active member of his profession, he has been Chairman
of the Control and Automation Division and Vice President of the Institution of Electrical Engineers. Currently he
is President of the Institute of Measurement and Control and Chairman of the United Kingdom Automatic Control
Council.

Philip W. Grant received the B.Sc. degree in Mathematics in 1968 and the Advanced Diploma in Pure
Mathematics in 1969, both from the University of Manchester, UK. He received the D.Phil degree in 1972 in
Mathematical Logic (Computability Theory) from the University of Oxford, UK. Dr. Grant taught in the
Department of Mathematics and Computer Science at Sunderland University until 1975. Since then he has been a
lecturer and senior lecturer in the Computer Science Department at the University of Wales Swansea. In 1983-84
he taught at Cal-State Northridge and was employed as a senior research scientist with Silogic, Inc., Los Angeles.
His main research interests are logic and functional programming and the application of modem computer science
techniques to the solution of problems in control engineering.
756 HA. Barker et al./Microprocessing and Microprogramming 41 (19%) 737-756

Ji Song was born in 1963. He received a BSc. in Automatic Control at the Shanghai University of Technology in
1982 and an M.Sc. in Intelligent Control Systems from the same University in 1985. From 1985 to 1987, he was a
Lecturer in the Automation Department at Shanghai University of Technology, teaching control theory and signal
processing. From 1988 to 1991 he was a research student at the University of Wales Swansea, where he was
awarded a PhD for his work on ‘Graphical Environments for Discrete Event Dynamic Systems’. From 1991 to
1993, he was a Research Associate in the Human Computer Interaction Group at the University of York where he
developed a tool kit for the design of a mission control system based on the formal specification language LOTOS
and graphical LOTOS. Since 1993 he has been working in the fmancial software industry, and he is currently
working for the usability group of Reuters developing dealing software for foreign exchange markets.