Barker 1996 Micro Processing and Micro Programming

8/9/2019 Barker 1996 Micro Processing and Micro Programming

1/20

EISVIER

MicroprocessingandMicroprogrammingMicroprocessing and Microprogramming 41 (1996) 737-756

A graphical simulator for programmable logic controllers basedon Petri netsH.A. Barker, P.W. Grant * J. Song

Departm ents o f Electrical and Electronic Engineering and of Computer Science, Uniuersiry of W ales, Sw ansea, Singleton Park, Sw ansea,SA2 8PP, UK

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

AbstractIn 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 forthe 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. IntroductionIt has been over a decade since Petri nets [12] were first applied in process control. As early as 1980, acompiler 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 primitivegraphical display, were developed, based on a marked flow graph, a subset of the Petri net model. The simulatorwas used to eliminate deadlock in control systems [ 111. Later this work was transferred to programmable logiccontrollers (PLCs), the first application of this type being described by 191. Based on their work, a C-net wasproposed at Hitachi to design a station controller, the cell level of their factory automation project [lo]. Petrinets have also been used to replace conventional ladder diagrams in the design of programs for PLCs [7]. This

l Corresponding author. Email: [email protected]/%/%15.00 0 1996 Elsevier Science B.V. All rights reservedSSDI 0165-6074(95)0003 1-3


2/20

738 HA . Barker et al./Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756

work shows that the Petri net is a powerful representational method for the modelling, simulation andprogramming of PLCs.There are, however, still many important aspects which have not been fully investigated. PLC applicationsare mainly restricted to sequential control processes, and modelling often depends on the users personalunderstanding of the system and interpretation of the Petri net, resulting in different representations for the samesystem. A systematic modelling methodology is not yet available and the method of presentation of simulationresults is limited to the flow of tokens.

In this paper an extended Petri net, the program mable logic controller net (PLCNet), will be introduced anda set of operational rules used to simulate PLCNets. A rule-based simulator is designed which follows closelythe definitions of the PLCNet and its operational rules. Various facilities are used to set up and control thesimulation and time and step responses are used to present the simulation results. The simulator is embedded inan interactive graphical environment, the Control Engineering workstation (CES) [ 1,3,4]. This has beendeveloped as a general purpose graphical environment for the design, simulation and implementation ofdynamic systems, particularly for control. More recently, a thorough redesign and reimplementation of CESusing the X windows environment has been undertaken which is called extended X-based Control engineeringworkstation (eXCeS) [2].

2. eXCeSeXCeS 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 runconcurrently 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 beendeveloped based on Petri nets. At the cell level, modelling, simulation, implementation and transformation toolshave been designed for PLC applications based on three graphical models - Petri nets, ladder diagrams [ 141 andGrafcet [8]. The modelling tools allow users to construct control processes graphically. The simulation toolsallow logical errors to be detected and corrected before the implementation phase. The implementation toolsprovide a graphical programming environment in which various PLC codes can be generated directly from thegraphical models. Transformation tools allow one kind of graphical model to be converted into another so thatusers can work with their preferred representation, yet still access others [13]. This paper, however, describesonly 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 anexample. A wagon is initially at rest. When the start button Xl is pressed, the wagon moves forward. As aresult, 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 encounterthe limit switch X2. This external event is modelled by e3. When the limit switch X2 is encountered, the


3/20

HA . Barker et al./ Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756 739

Xl

0

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 bemodelled 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 atoken to Sl and Y 1. The removal of the token by el indicates that the button has been released, the token at Slthat the system reaches a new stage. This system stage denotes that the wagon is moving forward. The token atY 1 models the motor being energised. The enabling conditions for e3, require a token at Y 1 and no token atX2. These two conditions are met by the current status of the system illustrated in Fig. 1. Event e3 is thereforeenabled, which means the wagon encounters the limit switch X2. The firing of e3 will remove the token at Y 1and 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 oftokens remains constant. The token at X2 represents that the limit switch is energised, the token at Y 1 themotor is still energised when the wagon encounters the limit switch X2. This observation conforms with thephysical reality. Now the event e2 is enabled. The firing of e2 removes the tokens at Sl, Y 1 and X2 and addsa token to S2 and Y 2. The firing of e2 models the wagons movement backwards. The removal of the token atY 1 indicates that the motor is de-energised. The removal of the token from Sl and the addition of the token toS2 models that the system status is transformed from the wagon moving forward to the wagon movingbackward. 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 Y 2, and the physical input states (PHYIN) X 1 and X2. As some physical input states areinitiated by users and others by the actions of physical output states, two sub-categories are identified - userdriven 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 areinternal events and e3 is an external event.

The disadvantage of the representation above is its complexity. Even for the simplest of control systems thecomplexity of the resultant model is evident. The size of a model soon becomes overwhelming in modelling reallife control systems. A complicated model is not only hard for users to understand, but also requires morecomputational resources. However, these disadvantages can be overcome by transforming the Petri net to asimplified form. The idea behind the transformation is to remove some parts of the Petri net and toautomatically generate the missing components from the existing ones. The corresponding semantics, defined bythe Petri net operational rules, has to be modified to reflect these structural changes.


4/20

740 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

YI e3 x2 Y2Fig. 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 virtualevent (E, ). Ordinary events in a Petri net are then referred to as concrete events (Ec). The semantics of virtualevents 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. Thefiring of e3 will remove the token at Y 1 and add a token back to Y 1 at the same step. A virtual event isrepresented 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 e2backward to X2, from X2 to e3 and finally from e3 to Y 1. The derived Petri net for the sequential process istherefore as shown as Fig. 3.This synthesis technique is, however, not applicable to the situation where the physical output state willenergise 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 followingprocedure: trace from e6 backwards to Y4, from Y4 to e3 and e5, from e3 to Y 1 and from e5 to Y 3. Twomissing input states are found - Y 1 and Y 3. However, according to Fig. 4 only Y 3 is a missing input state andso a modified search strategy has to be devised. This time an additional search is required, which involves

Yl e3 x2Fig. 3. PLCNet for the sequential process.


5/20

HA . Ba rker et al. /Mi croprocessing and Mi croprogramm ing 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, Y3is 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 ingray, cannot be omitted because the above synthesis technique will exclude Y 1 as not being an input state ofe6.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.


6/20

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 isgiven in Definition 1 of the Appendix A.

4. Synthesis of operational rulesGenerally 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 thePetri 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 outputphysical states of the previous event.

In what follows, the generic operational rules are formally synthesized. In addition, time is also taken intoconsideration. Rule 1 is applied to concrete events. Rules 2-5 are applied to virtual events. Rules 2 and 3 areapplied to a virtual event with no timer state as input. Rules 4 and 5 are used for a virtual event with a timerstate as input.Rule IThis rule is defined for concrete events. Two sub-rules are defined for Rule 1 which are applicable for e E ECwhen 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 situationsdepending upon whether the concrete event has zero or greater than zero previous events. Here and below, pindicates 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

ifeE 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), theevent is enabled. Rule 1.1 applies to an event with initial states as its input states. Event el in Fig. 2 is such anexample 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 isapplied to an event with previous events. In addition to the operations performed by Rule 1.1, it also removesthe tokens from the latched output physical states of the previous events. e2 in Fig. 2 is such an example in


7/20

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 notoken at the remaining states of the system. Applying the rule will not only remove tokens at Sl and X2, butalso remove the token at Y 1. Intuitively, after the wagon encounters the limit switch X2, the motor causing thewagon to move forward will be de-energised and the wagon will leave X2.Rule 2For 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 outputstates of e are dead and some output states are user-driven, then wait for users to add a token for output states toproceed with the simulation.Rule 3For 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 byphysical 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 4For GEE,,

vpE~a(e)(CL(p)>O)AvqE~~~n~,(e)(r,(q)=O)AO,(e)GlJSERDRrVENAVpEO,(e)( p(p)=O)+ wait users actionswhere 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 arethat 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,,


8/20

144 HA . Barker e! al./Mi croprocessing and Mi croprogramm ing 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 statesare 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.2O,(e)nPHYDRZVENf$ AVpEZg(e)nTZM(t,(p)>f,)+VpEZ&) nTZM(C(p) =&(P) -4)

