UML design and AWL programming for reconfigurable control softwaredevelopment of a robotic manipulator

M. BruccoleriDipartimento di Tecnologia Meccanica,Produzione e Ingegneria GestionaleUniversita degli Studi di Palermo

Viale delle Scienze - 90128manbrugdtpm.unipa.it

U. La CommareDipartimento di Tecnologia Meccanica,Produzione e Ingegneria GestionaleUniversita degli Studi di Palermo

Viale delle Scienze - 90128ulacomma@dtpm.unipa.it

Abstract

The goal of the presented research is to face thetopic of reconfigurable control software developmentin a concrete fashion, i.e., by presenting a controlsoftware system development approach which has beenused for a specific, although easy to be generalized,robotized manufacturing cell component. In particular,a methodology for the control software development ofa planar robot (2-degrees offreedom) is presented,from the conceptual design to the actualimplementation. The methodology suggests UML andobject-oriented modeling andprogramming techniquesfor the design phase, while AWL programminglanguage run by a PLC for the implementation phase.The analysis has been conducted considering theinternal and external requirements of themanufacturing system which comprises the robot,mostly driven by the contemporary industrial need ofreconfigurable control systems, critical key to succeedin the new era ofmass customization.

1. Introduction

A control system needs to confer to themanufacturing system capabilities for easyupgradability and integrability with new components.The manufacturing system should be able to be easilyre-configured to process different part types or atdifferent production rates. Flexibility and re-configurability are primarily based on easy usability,modularity, reusability, and scalability of the controlsystem itself. While for high level control activities

C. D'OnofrioDipartimento di Tecnologia Meccanica,Produzione e Ingegneria GestionaleUniversita degli Studi di Palermo

Viale delle Scienze - 90128cdonofriogdtpm.unipa.it

F.M. RaimondiDipartimento di Ingegneria dell'Automazione

e dei SistemiUniversita degli Studi di Palermo

Viale delle Scienze - 90128raimat@dias.unipa.it

(SCADA, scheduling, planning, etc.) many approachesfor developing flexible and reconfigurable controlsoftware can be found in literature, the low levelcontrol system still presents some difficulties.

From a low-level control perspective, themanufacturing control system has to perform mainlylow-level coordination activities (task planningactivities) such as synchronization of shop-floordevices like actuators and sensors. Considering arobotized manufacturing cell, the control issuesconcern the coordination of the cell hardwarecomponents in order to achieve a given task plan. Inmost cases, the planner is a sequence controller thatcontrols I/O variables by using simple algorithms orprograms. These sequence and synchronizationcontrollers are usually programmed in the PLClanguage or in a common general purposeprogramming language (if the task plan is run by aPC). Ladder diagrams (LD), functional block diagramFBD), structured text (ST), and instruction list (IL) arethe most utilized modeling and programming languagefor PLC-based controller. They are very easy-to-useand relatively familiar to the shop floor personnel.Also, Petri nets (PN), state-charts, and finite statemachine diagrams have been extensively applied forpreliminary phases of the control system developmentsuch as specification, design, verification, andperformance evaluation of discrete event controlsystems, despite they employ a process-based model,which does not fully correspond to the controlprogramming behavior. As far as the main requirementis to develop reconfigurable cell-level control softwarethat is reconfigurable in its basic components, objectoriented (00) modeling techniques are widely

0-7803-9402-X/05/$20.00 © 2005 IEEE 331 VOLUME 1

proposed in the scientific literature for the conceptualmodeling phase of the control software developmentbecause of their well recognized features related tosoftware modularity, rapid prototyping, and re-use.Indeed, these features represent crucial enablers forcontrol system reconfiguration and flexibility.

However, one main concern arises. It is related tothe significant gap which exists between the objectoriented conceptual model or design of the controlsoftware and its actual implementation. Indeed, whilegeneral purpose programming languages, for PC-basedcontrol software, encapsulating object oriented featureare surely available (e.g. C++), concerning a PLCbased control system, AWL instruction listprogramming language, for instance, do not includeobject oriented features.

The aim of the research presented in this paper ismainly focused on proposing an integratedmethodology which adopts an object-oriented approachfor modeling and designing the control systemencapsulating reconfiguration capabilities and theAWL instruction list programming language for itsimplementation. Specific attention has been given tothe concern above mentioned related to the integrationof the two development phases.

