40. SBAI- Simpósio Brasileiro de Automação Inteligente, São Paulo, SP, 08-10 de Setembro de 1999

PERFORMANCE EVAlUATION OF CONTROl ARCHITECTURES ININDUSTRIAL AUTOMATION

LuísClovis Lima Viana

João Maurício RosárioLaboratório de Automação Integrada e Robótica

Departamento de Projeto Mecânico Universidade Estadual de CampinasCx. P. 6051 - 13083-970 - Campinas - SP - Brazil

Jean-Mate FaureLaboratoire d'Ingénierie Integrée des Systêmes Industriels

CESTI-ISMCMMaison des Technologies - Place Georges Pompidou - Quartier Mayol

F83000 - Toulon, France

Abstract, The design phase of Automated ManufacturingSystems comprises many different tasks and among themstands the design of a control architecture. Actually for highlydistributed control systems the choice for a specificarchitecture has great impact on the overall system 's life cycle .In such cases the designer is faced with lhe paradox of havingto propose early enough in Lhe system 's design phase a controlarchitecture which rnust fulfill functional requirements such asresponse time. This work presents a framework for validatingdistributed control architecturcs by modeling lhe system 'sdistributed features with tools from Structured Analysis andfurther 'translating ' its dynamic behavior into Timed ColoredPetri Nets models for simulation . A case study is provided asan application in a didactic automated platform.

Keywords: distributed controI, simulation, Timed ColoredPetri Nets, response time.

1 INTRODUCTIONThe life cycle of an Automated Manufacturing System

(AMS) begins with a specification and design phase. Thisphase compr ises the following activities:• analysis of the user's needs, which rcsults in lhe definition

of the System's Requirements;• prelirninary design of the system , by specifying its general

properties;• lhe specification and design of its control subsystem;• the specification and design of its operational subsystem;• several validation steps, for each design activity generates

models which shall be validated prior to rcaching thesystem's construction phase and the remaining of its lifecycle.

669

The design of the control architecture of an AMS leads todefining theallocation of the system's control functions to lheavailable control devices.

UsualIy this task is placed among the control subsystem 'sspecification and design activities, i.e. in lhe middIe of thespecification and design phase, which is perfectIy acceptablefor systerns with simple control architectures, rnostIy made of asingle control device.

However, in order to achieve higher leveIs in -flexibility andreactivity in the industrial environment, AMS control systernsare often conceived as distributed. For exampIe, the operationalsystem may be controlled by several programmable logicalcontrollers (PLC), these being directed by a supervisorysystem; lhe data exchanges among the several deviccs beingassured by a local network. Therefore, it becomes quitedifficult for the designer to choose a proper control architecturefor the distributed system, specially with regard to responsetime. Moreover, equipment manufacturers have perfectknowledge of their control system components takenindividually but, in general, they lack of information about howvarious components and different influence parametersinteract.

Thus, for an AMS with a strongly distributed control structure,most of the following activities of its life cycle depend on thechoice of a proper controI architecture. The designer must thenevaluate his choices of controI architecture early enough duringthe system's design and specification phase: in fact, during thepreliminary design of the system. The next chapters show astructured framework for achieving this goaI.

40. SBAI- SimpósioBrasileiro de Automação Inteligente, São Paulo,SP, 08-10 de Setembrode 1999

PLC2

Figure 2 - Example of material arehiteeture.

Figure 1 - Schematie model of functionalarehitecture: (a) flow of data between funetions;

(b) GRAFCET of process T3.

(b)

(a)

Figure 3 - Example of operational archítecture,

SupervisorySystem

2.3 Operational Architecture .The operational architecture describes lhe partition of lhecontrol system's proeess and data among lhe availableequipment by assigning lhe entities of the functionalarchitecture to the components of the material architecture.Figure 3 shows lhe model of operational archítecture issuedfrom the previous examples.

The choice of a control arch itecture for a system aims todetermine which equipment will be used and how lhe variousprocess and functional requirements shall be distributed amonglhe available equipment components in a given application. Inarder to. consider both functional and material aspects of lhecontrol subsystem, lhe control architecture for a distributedsystem is modeled according to three different points of view(Denis , 1997).