Rule 5.3O,(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 thesmallest event life time. I,, and its output states are all driven by users. Applying Rule 5.1 will reduce timerstime 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 timerstates is greater than the smallest event life time, r, and at least one output state of a virtual event is a physicallydriven 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 tothe smallest event life time. As a result, applying Rule 5.3 to the virtual event will not only reduce the timerstime by t,, but also add a token to each of the physically driven states of the virtual event.

5. Rule-based PLCNet simulatorRule-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 an d ar c. We indicat e the type of the par amet ers we ar e intending to st ore as su ch facts.

The state facts ar e of th e form:

sta te(Stat eIdentifier, PLCflag, Type, DrivenType, Star tTime,EndTime, Token, Parameter, LifeTime)


9/20

H.A. Barker et al./ Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756 745

whereStateIdentif 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. Thenumbering systems used for the PLC Flag differ between manufacturers.Type : [1..51 where1. initial state

2. system state3. junction input4. junction output5. physical state

DrivenType: Another attribute of the physical state:1. physically driven2. user drivenPhysically driven means that the physical state is activated as the result of firing other events in thesystem. 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 offStartTime: The start clock time of the current shortest event life timeEndTime: The end clock time of the current shortest event life time, EndTime= Star tTime f t,, where t, is

the s hortest life time defined in the appendixParameter: Time defined for the timer stateLifeTime: The time value left on a timer. The initial time value, t(p) for p E TIM is the physical timeassociated with timer states.

The evein and eveot relations are of the form:evein(EventIdentifier, InputStateIdentifier).eveot(EventIdentifier, OutputStateIdentifier).

The arc relation is defined as:ar c(ArcIdentifier, Weight, Type, Input Sta te/EventIdentifier,

OutputState/EventIdentifier)

Weight: The weight associated with each ar c.Type : Defined as:

1. ordinar y2. inhibitor

The simulator is implemented in both C and Prolog. The calling part is written in C, and forms the maincontrol loop. The called part is written in Prolog, and consists mainly of the realisation of the rules given inSection 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


10/20

746 HA Barker et aL/M icroproceaing and Microprogramming 41 (1996) 737-756

(2) Invoke th e predicat e ass ert _enableEves_conflictE ves_user tSt as_an d_flags to formthe curren t enable, conflict events, user driven sta tes an d corr esponding 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 structureThere are two basic Prolog modules. The first module contains the predicate:

assert_enableEves_conflictEves_usertStas_and_flagswhich causes t he curr ent enable, conflict events, user driven states and corresponding flags to be asserted in thedatabase. 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 thePLCNet operation rules defined in Section 4. The reason that the knowledge is separated into two modules isthat the simulation has to be halted by the main control loop when the conflict events, user driven states, and allevents in the system are dead. The second module is applied only when there are enabled events available. It isworthwhile pointing out that the implementation mirrors the specification of the PLCNet and its operationalrules in the sense that each predicate can find its counterpart in the formal definition, making the production of aprototype simulator straightforward.

6. Simulation of PLCNetsThe 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 followingcircumstances

l no event is enableda waiting for a user to provide a token in user driven statesl 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 tosimulate the system by choosing one event at a time. Whenever the automatic simulation is started, the pop-upwindow shown in Fig. 6 is used to control the current session of the simulation. The life time associated witheach timer state is updated when the current shortest event life time elapses. The updated system states areanimated by the flow of tokens in the net. After the simulation, the system behaviour can be viewed or plottedby selecting the Data View or Data Plot button on the pop-up window, activated by the Statistics button in theActivities pull-down menu. The options System Dynamics or State Dynamics allow a user to view and plot thetoken distribution of either a whole system or a specific state at a time.


11/20

HA . Barker et al./Mi craprocessing and Mi croprogramm ing 41 (195%) 737-756 747

The example shown in the Fig. 6 serves to show how the simulation is carried out under the operational

Fig. 6. Desktop of Petri net simulation tool.

rules. The simulation is composed of following steps:(1)(2)(3)(4)

A token is added into state X401, which sets the initial condition for the system.Rule 1 l is used to fire the enabled event el. As a result, the token at X401 is removed and two tokensare added to the two output virtual states,The events e2 and e4 are enabled simultaneously. After applying Rule 1.2 to each of these event, thetokens at the input states are removed and a token is added to each of states S600, T450, S603, T451.Two virtual events are enabled simultaneously. The shortest event life time is set to 2 minutes. As thephysical state X402 is driven by the user, Rule 5.1 is applicable to the virtual event between T450 andX402. Having fired this event, the timer 7450 is timed out. As the physical state X403 is driven by theoutput physical state T451 and t,(T451) = 5.0 > 2.0, Rule 5.2 is applicable to the virtual event betweenT451 and X403. After firing the event, the life time in T451 is updated to 3.0.


12/20

74 8 HA. Barker et al./Microprocessing and Microprogramming 41 (1996) 737-756

(5)

(6)(7)(8)(9)

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

S600 T450

X402

4

4

8 step

stepS603 T451 I I I 5mn I I t

1 2 3 4 5 6 7 8 9 _ step

1 2 3 4 5 6 7 a 9 slepS601 Y430

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

S604 Y431 1 1

56051 -3 4 5 6 7 8 9 step

1 2 3 J 5 6Fig. 7. Step response.

7 8 9 step

Since r,(T450) = 0.0 and X402 is driven by the user, Rule 4 is applied, which results in the state beinghighlighted to prompt a token that should be added in order to proceed to the next event. After a token issupplied in X402, there are two events enabled simultaneously, the event e3 and the virtual eventbetween T451 and X403. The shortest event life time t, between two events is min(0.0, 3.0}. Using Rule1.2 to fire event e3 results in the token being removed from T450, S600, X402 and a token being addedinto 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.The virtual event between T451 and X403 is the only enabled event in the system. tl is the time of thevirtual event itself. Applying Rule 5.3 results in the time in state T451 being updated as t,(T451) = 0.0and a token added to X403.After applying Rule 1.2 to the only enabled event e5, the tokens in the states S603, T451, X403 areremoved and a token is added to each of states S604 and Y431.Event e6 is the enabled event. After applying Rule 1.2, the tokens in S601, Y430, S604, Y431 areremoved and a token is added to the state S605.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 tokendistribution.

Another way to present the system dynamics is to use the time response in which the X axis is time insteadof the simulation step. Part of the time response for the same example is displayed in DataPlot pop-up window


13/20

HA Barker et al./Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756 749

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

7. ConclusionsIn 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 othertools, e.g. for modelling, implementation and transformation, and allows the use of other representations such asladder diagrams and Grafcet. The aim is to achieve the greatest acceptability from users who have experiencewith ladder diagrams and Grafcet, without losing the information required for each tool. The PLCNet hassimpler structures, but requires more complicated operational rules, than the Petri net. A rule-based PLCNetsimulator has been designed based on the formal definitions of PLCNet and operational rules. Various facilitiesare provided to set up and control the simulation. Both step and time responses are provided for the presentationof simulation results, a facility which has proved to be useful in the analysis of system behaviour and in faultdiagnosis. In particular, the step response can be used to evaluate logical dependencies when time is notinvolved in the system. The construction of PLCNets, simulation and presentation of simulation results areembedded in the eXCeS graphical environment.

Appendix A. PLCNet definitionsA.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 bepartitioned into subsets

P=INIUSYSUPHYwhereIN1 is a finite set of initial states, which are usually physical components,!5YSs a finite set of system states, representing internal status, andPHY is a finite set of physical states, representing physical components such as buttons, limit switch etc, whichcan be further subdivided into

PHY = PHYIN V PHYOUTwhere

PHYIN = USERDRIVEN U PHYDRNEN


14/20

150 HA. Barker etnl./Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756is a set of input physical states and PHYOUT is a set of output states

TIM G PHYOUTis 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 itsvalue 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. DefinitionFor eEE

PREVEVE(e) = {eI(gsEZ,(e) flSYS)(eEZ,(s))}PREVEVE( e] is the finite set of immediately previous events to e.


15/20

HA . Barker et al./ Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756 751

A.5. DejinitionThe number of tokens at a state is given by the function:

Z.&: +4fwhere Jy is the set of natural numbers. We call this a marking. p, and z+, are used to denote the initial andfinal 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 leastone 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$nitiont,(e) is the event life time for a single event e and for e E E defined as:

i

0 if e E EC,t,(e) = 0 if eEE,, and Z,(e) nTZM=@

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 inputstates is timed out.A.9. Dejhzition

t, is the event life time of a system, wheret, = 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 enabledevents. In other words after the time period t, has elapsed, at least one event in the system is ready to fire.


16/20

752 HA Barker et al./Mi croprocessing and Mi croprogramm ing 41 (19%) 737-756

B. Prolog modulesB.I. Moduleassert_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 eventsassert(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) == 11process_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 eventassert(live-virtual_event(VirEve,O.O,InStas,OtStas))).


17/20


18/20

754

% Rule 1.2HA Barker et al./Mi croprocessing and Mi croprogramm ing 41 (1996) 737-756

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 3simulation_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.1simulation_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.2simulation_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.3simulation_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(_) :- !.


19/20

HA . Barker et al./M icroprocessing and Mi croprogramm ing 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 dynamicsystems, IEEE Cont rol Syst ems Ma g. 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 Syst ems, 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 1 -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 Sim ulat ion 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 inputin the form of ladder diagrams, hr. J. Engineering Applications of Artificial Int elligence 2 (1989) 300-306.[6] D. Chocron and E. Cemy, A petri net based industrial sequencer, in: Proc. IEEE I nr. Conf. and Exhibi rion on Indusrrial Conrrol and

Insrrumenratio n (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, NormeFran$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, Compu ter 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 Haw aii Inr.Co@ o n Sysrem Science (1980) 194-203.[121 J.L. Peterson, Perri Ners: Theory and Mo de&g of Sys tem s (Prentice-Hall, 1981).

[13] J. Song, A graphical enuironmentfor rhe design of discrere event syst ems, Ph.D. thesis, University of Wales, Swansea, Wales, U.K.,1993.[14] I. Wamock, Programmable Controllers O peration and Applicat ion (Prentice-Hall, 1988).

H. Anthony Barker was born in 1931 in Nottingham, UK, where he lived until he completed a B.Sc. degree atNottingham University in 1952. After periods spent in the Army, and as a graduate apprentice and projectengineer 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 andElectronic Engineering, as a Lecturer at Glasgow University, a Professor at Aston University, and a DepartmentalHead 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 systemidentification and computer-aided control engineering. An active member of his profession, he has been Chairmanof the Control and Automation Division and Vice President of the Institution of Electrical Engineers. Currently heis President of the Institute of Measurement and Control and Chairman of the United Kingdom Automatic ControlCouncil.

Philip W. Grant received the B.Sc. degree in Mathematics in 1968 and the Advanced Diploma in PureMathematics in 1969, both from the University of Manchester, UK. He received the D.Phil degree in 1972 inMathematical Logic (Computability Theory) from the University of Oxford, UK. Dr. Grant taught in theDepartment of Mathematics and Computer Science at Sunderland University until 1975. Since then he has been alecturer and senior lecturer in the Computer Science Department at the University of Wales Swansea. In 1983-84he 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 sciencetechniques to the solution of problems in control engineering.


20/20

756 HA . Barker et al./Mi croprocessing and Mi croprogramm ing 41 (19%) 737-756

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

Barker 1996 Micro Processing and Micro Programming

Documents

Transcript of Barker 1996 Micro Processing and Micro Programming