The authors propose the unified modeling language(UML) as tool for the design and modeling of thecontrol system itself, while AWL (the standardSiemensg for IL representation) for its implementationin PLC-based embedded control systems. Also, it isshown how the use of UML and its activity diagramsmakes easier the trade off between the design and theprogramming phases.

The paper is structured as follows. Section 2overviews the context of the research presented in thispaper. The control system requirements and thedescription of the test case which has been used in thisresearch are presented in section 3, while section 4shows how the proposed methodology has beenapplied for a PLC-oriented AWL-based control system.Conclusions and further remarks are drawn in the lastsection.

2. Research context

A robotized manufacturing cell consists of acollection of manufacturing, material handling, control,and auxiliary equipments that are needed tomanufacture a specific part type or, more generally, apart family.

Depending on the manufacturing goal, on therequired flexibility, automation, and productivity, arobotized manufacturing cell can consist of differentnumbers and different kinds of manufacturingequipments (machining stations), auxiliary fixtures,material handling systems (robots and transportationsystems), and control systems (relays, PLCs, PCs, etc.).

In particular the cell control system architecturedepends mainly on the structure and configuration ofthe cell itself. As an example, if the manufacturing cellconsists of many and different kinds of equipments, itscontrol system probably needs to include severalhardware devises like PLCs or PCs.

Also, depending on the functionality requirementsof the cell governance policy, the control softwarecould consist of various kinds of modules. Forinstance, if the only requirement is the synchronizationof actuators and sensors for running a given task plan,then a simple program can be loaded into the PLC,which controls both the input signals originating fromthe cell sensors and the output signals which trigger thecell actuators.

On the other hand, if the control system is requiredto automatically download the NC part processingprogram from a database according to the informationoriginated by an automatic vision system which detectsthe part type entering the system, or some errorrecovery functionality is required, then the controlsystem needs to include different hardware devices anddifferent software modules.A very conventional way to control a robotized

manufacturing cell is by PLC devices, which interactwith every other element by exchanging electricalsignals. As an example, a PLC can trigger or stopdiscrete event sequences on a machine tool accordingto the ladder logic it is executing. In other words, thePLC not only controls basic actuators but also thesynchronization of production processes among manymanufacturing and auxiliary elements, which can alsobe programmable.

The most common programming languages for PLCare the standards IEC 1131-3, like LD, ST, FBD, andIL. All of them differ from the most common general-purpose languages such as C++ or Visual Basic, beingdevise-oriented programming languages. For instance,in its essential form, the ladder logic is a graphicalrepresentation of Boolean switching functions based onan analogy to physical relay systems.

As far as PLC-based embedded control systems areconcerned, the topic of the limited and inflexiblecapability of their programming languages is largelytreated in literature. Following these directions authorspropose Petri net models [1], [2], object orientedmodels [3], state-chart diagrams [4], [5] that,afterward, need to be, automatically or manually,converted in the PLC programming language. This pre-programming phase is needed in order to have a higherlevel model of the control program, which is easier tounderstand and easier to design, due to its processoriented nature which reproduces the discrete eventfunctioning of the manufacturing cell. Lee et al., byusing object oriented models and state chartsdeveloped a virtual prototyping environment to reducethe risks involved in PLC-based control programs, such

VOLUME 1332

as deadlock problems [6]. Also, expert systemsmodules [7] and layered Petri Nets [8] are used whenadditional features are required to the control programof the cell task plan, such as error handling capabilities.

3. Control system requirements

The research context described in the previoussection highlight that, in order to approach thedevelopment of a manufacturing control system, threemain requirements need to be well defined.- The first requirement concerns the identification

of the boundaries of the problem, i.e., thespecification of the manufacturing system to becontrolled, in this case the specificmanufacturing cell component, i.e. the planarrobot.

- The second requirement is related to thefunctional requisites that the control systemshould provide, such as simple task planrunning, or monitoring, or error handling, orsupervising, or scheduling, or part qualityvisioning, or, also, all of these.

- The third main requirement concerns thespecification of the basic properties that thecontrol system should have. This lastrequirement depends, of course, on the secondrequirement and involves decisions on thesystem hardware configuration, such ascentralized/distributed or hierarchical/heterarchical architecture, and on its softwarefeatures, such as device/process/objectorientation or synchronous/ asynchronousprocedural implementation.

In what follows, these requirements are described indetail.

3.1. The system to be controlledThe system to be controlled is a robotic manipulator

