LADDER LOGIC IMPLEMENTATION OF RAMADGEWONHAM SUPERVISORY CONTROLLER

Soumi Ray, Rashmi Vashisth, Shubham Prakash Goel, R P Pawan, Sameer Joshi, Chaitanya Sharma Amity School of Engineering and Technology, Bijwasan, New Delhi

Abstract : The aim of the project is to convert the

Ramadge Wonham Controller Framework into an equivalent Ladder Logic Diagram Programming Language. The logic is to develop an algorithm to convert a controller automaton synthesized by Ramadge-Wonham(RW) method to a ladder logic diagram. Our proposed plan takes a new look at this subject. We not only make sure that the same sequences of events can be generated by both the RW controller and its converted ladder logic (as done by other related literature), but we also guarantee the implementation of the converted ladder logic as a PLC program. The Ramadge-Wonham framework, also known as the supervisory control theory, is a method for automatically synthesizing supervisors that restrict the behaviour of a plant such that as much as possible of the given specifications are fulfilled. The supervisor observes the string of events generated by the plant and might prevent the plant from generating a subset of the controllable events. However, the supervisor has no means of forcing the plant to generate an event. The main objective is to propose a very effective and easy to use technique for the assignment of actions (output signals) to the related states of RW supervisors so as to facilitate the implementation of RW supervisors as LLD on a PLC. This methodology is based on assigning actions to some states of the RW supervisor. Once a RW supervisor assigned with actions is obtained, the conversion of this supervisor into LLD is straight forward for PLC implementation. Ladder Logic provides engineers a better edge over finite automata as it is reliable, cost effective, easy to develop, reliable and easy to understand and with a compiler can be burned into a PLC and can be used in various processes.

constructed controller is first analyzed and then a conversion procedure generates an equivalent LLD of the controller. Therefore the final LLD is guaranteed to carry the same control properties as of the constructed model. Researchers have introduced different controller construction techniques such as Petri Nets and Finite Automata. Finite Automata Analysis, introduced by Ramadge and Wonham, is a formal controller construction technique, which generates a maximally permissive controller of a DES plant and its controller specification. The technique has been very successful due to its fair mathematical structure . The conversion of RW controllers (or RW supervisor) to LLD was addressed by, which is basically the conversion of a state transition diagram to LLD. While this conversion is algorithmically true, the resulting LLD is usually not implementable, i.e. it cannot be directly run on PLC.

2. Ramadge Wonham Framework

The Ramadge-Wonham framework, also known as the supervisory control theory, is a method for automatically synthesizing supervisors that restrict the behaviour of a plant such that as much as possible of the given specifications are fulfilled. The plant is assumed to spontaneously generate events. The events are in either one of the following two categories controllable or uncontrollable. The supervisor observes the string of events generated by the plant and might prevent the plant from generating a subset of the controllable events. However, the supervisor has no means of forcing the plant to generate an event. In its original formulation the SCT considered the plant and the specification to be modelled by formal languages, not necessarily regular languages generated by finite automata as was done in most subsequent work. The work of Ramadge and Wonham (R&W) is developed around the formal regular languages generated by finite automata. R&W's plant model P is obtained by describing the plant processes in terms of a formal language which is

1. Introduction
Programmable Logic Controllers (PLC) are the main controller hardware for the control of Discrete Event Systems (DES). Ladder Logic Diagram (LLD) is the most popular programming language of PLCs. While LLDs are very useful in implementing a control policy, it is very hard to verify the control properties of a LLD-based controller. Remedy is to develop a controller with one of the formal controller construction techniques and convert the resulted model to a LLD. The

generated by a finite automaton and whose alphabet consists of the (finite) set of events. A ``means of control'' is adjoined to this ``generator'' by identifying the events that can be enabled or disabled by the controlling agent. The specifications Sp are described in terms of the formal language generated by P. Then, the controller is constructed from a recognizer, also a finite automaton, for the specified ``target'' language given by Sp .

resource-activity latch event of that activity, it is not considered as a separate I/O signal. A4. In the plant initial state, all the resources are free and no activity has been started. A5. The RW supervisor is given, and no resource conflict exists. A6. The RW supervisor events can be classified as activity or system events. A7. The starting event of every activity is known, i.e we know exactly after what string(s) this event might occur.