Figure 1 shows an example of functional architecture mode\. Inthis example, as well as in the remainder of this work, we usevariations of the dataflow diagram (functional) and the state-transition diagram (behavior): the method SADT (StructuredAnalysis and Design Teehnique) (Ross, 1977) and lheGRAFCET (Graphe Fonetionnel de Commande Etape -Transitian) (lEC848, 1988) respectively, both of thern wellaccepted in lhe field of industrial automation.

The functional architecture describes alI lhe data processingissued from control functional requirements. It is generallymodeled as if lhe physical structure of the control systemconsisted of a single piece of equipment, i.e. one does notconsider its phys ical distribution. It should assure lhefollowing:• represent alI lhe functions of lhe control software 'as well

as alI data that should be stored or circulate among thesefunctions;

• specify when the control functions should be activated,namely define which events are necessary for lhetriggering of a function ;

• specify data Iifetime, e.g. define whether data is consumedin the trans fer between two functions (producer andconsumer) or it is necessary to assign a store for theinformation.

Therefore lhe functional architecture is expressed by aconsistent set of functional models (those describing functionsor process), behavior models (which describe lhe evolution andactivation of funct ions) and information models (describingrelationships between different data) . Thus, dífferent designmethods can deseribe the functional architecture as a whole.We have chosen the approach known as Structured Analysis(Gane & Sarson , 1979) (DeMarco, 1979), these three kinds ofmodels being combined as in lhe work ofYourdon (1989).

2.2 Material Architecture

2.1 Functional Architecture

2 DESIGN OF THE CONTROLARCHITECTURE

The material architecture is in fact a representation of lheavailable physical means to respond to a specific problem,These consist of control equipment and industrial computerizeddevices (Fig. 2).

Despite the diversity of lhe equ ipment that may be used in anAMS, lhe different components of lhe material architecture canbe grouped into generie classes:• processors (PLC, industrial caleulators, computers, etc.);• man-machine interface (control consoles, dialogue

stations, supervisory sys tems, etc.);• communication links (point-to-point Iinks, networks, etc.).

670

40. SBAI- Simpósio Brasileiro de Automação Inteligente, São Paulo, SP, 08-10 de Setembro de 1999

o= dlO;

VRG

IWj;Gj l(b)

ca.zolCOM31 :Q 1'EP1PPO.. 1'C01.1121COM:21 z> 1'PPtEPO ,,''COI.I13

....naocs

P1.C

(c)

Figure 4 • (a) TCPN model of a PLC; (b) TCPNmodel of a logical process; (c) projection of the

process model onto the PLC model.

4 STUDY CASE: THE ASSEMBLYSTATION

3 VAlIDATION OF RESPONSE TIMETHROUGH TIMED COLORED PETRINETS

In order to simulate and to evaluate the operation al architecturemodels, we have opted for Design/CPN, software maintainedby the CPN group of lhe University of Aarhus, Denmark.DesignlCPN is a TCPN editor and simulator. Besides, thissoftware allows the construction of hierarchical modelsthrough the following mechanisms (Maciel et al, 1996):

• transitions themselves can contain subnets, which allows astructured process of design in eilher top-down or bottom-up fashion;

• plaees in different subnets can be "melted" together as ifIhey were just one, even Ü they are in different regions ofthe model, allowing . the various subnets to connect,forming an on1ynet,

The function subnets, derived from lhe functional architecture,are then coupled to lhe equipment component subnets (Figure4). The TCPN in Figures 4a and 4b use DesignlCPN ownsyntax. Even if these subnets are in different regions of lhemodel, their places are logically connected by lhe mechanismcaIled "fusion of places" . These specific places carry a labelwith lhe inscription FG (meaning Global Fusion) and areconnected to their counterparts (e.g. the two places carrying FGSTüRE_WR are lhe same place and they obviously have thesame five tokens) . Figure 4c shows explicitIy their behavior.

Finally, the tokens in DesignlCPN carry a time . stamp,indicating the instant when a given token arrived in its lastplace. During simulation, these time stamps permit theintervals of the many flows of data to be coIlected or evenplotted, so lhe designer can evaluate lhe given architecture.

At this point of the design of lhe control architecture, variousoperational architectures may be carried out. Each onepresenting a different behavior, specially with regard to lhesystem's time response. The designer has to validate lhedynamic behavior of the operational architecture models inorder to evaluate their temporal performance and finally definelhe control architecture for lhe system.