with 2 degrees of freedom represented by two armscoupled by a brushless engine (see figure 1).

The bottom arm of the robot is fixed against thebasement through another brushless engine, while theupper arm holds a grip for workpieces manipulation(end-effector). Also, two resolvers are used to measurethe angular position of the robot.

The robotic manipulator includes two magneticstroke-ends to limit the arms' rotation under 2400. Thearms' rotation is performed by using two drivers,depicted in figure 2, coupled to the brushless engines.

Fig. 2: Drivers coupled to the brushlessengines

Each driver communicates to the central controller(in this case the PLC) the desired position of the robotthrough a serial port RS232C. For instance, by usingthe command string AD "data" the engine rotates thearm of the angle specified in the field "data" from thespecified home position and in a specific rotationversus.

Through the RS232C port the shape of the velocityfunction is also communicated. This could betrapezoidal (as showed in figure 3) or simplysinusoidal.

Fig. 3: Example of velocity andacceleration time laws

Fig. 1: The robotic manipulator

VOLUME 1333

3.2. Control functional requirementsThe aim of the control system, which has been

developed, is simply to run procedural programs fortransferring by means of the robot arms worpiecesfrom a working station to another working station ofthe manufacturing cell. No integration with othersupervising control system, no error handling, no datacollection functions are required.

The abstraction level of the required automation isvery low, as far as the operations of the robot aredriven by 2 brushless engines while a number ofsensors identify its status. Both engines and sensorsexchange digital signals (ON/OFF) with the controlsystem by means of electromechanical relays andanalogical signals by means of the resolvers needed inorder to correctly define the 2D robot positioning. Thecoordination of every component for executing the taskplan is driven by an asynchronous control mechanism,i.e. an interlocking based control.An interlock is a mechanism for coordinating the

activities of two or more devices in order to ensure thatthe actions of one device are completed before the nextdevice begins its activities. Interlock-based control, incontrast with time-based control, works by regulatingthe flow of control signals back and forth between thecontroller and the controlled devices.

Summing up, the abstraction level of the requiredcontrol system, coincides with a stand-alone PLC-based control system for the above mentioned roboticmanipulator.

3.3. Control properties: reconfigurable controlDespite the sequence co-ordination capability is the

primary required control property, the control systemshould also be reconfigurable. Indeed, using hardwareand software rigid configurations could be an easysolution to perform a specific manufacturingapplication. However, the redefinition of suchapplications which includes removing/adding one ormore hardware subsystem (such as working station) orsoftware subsystem (such as error handling modules)would involve significant efforts in reengineering thesystem.

The control system, even if it performs very low-level control activities such as equipmentscoordination, must be able to re-define the presence ofthe hardware devices it controls and the governancefunctions it performs in an easy way by beinghierarchically structured and modularly designed.Object-oriented (00) technologies are the paradigmmainly proposed and used for software development ingeneral but also in the specific field of manufacturingsystem control applications.

The characteristics of such a paradigm are perfectlysuited for software applications that require reusability,scalability, and reconfigurability of the software

However, it is a matter of fact that 00methodologies are widely used during the phase ofmodeling the control system architecture but quiterarely adopted when it comes to the control softwareimplementation.

Indeed, as far as a complex control system isconcerned, such as a large control system for a CIMsystem, then the 00 approach allows the definition ofits hierarchical architecture and the relationshipsamong its many software modules (such asdependencies, aggregations, and so on) [9].

On the other hand, concerning the low-level controlsoftware implementation it is easy to comprehend thatas far as most manufacturing equipments are controlledby PLC devices and PLC can be programmed withspecific programming languages (such as ladder logicor sequential function chart or instruction list) 00programming is not practical and ease to implement.That's the reason why, the paper proposes amethodology for easily translating the 00 softwaredesign into the AWL program.

4. Control system development

4.1. Control system designAs already mentioned, the control system which

needs to be designed correspond to a task programwhich coordinates the sequence of actions of thespecific robotic manipulator for workpiece transferamong working stations.

In the first step of the control program development,by examining the real objects which need to becontrolled and coordinated, the designer needs toidentify all classes involved in the system. Figure 4provides the main class diagram (according to theUML graphical notation), where classes, theirrelationships, and hierarchy are displayed. All of therepresented classes constitute the control systemstructure.

Fig. 4: The control system class diagram

components.

VOLUME 1334