3. RW to LLD Conversion
An activity is any operation in a manufacturing system that takes an interval of time to complete. During this interval, a set of resources (consists of at least one resource) is used to perform the activity. Without loss of generality, we assume the starting event of each activity happens immediately after the activity obtains all the resources that it requires (in other words, the starting event of an activity can be considered as the last resource assignment event of that activity). The ending event of an activity happens when the activity is complete. The ending event is disabled if at least one of the resources assigned to an activity is freed during the activity execution. For example, an assembly operation can be considered as an activity, which has a start and an end. The resources required for an assembly operation might be robots, tools, machines, etc. A resource is an entity, which is required by at least one of the manufacturing activities. A resource-activity latch event happens when a resource is assigned to an activity. A resourceactivity unlatch event happens when a resource is taken back (or freed) from an activity. In the assembly operation example, assigning a robot to this activity is considered as a latch event of the robot for assembly operation. When the assembly is complete, the unlatch event will free the robot. A system event is any change of manufacturing system state, which is not considered as a resource latch/unlatch or activity starting/ending event. In the assembly example, a breakdown event of the robot is considered as a system event. The following assumptions are critical to our proposed conversion method: A1. The latch and unlatch events are forcible, i.e. a free resource can always be assigned and a used resource can always be freed. A2. For any activity, there exists a single event in the set of RW supervisor events, , that can be considered as the ending event of that activity. A3. All the events in the classes defined above have corresponding PLC I/O signals. Resource latch and unlatch events are outputs, and ending and system events are inputs. Because the starting event of an activity is equivalent to the last

4. Conversion Algorithm
Step 1. Initialization Let R = {1,2,...,m} denote the resource set, and A = {1,2,..., n} denote the activity set. According to the event classification mentioned above, divide , the event set of the RW supervisor S = (X ,X m ,x0 , , ) into three disjoint sets: activity starting events set s , activity ending events set f and system events set sm . Step 2. Extended Supervisor Construction For any pair of states x1, x2 X , where x2=( fa, x1) and fa a is the ending event of activity a A, if no starting event for activity a is in s , then denote this event by sa and add it to s. Accordingly add a new state, say y , to X and define the following transitions: y =(sa ,x1) and x2 = (fa, y). Define activity-resource vector ARa for every a A .The size of this vector is m , and ARa(r)= 1 , r R , if activity a uses resource r ; ARa(r)= 0 , otherwise. Define state-resource vector SRx for every x X . The size of this vector is m and it is constructed by the following procedure: (a) SRx0=0, M={x0} x0 , { } 0 M x (b) Select x X - M where (, y) = x , y M and s U f U sm Generate SRx as follow: (i) If = sa then r R : SRx(r)=1 if ARa(r) =1 SRx(r)=SRy(r) otherwise (ii) If = fa then r R : SRx(r)=0 if ARa(r) =1 SRx(r)=SRy(r) otherwise (iii) If sm then r R : SRx(r)=SRy(r). Add x to M . (c) If X M then go to (b), otherwise stop. - Attach the State-Resource Vector SRx to every state x X . The new supervisor is called Extended Supervisor. Step 3. Conversion Use the following rules and convert the extended supervisor to a ladder logic diagram.

(1) Build an initialization rung, with one initialization input contact and one latched coil for state 1 (initial state of RW controller) in the output. The initialization input contact is used to initialize the ladder logic. This contact can be imagined as Run command received by the PLC. Let M = (2) Select state x X -M ; for each outgoing event from x , create a rung with the following inputs and outputs: Inputs: {es,x} if (s) (N>1) (Ns1) I= {x} if (s) (N=1) {x,} otherwise Outputs: OL ={{ r| SRy(r)=1 SRx(r)=0}, y|y = (,x)}; OU ={{ r| SRy(r)=0 SRx(r)=1}, x}; Where N ---- the number of outgoing events in state x, I ---- input normally open contacts in LL, OL ---- latched output coils, OU ---- unlatched output coils, Ns ---- the number of outgoing activity starting events in state x, es ---- a conflict resolution signal that selects among several activity starting events available in state x . (3) Add x to M, if M=X, then stop; else go to (2). Our main assumption is that the DES plant executes a set of activities to accomplish its mission. Each activity uses at least one resource. The objective of the plant controller (here LLD controller) is to assign/free the resources to/from activities to restrict the plant to a predefined set of control constraints. In Step 1, after identifying the sets of resources and activities, we recognize the corresponding starting and ending events of activities in . All other events in are considered as system events. The permissive RW controller is modified to an extended controller in Step 2. Here, missing activity starting and ending events are added to complete the activity execution cycle for each activity. The activity resource vector is used to show the utilization of resources by activities, and the state-resource vector to show the resource utilization status in each state. The system event doesnt affect the state- resource vector, while the occurrence of starting events and ending events does. The former one implies the corresponding resources are in use; the latter one leads to resources release. By assumption A5, it is impossible that a resource is assigned different. SRx in one state by different events. The idea behind the extended controller is to identify the required forcing events when a plant state change is observed. In fact the extended model establishes a relation (using the activity resource vectors)