For each process (Ti), one determines which processor shouldassure its execution. Each data store function (Ei) can beaIlocated either to a processor (into its memory) or to a specificdata storage device . The flows of data circulate among processand stores by a communication link, e.g. a local network.

To validate lhe temporal behavior of lhe different operationalarchitectures one must create a dynamic model by joining lhemodels of lhe various process and components (Denis, 1997).These models should be generic for they could be freelycoupled to each other according to the different architecturesproposed.

Timed Colored Petri Nets (TCPN) permit lhe construction ofsuch a dynamic model , The eolor feature aIlows to creategeneric models, in which a subnet can retain the same structure(places, transitions and ares) independently of its position inthe architecture: on1y the different colors of tokens

(representing, for instance, different kinds of data) indicate itsrole in relation to the other subnets. In addition, the time

feature is essential to model the temporal behavior of lhedynamic model,

671

40. SBAI'- SimpósioBrasileiro de Automação Inteligente, São Paulo,SP, 08-10 de Setembrode 1999

As an application of this rnethodology, we have used one of the • the setof cylinders in the upper part of the station handlesworking stations of a didactic automated platform (Rosário et the previously stored cubes (Set Cube and Cube Bolder)al, 1995). This platform results from the co-operation between and assembles them onto the plate (Cube Assembler);the Laboratório de Automação Integrada e Robótica at 5 Plote Holder sets the plate onto Lift, 'which brings it downUNICAMP, in Campinas, BraziI and the Laboratoire back to the transfer system.d 'Ing énierie Integrée des Syst êmes Industriels at CESTI-ISMCM, in Toulon, France. It is an experimental AMS for 4.2 Control Architectureresearch in the automation field.

4.1 System's requirementsThe platform automatically assembles LEGO"'" pieces. It iscomposed of four working statlons and a transfer system,which interact to correctly assemble a deterrnined sequence ofcubes on a Iarger plate . Each different sequence of cubes on aplate is considered as a distinct type of product (Fig. 5).

Functional architecture

The main controI functions of the Central Assembly Stationwere modeled through the SADT method. A model of thesefunctions consists of (Fig. 7a):• "to process code", namely to identify it and further

transmit the information about the type of product to theother controI functions;

• ''to handle the plate", namely to controI the alternareoperations of Lift and Plate Holder cylinders, i.e, receivingthe plate and its evacuation after the product is assembled;

• ''to assemble cubes", namely to controI the cylinders andsensors responsible for assembly of lhe cubes.

(a)

PlaleHolder

Plate Holder

"Wailing"

"Wailing"

"Wailing"

Message!llProctsS Cod.

Old:rs loe}lincIn

-7

StatíonBlock

Cube Asscmblcr

CubeHolder

Figure 5 • Example of product made by the platform,

The Central Assembly Station assembles up to two cubes ontothe central position of the plate, according to an attached code(by bar code or by magnetic label) which specifies the type ofproduct to be made by the platform. The work in the CentralAssembly Station can be resumed by the following sequence ofoperations (Fig. 6):

Figure 6 - Structure of the Central AssemblyStation .

• the plate arrives through the transfer system's conveyorand its code is read;

• the plate is raised by Lift and carried into the station byPlate Holder;

(b)

Figure 7 ..Central Assembly Station's functionaIarchitecture: (a) SADTaction diagrama(b) Handle Plate function's GRAFCET.

672

40. SBAI- Simpósio Brasileiro de Automação Inteligente, São Paulo, SP, 08-10 de Setembro de 1999

• . _ .. . . ... . ... _ . _ _ ..._ . • Dctcetionorpb;nt..hddC"_IN (I)

30 60 !lO 120 ISO 18U 210 240 270 300

Figure 9 • Response time for two control archítectures.

4.4 Simulation and resultsDesignlCPN permits, with the addition of programming code,to plot selected pararneters in graph form during simulation.The following are some of the measures of system's responsetime.