So far, only classes' relationships and theirhierarchy have been defined. Yet, to define classes'structures, their attributes, and operations, it isnecessary to analyze the dynamic behavior of thesystem and of its components during the realization ofall of the system use-cases. In order to describe thedynamic behaviors and the process workflows in termsof information flows among objects, UML sequenceand activity diagrams should be used.

Once the main class diagram has been designed, i.e.the classes of objects (and their relationships) whichneed to be controlled and coordinated have beenidentified, the messages that such object should send toeach other in order to obtain the specific task programneed to be discovered. Such exchanged messages areshown in the sequence diagram of figure 5.Specifically, the sequence diagram reports thesequence of messages that need to be exchanged whenthe transfer of the workpiece from a working machineto another requires the following movements:- 1100 rotation of the upper arm- 3200 rotation of the bottom arm- 3200 rotation of the upper arm- 1200 rotation of the bottom arm

Initially, the class "Machine" asks for being idled fromthe processed workpiece and sends to the class "CellController" the message take out piece. For thispurpose, the class Cell Controller sends the messageMove piece to the PLC class and this activates thesequence of messages necessary for the robotmovements.

For example, the first movement, associated withthe message Trasfer data movement upper arm, isachieved by sending the string ADI 10CR to the RobotDriver class which is responsible for the robot realmovements.

LMove viecee

y

Transfer data movement upper arm

Move uper ar

TranFfer data movement lower arm

_ Move lower arm

Transfer data movement upper arm L

-Move upper arm

Transfer data movemeni lower arm

-Jove lower arm

Fig. 5: UML sequence diagram for theworkpiece transfer operation

Although the sequence diagram shows clearly thesequences of operations needed for the processaccomplishment, the interlocking logic of the discretecontrol system could not be implemented without thedesign of the correct synchronization of events,activities, and states that characterize such a process.

In other words, what still needs to be designed is thesequence of activities triggered by certain events andchanging objects states. In order to describe the processdynamic in terms of workflow to be performed, theUML activity diagram has been chosen. In figure 6, theactivity diagram for the control process is given.

Fig. 6: UML activity diagram for the workpiecetransfer operation

The activity diagram shows that the workflow istriggered as soon as the Cell Controller class is ready tostart the movement sequence. Such state is representedby the value of attribute variableMOV equal to 31. Atthis point the activity First movement upper arm (1100)

VOLUME 1

I

335

is activated and the PLC will transfer data ADJJO tothe Driver Robot upper arm class. This last class, then,will convert data in position and triggers the activityMove upper arm performed by the robot class until thestate upper arm in position is reached.

Once all of the exchanged messages and thecorresponding objects' activities and states have beenidentified, the design of the software classesconstituting the system can be completed by assigningattributes and operation to every class as reported infigure 7.

Flexible Ncnufacturing Cellatt cnbute:openrtion:

Cell Controller o Mhinem Robotg Dciver RobotCet working: boo aolM odles upperannRin position: bool 8Ceelnotworking: bool Machine teminate loweranninposition: bools convert data in positionFariabileMOV: int workpiece: bool robotiwors.ng/not working: read actualpositionMove piece() P rocess Workpiece pa bool

purpose languages orn rotate upper ann u i tlanguage.rotate lower ann

PLCfust movenment: boolsecond move rnent:boolthird movement: boolforth movermt: bool

tavnsfer data to dhver robot F 9fust movenment upper ann ( )s econd moveient lower ann p tthird movement upper ann ( )fourth mvement lower ann l b

Fig. 7: UML complete class diagram of thecontrol system

4.2. Control system implementationIn order to implement the designed control system

two serial modules CP340 RS232C (see figure 8) havebeen used as communication channels among the PLCand the brushless engines drivers.

The PLC is usually programmed with specificpurpose languages or notations. The PLC used in thisapplication is a SIEMENS S7-300 and itsprogramming language AWL is a classical ILlanguage.

The control logic that governs the execution of taskplans, should hence be translated from the UMLactivity diagram into the AWL notation. Figures 9, 10,and I11 report a partial view of the AWL program thathas been written for executing the task plan of figure 6UML activity diagram.

The design of the interlocking logic by using theUML activity diagram surely supports the PLCprogrammer in understanding and writing the AWLcode. Indeed, by associating:- every object to hardware components

(machines, robots, etc.),