between the events in and the events that need to be forced, i.e. resource latch/unlatch events. If the RW controller enables a system event, no resource event is forced. On the other hand, if activity events are enabled, then the necessary latch /unlatch resource events are considered. In Step 3, we convert the extended model to LLD. Except the first rung, the initialization rung, which sets the controller to its initial state, all other rungs consist of the following types of input contacts and output coils. Four types of input contacts are used: activity ending contact (corresponding to activity ending event), system contact (corresponding to system event), conflict resolution contacts that are used to decide between different alternatives that might become available to LLD controller, and state memory contact showing the current state of the RW controller. Output coils latch/unlatch the resources and control the active state of the RW controller. In every state of the RW controller, depending on the number and type of the outgoing events, one or several rungs are defined. If all the outgoing events are activity ending or system events, then the controller does not force any resource and it listens to input signals. An incoming input (which is already enabled by RW controller) changes the state of LLD. If the only outgoing event is an activity starting event, then the required resources are latched immediately and the RW controller state is updated. If more than one outgoing activity-starting event exists, conflict resolution signals are used to select one of them. In this paper we assume an external agent provides these signals. These signals also resolve the situation in which the LLD controller has to decide between listening to activity ending/system events and forcing resources to start an activity. This case arises when the set of outgoing events from the current state has both types of activity starting and system/activity ending events. It is easy to show that the extended controller is equivalent to the original controller in terms of control policy. The original RW controller only includes the activity and the system events. In the extended model we add the latch or unlatch events to assign or free the required resources for each activity event, and define some activity events to complete the activity execution cycle. Therefore, for enabled activity events we assign the required resource to make it possible to happen, which is consistent with the enabling control action in RW controller. Similarly, for the disabled activity event by not assigning the necessary resource, we do not let that activity event occur, which is equivalent to disabling control action in RW controller. It is concluded that the converted LLD preserves the properties of its original RW controller. It is also found that the LLD controller is ready for use on a PLC because it has all required I/O elements.

5. Example
Event Category Latch event (Assign a resource) Figure 1 : Manufacturing Process In this plant, incoming parts go through a two-step manufacturing process done by Machines 1 and 2. An intermediate buffer can hold the output parts of Machine 1, which should be processed by Machine 2. Two specifications are imposed on this system: (1) Machine 2 has repair priority over Machine 1 in case both the machines are down; (2) the number of parts in buffer can be either 0 or 1. The RW supervisor of this example is given in Figure. A description of the supervisor events can be obtained from Table. In the Initialization step we identify the activities and resources and their respective events. In the second step, we construct the Extended Supervisor. In this example the starting events of activities are equivalent to the resource-activity latch events because each activity in this system needs only one resource. Since r1 is the ending event of repair on Machine 1, and the corresponding starting event sr1 is not shown in the given supervisor, we add this event and we define a new state, 13. We remove (r1 ,12) and add (r1 , 12) 13 and (r1,13) =1. In a similar way event sr2 , and states 14, 15 and 16 are created and the transition function is accordingly revised. Machine1 (denoted as 1) Machine 2 (denoted as 2) repairman (denoted as 3) operation on Machine 1 (1) operation on Machine 2 (2) repair work on Machine 1 (3) repair work on Machine 2 (4) Table 1 : Activity and Resource Unlatch event (Free a resource) M1 M2 R1 Events M1 M2 R1 R2 Machine 1 is assigned Machine 2 is assigned Repairman is assigned to Machine 1 Repairman is assigned to Machine 2 Machine 1 is freed Machine 2 is freed

Repairman is freed from repair work R2 on Machine 1 Repairman is freed from repair work on Machine 2 Starting s1 Operation starts on event s2 Machine 1 (Starting sr1 Operation starts on an activity) sr2 Machine 2 Repair starts on Machine 1 Repair starts on Machine 2 Ending f1 Operation ends on event f2 Machine 1 (Ending r1 Operation ends on an activity) r2 Machine 2 Repair ends on Machine 1 Repair ends on Machine 2 System b1 Machine 1 breakdown event b2 Machine 2 breakdown Table 4.2 : Event Description