( . ClIbc A5KmbIN.. ....-...-....•-...•Architecrure 2

. ..-...Rc:.pofMCTiau' (11I&)

soo4504003SO300

...• .ISO10050o o

Figure 9 shows, in the vertical axis, several measures of lhetime elapsed since there is signal in the plate holder IN sensoruntil Cube Assembler cylinder is activated, throughcommunication between two control devices. These valuescome from the simulation of successive operation cycles(several plates being worked, the horizontal axis showing themoment plote holder IN sensor turns on). For this parameter,the traffic of data in the network and the hierarchy of access tothe médium (whether a master or a slave device communicates)result in a better response time for Architecture 2 (average of220 ms) compared with that of Architecture 1 (average of 340rns).

RC"IpoaKTiroe{rut.) Architcctnrc 1li ...·····...-....-........-.-.- (.C:ubeAoocm'k,_. Dctectl ono fpb(l'_hokSer_IN (. )

o o 30 60 !lO 120 ISO J!O 210 240 270 300

Material architectures.Two material architecture configurations are intended tocontrol the station:• the first consists of three PLC linked by an UNITELWAY

PLC network, whose protocol has rnasterlslave accesscontrol;

• the second material architecture consisting of .two PLCplus a dedicated embedded controlIer responsible forrnagnetic label reading/writing, alllinked by UNITELWAYPLC network; the embedded controller only supportsnetwork connection in slave mode.

Operational architectures.These are the models to be simulated and evaluated in variousscenarios. They come from the projection of the system'sfunctions onto the previous material architectures. Forexarnple, we may have "Architecture I" as being:• process code onto the master PLC;• handle plate and assemble cubes onto each one of the

slavePLCs.

And, as "Architecture 2":• process code onto the embedded controlIer (slave);• handle plote onto the rnaster PLC;• assemble cubes onto the slave PLC.

These two last functions are interdependent thus exchangingsynchronization messages that assure the co-ordinationbetween positioning the plate inside the station and setting thecubes on the plate.

The time-dependent behavior of these functions, above alI thesequence of data exchanges among them is described by theirrespective GRAFCETs (Fig. 7b).

4.3 Performance indicatorsAs seen in the functional architecture model (Fig. 7), there areseveral flows of data among the control functions. In fact, thesecommunicate in order to perform their tasks, by exchangingactivation or synchronization messages. Thus, the performanceindicators to be collected during sirnulation will be lhe timeintervals between cause and effect in two differentfunctions. For example, the time elapsed since the detection ofplate arrival at the lift (input in Process Code) until the actionof lifting the plate (output in Handle Plate), these beingseparaled by the emission and reception of a message (Fig. 8).

5 CONCLUSIONTimed Colored Petri Nets are a powerful paradigm to modeldynamic systems . Combined with the present methodology, itis possible to conceive the design of controI architectures ofdistributed systerns in a systematic and structured way.Besides, compared to analytic validation or prototype building,this rnethodology permits to define project guidelines at a Iowcost and before affecting posterior phases of system's lifecycle.

REFERENCES

Figure 8 - Communication between distinctGRAFCETs.

Boutei1Ie N. et ai, 1992, Le GRAFCET, CollectionAutornatisation et Production, Editions Cépadues, Paris.

DeMarco, T., 1979, Structured Analysis and SystemsSpecification, Prenlice-HalI, Englewood Cliffs, NJ.

Denis, B. & Meunier, P., 1997, Validation du ComportementDynamique des Architectures de Conduite de Systêmesde Production par Simulation, Modélisation etSimulation des Systemes de Production et deLogistique, June 5-6, Rouen, France, pp. 229-238.

DesignlCPN Tutorial for X-Windows, Meta SoftwareCorporation, Cambridge, MA.

673

40. SBAI- Simpósio Brasileiro de Automação Inteligente , São Paulo, SP, 08-10 de Setembro de 1999

Gane C. & Sarson T., 1979, Structured Systems Analysis,Prentice-Hall, Englewood Cliffs, NJ.

International Electrotechnical Commission, 1988,Etablissement des Diagrammes Fonctionnels pour desSystêmes de Commande, iriternational standard IEC848.

Maciel, P. R. M. et al, 1996, Introdução às Redes de Petri cAplicações, Instituto de Computação - UNICAMP,Campinas.

Rosário, J. M. et al, 1996, Platform for Teaching and Researchon Industrial Automation, Proceedings of the ThirdInternational Electronic Engineering Conference,August, Trujillo, Peru.

Ross, D. & Schoman, K., 1977, StructuredAnalysis forRequirements Definition, IEEE Transactions onSoftware Engineering, vol. SE-3, n. I, pp. 6-15.

Yourdon E., 1989, Modem Structured Analysis, Prentice-Hall,Englewood Cliffs, NJ.

674