- every condition related to a specific state of anobject (note that, on the UML side, a statecorresponds to a specific configuration of theobject attributes) to the input conditions, whichin the AWL notation are defined by using the"U" symbol (note that in AWL, the inputconditions represent physical input or specificcontrol variables values that identify a givencontrol sequence status),

- every object activity (note that, in UML anactivity is associated with the execution of onespecific or a group of object operations) to theoutput actions, which in AWL are defined byusing the "S" symbol (note that in AWL, theoutput actions identify physical output orspecific control variables values as the inputconditions), and

- every data transfer (note that in UML, amessage recalls a given operation of thereceiving object by transferring someparameters) to the loading and transferringoperations (denoted in AWL respectively withthe symbols "L" and "T")

the shop-floor control operator can program the PLC,by simply interpreting the UML activity diagram inAWL.

Fig. 8: Serial communication modules CP340RS232C

Also, the following steps need to be executed:- Definition of the table of symbols by using the

variables which compare in the activitydiagram;

- Transfer (by using the commands P SEND) thestrings that are necessary for the armsmovement, and which are recorded in a specificdatabase;

- Recall the P_RCV command for the armsposition detection;

- Insert additional commands like SPB or otherjumping commands to other segmentcommands, in order to avoid data transferringand/or operations triggering when the specific

VOLUME 1336

state attributes are not activated, as depicted infigure 10.

For instance, let's consider the first movement whichconsists in the 1100 upper arm rotation. As alreadymentioned in the activity diagram description of figure6, the state SI "first movement" of the PLC objecttriggers the activities Al "First movement upper arm(1 10°)" and A2 "transfer data ADI 10". This has been,then, translated in the AWL notation where the inputcondition (U) "First movement" activates the outputcondition (S) "First movement upper arm" (figure 9),and also the data ADi 10 transfer to the databasenumbered 27 (figure 10). Finally, such data aretransferred to the specific driver (figure 1 1).

: Titolo:

First rbbbot'3 Ifovemeent

U "First movement"s "First movement upper arm"

Fig. 9: Sketch of the AWL control program forthe workpiece transfer operation

: Titolo:

SPBLTLTLTLTLTLT

fine: BE

"First movement"fine'A'DB27.DBB 2'DiDB27.DBB 3'1'DB27.DBB 4'1'DB27.DBB 5

DB27.DBB 6B#16#DDB27.DBB 7

//char

Fig. 10: Sketch of the AWL control programfor the workpiece transfer operation

oSegmento 13: Transfer data to driver

Transfer data AIADiIODOrI

CALL "Invio Stringa"r r"Dati Stringa"

Fig. 11: Sketch of the AWL control programfor the workpiece transfer operation

Once the AWL code for the robot movements'sequence has been written, such code can be saved as aspecific sub-routine (see "FB24 Sequence Movement"in figure 12) that can be reused in other similarapplications by changing only the movementcoordinates. In this way it is possible to create a libraryof sub-routines that can be reutilized in new controlsoftware systems' design and development.

+af 5ndrdLibrary--A SIMATIC_NET_CP

1 CP 3001k FB2 IDENT CP_300

i FB3 READ CP 300.-- FB4 REPORT CP 300

FBs STATUS CP 300Cl FB6 WRITE CP 300. FB8 U5END CP300PBK.--- FB9 URCV CP300PBKa FB12 BSEND CP300PBKCl FB13 BRCV CP300PBK. FB14 GET CP300PBK.-- FB15 PUT CP300PBKl11 F624 Se9uence Mb1vement.-- FC1 DP SEND CP 300

FC2 DP_RECV CP_300.- FC3 DP DIAG CP 300QI FC4 DP_CTRL CP 300.- FC5 AG 5END CP 300

FC6 AG RECV CP 300.-- FC7 AG LOCK CP 300a FC8 AG UNLOCK CP 300; FC12 Ciso.11-FC40 FTP CONNECT CP_300C FC41 FTP STORE CP 300471 FC42 FTP_RETRIEVE CP_300C FC43 FTP DELETE CP 300.--- FC44 FTP_QUIT CP_300