Resources

Activities

Figure 3: Extended Model State Transition Diagram

Figure 2: RW Controller State Transition Diagram

We convert the extended supervisor to ladder logic. The result of this conversion is given in Figure 4.

In the initialization rung, rung 1, the initialization input contact is set as input, and the initial state 1 is latched. Next, we select state 1 to process. In state 1 there is only one outgoing event s1 (N=1), which is a starting event. So we create one rung for it, rung 2, where state 1 memory contact is the input; and the output is to latch resource M1 coil and state 2 coil, and unlatch state 1 coil. Now, M ={1}. Then, we process state 2, where there are two outgoing events (N=2) f1 and b1, and none of them is a starting event. We create two rungs, rung 3 for f1and rung 4 for b1. The input of rung 3 is the memory contact of state 2 and f1 itself, and the output is to latch state 3 coil and unlatch state 2 coil. Similarly, in rung 4, we set the memory contact of state 2 and b1 as input, and latch state 12 coil and unlatch state 2 coil in the output. Let us take a look at rungs 6, 7 and 8, which correspond to state 4, where three events s1, f2 and b2 are enabled. Of these, s1 is a starting event. So in rung 6, we add an external signal in the input. This is because we need to choose whether to force Machine 1 to start, or to wait for the signals from Machine 2 that it has either finished the process or it has broken down. We notice that the ladder logic of Figure 4 is implementable, i.e. all the input contacts have their corresponding input signals, all the latch /unlatch elements have their corresponding output signals. At the same time this controller preserves all the properties of the original RW supervisor.

Having done with this exercise we notice that the ladder logic of Figure 3 is implementable, i.e. all the input contacts have their corresponding input signals, all the latch /unlatch elements have their corresponding output signals. At the same time this controller preserves all the properties of the original RW supervisor. We notice the implementation of the ladder logic is different from the ladder logic implementation of for the example. In, the corresponding events of the ladder logic contacts are not necessarily I/O PLC signals. In fact the design criterion of the ladder logic suggested by is a system state change, which is not necessarily corresponding with a single I/O signal. At the same time, due to one to one relationship between the events and I/O signals in, only one input signal might be received by PLC at any scan time. The implementation of the designed ladder logic does not have this limitation. In addition to RW controller automaton, we also used the manufacturing resource information as inputs to the conversion algorithm. The resource information was used to define the forcing mechanisms of LLD controller that are not covered by RW controller. We also discussed how the conversion preserves the properties of the original RW controller. We presented two illustrative examples, one of which was implemented by our research group. Our current research focuses on the fault diagnosis and analysis of the converted LLD using the properties of its original RW controller. We are also interested in identifying the conditions under which a given LLD can be converted to an RW controller. This can be considered as an inverse of the proposed conversion process.

7. References
[1] M. Fabian, A. Hellgren, PLC-based Implementation of Supervisory Control for Discrete Event Systems, Proceedings of the 37the IEEE conference on Decision & Control, Tampa, Florida, USA, Dec. 1998. [2] B. A. Brandin, The Real-Time Supervisory Control of an Experimental Manufacturing Cell, IEEE Transactions on Robotics and Automation, Vol. 12, No.1, Feb. 1996. [3] J. Zaytoon, Specification and Desgin of Logic Controllers for Automated Manufacturing Systems, Robotics & Computer-Integrated Manufacturing, Vol. 12, No. 4, pp. 353-366, 1996. [4] A. Ramirez-Serrano, S.C. Zhu, S.K.H. Chan, S.S.W. Chan and B. Benhabib, A Hybrid PC/PLC Architecture for Manufacturing System ControlImplementation, 2000 IEEE International Conference on Systems, Man, and Cybernetics, Vol.3, 2000. [5] T. Krairojananan and S. Suthapradit, A PLC

Figure 4: The Converted LLD of the Example

6. Conclusion

Program Generator Incorporating Sequential Circuit Synthesis Techniques, 1998 IEEE AsiaPacific Conference on Circuits and Systems, 1998. [6] M. Uzam, A. H. Jones, Towards a Unified Methodology for Converting Colored Petri Net Controllers into Ladder Logic Using TPLL: Part IMethodology, in WODES96-The 3rd Workshop on Discrete Event Systems, Edinburgh, Scotland, UK, 1996.