-Th±1 [E- Za IN[13-1--l OUT1 q IN OUT13--- STAT+ TEMP

Fig. 10: Library of the developed AWL sub-routines

5. Conclusions

This paper describes a study that has been conductedfor the development of a control system for a robotizedmanufacturing cell, and in particular for a specificcomponent, i.e. a robotic manipulator. After apreliminary requirement analysis, the study involvedthe hardware and the software design of the controlsystem and then its implementation aspects.

The study showed that the object-oriented designsurely facilitates the PLC programming phase(typically a shop floor activity), unluckily it takes aconsiderable effort and time and thus it is not reallyrecommended unless the manufacturing cell is flexibleand required to process different part type. In this case,its control system, fixed in its hardware configuration,is called for running different task plans and writingmany activity diagrams and then translating them intoAWL is easier than writing directly all the AWLprograms.

The approach innovation is the proposal of theUML as an object-oriented tool that can be usedwithout other tools for the modeling and design ofmanufacturing control systems. It has beendemonstrated that the UML can support a static andstructural modeling of control systems, as well asdynamic one. Since UML offers a complete graphicalnotation but no modeling methodology, efforts havebeen focused on the development of a systematicdesign procedure to make the task of developing thecontrol software system easier.

VOLUME 1

44WO...,

Iwic,.Mi data iia,

UN "First movement"SPB fineL -A-T DB27.DBB 2L -D-T DB27.DBB 3L .1.T DB27.DBB 4L .1.T DB27.DBB 5L .0.T DB27.DBB 6L B#16#DT DB27.DBB 7

337

Also, the control software 00 features, allow, asvariously demonstrated in the literature, an easyreconfiguration of the control software [ 10], [11 ]. Thisreconfiguration, which can be thought of as thepossibility to add, subtract, and reuse software objects,becomes crucial for two main issues. The first concernsthe reutilization of software components during thephase of design of the control software; the secondregards the management, at low-level control, ofhardware reconfigurations, which are necessary to gaina given level of reactiveness.

using object modeling technique, Computers inIndustry, Vol. 41, pp. 213-238.

[10] Kovacs G.L., Kopacsi S., Nacsa J., Haidegger G.,Groumpos P., 1999, Application of software reuse andobject-oriented methodologies for the modelling andcontrol of manufacturing systems, Computer inIndustry, Vol. 39 pp.177-189.

[11] Kopacek, P., Kronreif, G., Probst, R., A modularcontrol system for flexible robotized manufacturingcells, Robotica, Vol. 17, p.p 23-32, Jan-Feb 1999.

6. Acknowledgements

This work has been possible thanks to the grant ofthe Italian Ministry of University and Research.

References

[1] Peng S., Zhou M., 2003. Sensor-based stage Petri netmodelling of PLC logic programs for discrete-eventcontrol design, International Journal of ProductionResearch, Vol. 41 No. 3, pp. 629-664.

[2] Jang, J., Koo, P., H., Nof, S.,Y., 1997, Application ofdesign and control tools in a multirobot cell,Computers & Industrial Engineering, Vol. 32, n. 1, pp.89-100.

[3] Pires, J.N., and Sa' Da Costa, J.M.G., Object Orientedand distributed approach for programming roboticmanufacturing cells, Robotics and ComputerIntegrated Manufacturing, Vol. 16, 2000, pp. 29-42.

[4] Borchelt, R.D., Thorson J., 1997, Toward reusablehierarchical cell control software, InternationalJournal ofProduction Research, Vol. 35, n. 2, pp. 577-594.

[5] Klein, P. Jonsson, C. Backstrom, Automatic synthesisof control programs in polynomial time for anassembly line, Proceedings of the IEEE Conference onDecision and Control, Vol. 2, pp. 1749-1754, 1996.

[6] Lee J.I., Chun S.W., Kang S.J., 2002, Virtualprototyping of PLC-based embedded system usingobject model of target and behavior model byconverting RLL-to-statechart directly, Journal ofSystems Architecture, Vol. 48, pp. 17-3 5.

[7] W. Hu, M. Schroeder, A. G. Starr, A Knowledge-basedreal-time diagnostic system for PLC controlledmanufacturing systems, Proceedings of the IEEEInternational Conference on Systems, Man andCybernetics, Vol. 4, IEEE, USA, pp. 499-504, 1999.

[8] M. Hasegawa, M. Takata, T. Temmyo, and H.Matsuka, Modeling of exception handling inmanufacturing cell control and its application to PLCprogramming, Proc IEEE Int Conf Rob Autom. Publby IEEE, Computer Society, Los Alamitos, CA, USA,pp. 514-519, 1990.

[9] Ou-Yang C., Guan T.Y., Lin J.S., 2000, Developing acomputer shop floor control model for a CIM system -

VOLUME 1338