From Design to Integration of Transitic Systems A Component Based Approach

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

A Component Based Approach

Thierry COUDERT, Pascal BERRUET, Jean-Luc PHILIPPELESTER

Université de Bretagne Sud

Centre de rechercheRue Saint MaudeBP 92116

56321 LORIENT Cedex

France

Tel: (33/0)2.97.87.45.25Fax: (33/0)2.97.87.45.05

email: {thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.fr

1

INDUSTRIAL INFORMATION TECHNOLOGYIntelligent transportation

Flexible manufacturing systemIndustrial automationCADCIM

Transportation systemsComponentsDesignSimulationIntegrationControl

KEYWORDS:

1

Contact author

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

A Component Based Approach

Thierry COUDERT*, Pascal BERRUET, Jean-Luc PHILIPPELESTER, Université de Bretagne Sud

Centre de recherche, rue St Maude, BP 92116, 56321 LORIENT Cedex, France

Tel: (33/0)2.97.87.45.25 fax: (33/0)2.97.87.45.05

email :{ thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.fr

ABSTRACT

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation onoperational architecture. It considers a flow that applies from specifications to integration the same model. This model isobtained from design requirements. Two steps are then conjointly performed: validation and prototyping. The validation step isbased on two kinds of analysis: static and dynamic analysis. Static analysis checks the coherence of the model by a constraints-based approach. Dynamic analysis allows to simulate the behaviour of the system with the control that will be implemented.The prototyping step enables choice of physical parameters and control design. The model is then implemented on anoperational architecture. The different parts of the transitic system corresponding to the model have to be installed and thecontrol has to be implemented on controllers. Controllers can be classical Programmable Logic Controllers or dedicatedcontrollers. A new kind of controller developed at the LESTER Laboratory is described: the nano-controller.

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

A Component-Based Approach

Thierry COUDERT, Pascal BERRUET, Jean-Luc PHILIPPE

Université Bretagne SudLESTER - Centre de RechercheRue de Saint Maude - BP 9211656321 LORIENT Cedex - FRANCE

{thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.fr

Abstract –The aim of this paper is to present a component-based approach for the design of transitic systems and theirimplementation on operational architecture. It considers a flowthat applies from specifications to integration the same model.This model is obtained from design requirements. Two steps arethen conjointly performed: validation and prototyping.Validation is based on simulation and a more formal approach.Prototyping enables choice of parameters and controlelaboration. The last step is the integration. The different partsof the workshop have to be installed and controls implementedon classical Programmable Logic Controllers or on dedicatedones: the nano-controllers.

I. INTRODUCTION

Transitic systems are particular manufacturing systemsthat transport parcels from different locations with a fast flowand dispatch them to their right locations. They are composedof different types of conveyors, elevators, consignments,sorters, and automated guided vehicles (Fig. 1). Conveyorscan be linear, curved, and circular. They can have pneumaticjacks, stops, and switchings.

Designers of such manufacturing systems are confrontedto many problems. The complexity requires modularapproaches in order to decompose very large and complexdesign problems in more simple ones. The bestappropriateness between functional solutions and materialarchitecture has to be obtain at the earliest stage of design.Facing very competitive markets, time to design andimplement a new transitic system has to be reduced. Atransitic system has to be robust, easy to maintain, easy tocontrol, flexible, modular and fault tolerant. Several solutionsare possible with different costs and have to be evaluated inorder to choose the optimal one. The reusability aspect is alsovery important enabling designers to reuse some validatedparts.

This work concerns a major project that provides aframework from design to integration of transitic systemsincluding both control and material part. The goal is topropose to designers a component-based model enablingthem to choose the different physical parts of the real system,to design the control, to check the behaviour of the controlledsystem and to test it before on-site implementation. When thedifferent components are well parameterised, chosen andorganised, the control is coherent and the system behaviour isconsistent with specifications, the obtained model can beimplemented on an operational architecture.

Fig. 1: Example of transitic system

The general approach is summarised Fig. 2. It considers aflow that applies from specifications to integration the samecomponent-based model obtained from design requirements(modelling step). On the basis of this model, two steps arethen conjointly performed: prototyping and validation. Theprototyping step enables choice of physical parameters andcontrol elaboration. The validation step is based onsimulation and a more formal approach based on constraintssatisfaction. The model is then implemented on theoperational architecture (integration step). Parts of thetransitic system have to be put together on the workshop andcontrols have to be implemented on controllers.

Fig. 2: Design flow approach

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

The component-based model, built from componentschosen in a library, is defined in section II. In section III,validation and prototyping steps are described by thedefinition of the different analysis methods and themethodology for control design. Section IV presents a toolnamed SimSED developed in collaboration with the Sydelsociety. This tool enables to exploit our approach and is veryhelpful for designers. The section V presents the integrationstep.

II. MODELLING

The approach needs to model physical environment onwhich the control is going to interact [1]. A component-basedmodel has been adopted. It provides a clear and easy way toreuse previously modeled elements or to modify the system’sinternal structure.

A component models a part of a transitic system, at thelevel of the operating part, integrating some constraints'notions.

Therefore, a component is composed of four views: Operating part view; Constraints view; Control part view; Graphical view.

The complete model of the workshop is seen as anassembling of components. Different sub-models (Operatingpart, Constraints, Control part) of the workshop are obtainedfrom these views.

The component description uses a black-box formalism.Inputs / Outputs relative to physical flow (connected withvariables corresponding to parcels' passing) are separatedfrom Inputs / Outputs that give account of informationrelative to sensors, actuators, communication, …

All components include parameters providing adaptabilityto different design. They are stored in a library as validatedready-to-use models. This enables reusing [2].

An aggregation procedure has been developed. It consistsin obtaining one component of level n from severalcomponents of level n-1 brought together. As componentshave the same structure at any abstraction level, thehierarchical component can easily be stored and reused forfuture workshops design.

The complete workshop model is obtained by successivelyaggregating components until having one representing thewhole system. If the study is based on an existing system, thefirst step consists in a structural splitting up in order to getcomponents [3].A. Operating part view

Operating part view models possible physical behaviour ofthe modeled entity.

This model includes both discrete evolutions of thecomponent and physical laws (linear or not), in order torepresent mechanical, pneumatic and/or hydraulicphenomena. It also includes many parameters such as size,

engine speed, engine power, inertia, weight, sensors position,actuators position, …

This view is highly detailed and precisely gives account ofrealistic possible behaviour of the modeled entity, withoutany limitation on its inputs.

As phenomena can be very complex to get, this view canbe obtained based on a structural splitting up approach.Beside elements such as elevator (with several inputs andoutputs), sorter (with several consignment areas), conveyorwith ejection jack and stop, the library also includes basicelements such as pneumatic jack with return effect, sensormodels…

B. Constraints part view

Constraints view expresses with a given syntax thedifferent functions, a component can perform, and what itdemands from adjacent components.

The syntax is based on the concept of predicate. Apredicate provides the constraints that condition a function.Four main functions have been identified: to switch, toregulate, to observe and to transport. Other functions, calledsecondary functions, characterise all other actions thecomponent can perform beside its main function. "Service"functions are relative to an action a component can perform."State" functions give account of the opportunity to emit aninformation variable.

In a predicate the function is linked to a set of constraintswith a necessity operator (requires) or an implicationoperator (if), depending whether the function is imperative ornot.

Constraints are expressed with "Destination.Type.Item".Destination indicates the targeted components, referring tothe I/O they are connected. Three types are possible: Service(constraint relative to a "service" function), State (constraintrelative to a "state" function) and Parameter (relationconcerning a physical parameter of a component). Itemcharacterises the name of the function or the relation about aparameter.

In order to illustrate the constraint part view of acomponent, an example of sorter component is presentedFig. 3. This kind of component is used to sort parcels in thetransitic system. Several parcels can be ejected by the jackwhen they are detected, others keep straight on.

This example contains two components: a sortercomponent and a ramp component. The sorter component islinked with:

- a previous adjacent component (not represented) linked

by the way of the input called Upstream11,

- a next adjacent component (the ramp component) linked

by the way of the output called Downstream12,

- a next adjacent component (not represented) linked by

the way of the output called Downstream11.

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

D. Graphical view

Fig. 3: Example of sorter component

An example of predicate concerning the sorter componentis detailed below:

L1: To_Switch requires

L2:((Upstream11.Service.To_Space_out_Parcels)

and

L3:(Downstream12.State.To_Send_Present_Parcel)

and

L4:(Eject_Input.State.To_Send_Parcel_Eject) andL5: (Downstream12.Parameter.Sensor_Position =

Parcel_width))

This means that this component has to ensure a switchingfunction. This function requires that (L1):

- the previous adjacent component linked by the input

Upstream11 has to space parcels out (L2);

- the next adjacent component linked by the output

Downstream12 (i.e. the ramp component) has to send tothe sorter component a message of presence of parcel(L3);

- the input called Eject_Input has to be linked to a

component (eventually a control output) that delivers anejection order (L4);

- the sensor position of the next adjacent component

linked by the output Downstream12 has to be equal tothe width of a parcel (L5).C. Control part view

Control part view expresses the control essentially discreteof the modeled entity. This control can be effective. Thismeans that it gives the actions sequences the succession ofwhich immediately depends on the previous action or directlyon a sensor. In this case, control outputs directly fit physicaloutput based on cards.

Control can also be considered at a higher level. In thiscase, it co-ordinates some entities, implementing somemanagement strategies (especially during the aggregation ofseveral components).

Control part view is written using the IEC 61131languages (essentially sequential function charts andstructured text). The control part design is described insection III.

Graphical view enables to display, with more or lessdetails, the component during the simulation phase.

It also enables to take manual action of an operator intoaccount (e.g. push-button on a control panel).

It can be noticed that a component has not necessarily agraphical view. A single graphical view can be affected to aset of components (i.e. to an aggregated component). So,operating part view and graphical view are clearly separated.The interest is that a highly detailed operating part view doesnot imply a complex graphical view to display relevantinformation.

III. VALIDATION AND PROTOTYPING

In the proposed approach, validation and prototyping stepsare performed conjointly. The procedure described on Fig. 4involves four steps : components setting, static analysis,control part design and dynamic analysis.

Static and dynamic analysis represent the validationprocedure. It is a compromise between proof and simulationmethods [4]. Static analysis checks the coherence of themodel and dynamic analysis has only to focus on thebehaviour of the system and needs the control.

Components setting and control design represent theprototyping step. Components setting consists in setting thephysical parameters (in the operating part view) and inlinking the different components. Control part design consistsin developing the discrete control of the system. Using thecomponent-based model of the system, component setting isfirst performed. Then, the static analysis checks thecoherence of the model. If the coherence is not established(see section III.A), it is necessary to modify the componentssetting and to start a new static analysis.

Control part design can be performed jointly with the staticanalysis using the results of this analysis as guidelines orindependently (see section III.B). Next step is the dynamicanalysis (see section III.C). It enables to check the behaviourof the components during their exploitation using asimulation method. If this simulation points out problems tothe designer, the control or the parameters have to bemodified and a new complete procedure has to be performed.Otherwise, the model can be validated.

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

A. Static analysis

Static analysis enables a design to be checked, beforesimulation. The static analysis is performed using theconstraints view.

Predicates and more precisely constraints are checkedduring the aggregation of components. The problem is notonly to find good values for components parameters but alsoto check whether adjacent components provide requestedservices.

As classical algorithms for CSP (backtrack, constraintpropagation [5], [6]) are not suitable for our problem, analgorithm has been developed. The principle consists, foreach selected component, in checking:

- whether it is possible to deal with each constraint of a

predicate (i.e. the targeted component is selected for theaggregation step),

- whether the constraint is satisfied.

The status of a predicate is then inferred from itsconstraints’ one. The algorithm provides an error message ifsome constraints linked to main functions are not satisfied. Ifsome constraints linked to a secondary function can not besatisfied, the function is removed and a warning message isprovided. The designer has then to confirm this choice.

Once the aggregation is completed at the level of the finaltransitic system, if some predicates remain unsolved, thesystem then contains some design errors: some componentsare missing or are not well organised, some specification ofco-ordination control are missing, some parameters are notfitted. For instance, static analysis can notify to designer thatthe position of the sensor (Fig. 3) is not correct.

This static analysis can be used during prototyping. Afterthe selected components have been set and joined together,this kind of analysis validates the choices of the designer andalso provides guidelines for the control part design (sectionB). However, static analysis only validates necessaryconditions. Another analysis, more accurate, is imperative inorder to check the behaviour of the controlled system: thedynamic analysis (section C).B. Control part design

The control part design is based on the intrinsic modularityand reusability of the components in a hierarchical structure.Control part is described by means of sequential functioncharts (SFC) and structured text (IEC 61131) and can bestored in a library for reusing. Therefore, in order to performthe control part design of a new component, designer canreuse an archived and validated control part (if thecomponent has similar characteristics).

Our component based model uses a hierarchical multi-level architecture. Consequently, the proposed controlarchitecture is a hierarchical one. When components of leveln are selected for aggregation, the co-ordination of thedifferent control parts has to be specified at level n-1. Thiscontrol part of higher hierarchical level is called hierarchicalcontrol part of the aggregated component (Fig. 5).

Req/Ack

Fig. 5 : Hierarchical control

The hierarchical control part is also described by means of

one SFC. The goal of this high level SFC is to co-ordinatethe execution of low level SFCs. The co-ordination isobtained by the way of the input and output called Req/Ackof each control part. The high level SFC can send a request(Req) to ask a low level control part to start a treatment.Then, at the end of the treatment, the low level control partsends an acknowledgement (Ack). Several aggregatedcomponents can be aggregated using the same method.Therefore, the control part of the aggregated component canreceive requests from higher level and sendsacknowledgements. If low level control parts have tocommunicate, they have to exchange data through thehierarchical control part.

1) Control part design methodology: In order to obtain theentire control part of the workshop, a bottom-up approach isused. The designer has to take ready-to-use basic componentsin the components library and to start the aggregationprocedure. During this procedure, only the hierarchicalcontrol part has to be specified at high level. For the lowlevel control parts, designer has only to set the parameters. Itconsists in adapting the name of the different variables to thenew aggregated component according to an appropriate andgeneric formalism.

In order to obtain the hierarchical control part, designerhas to perform two steps. First, if data have to be exchangedbetween low level components, hierarchical control part hasto ensure the transfer. This step consists in writing equalitybetween concerned inputs and outputs. Secondly, if the lowlevel SFCs have to be co-ordinate, the high level SFC has tobe written using the IEC 61131-3 language. These steps canbe guided using constraints part view as described below.2) Use of constraints part view for control part design: Inorder to define the hierarchical control part, designer can behelp by the results of the static analysis step. The constraintsview of the underlying components enables to obtain someinputs/outputs and the functions the hierarchical control parthas to perform.

a) If some constraints relative to "state" functions have adestination different than other adjacent components, thehierarchical control part has to satisfy these constraints.

For example, let the constraint L4 :(Eject_Input.State.To_Send_Parcel_Eject). If there is noadjacent component able to send an ejection order to the

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

input Eject_Input (then, there is no component linked andstatic analysis shows that constraint L4 is not satisfied),designer has to write a control function in the hierarchicalcontrol part providing this order.

b) If a constraint relative to a "state" function has adestination that concerns an other adjacent component, thehierarchical control part must to have an associated input tobe able to receive the message.

For example, let the constraint L3 :(Downstream12.State.To_Send_Present_Parcel).

His destination is the adjacent component linked by theoutput Downstream12. The constraint impose to thiscomponent (the ramp component) to provide a message whena parcel is detected by the sensor. Therefore, in thehierarchical control part, an associated input has to be used.3) Control part writing: Controls have to be written inorder to simulate the effects on the system and finally, toimplement them on programmable logic controllers. Theycan be written using softwares that are compatible to theIEC 61131 standards. ISaGRAF software [7] has been usedto write the different controls and to automatically translatethem to programmable logic controllers. This kind ofsoftware enables Instruction List, Ladder Diagram,Structured Text, and Sequential Function Chart. Thehierarchical control is automatically translated into hierarchyof SFCs. The co-ordination of several SFCs by the upperlevel SFC is performed using global variables. Thesevariables represent the Ack/Req I/O previously described.When the control part design step is terminated, it isnecessary to begin the dynamic analysis.C. Dynamic analysis

Dynamic analysis enables to study the behaviour thesystem is going to have during the exploitation. The goal is:- to validate the control of each component, as well as the

control co-operation between components;

- to check that the chosen parameters will enable to obtain

the wished performances.

The selected method here is the simulation of bothoperating part and control part of the whole system. Thisstage has then to be performed after control obtaining. Thejoint simulation is performed using SimSED tool (see sectionIV).

The visualisation of possible problems is performed usingthe graphical model of the system. This model isautomatically obtained from the graphical views of theselected components. Some components, that display curves,can also be added. Problems like critical speed oracceleration, low sensor tolerance, parcels collision arerevealed. Another frequent detected problem is the presenceof non-exclusive transitions between several exclusivecontrol states.

Simulation is attractive. It is the reason why it is largelyused in industry. The drawback is that the system is onlyvalidated according with a set of scenarii. The range ofscenarii to be checked can be fortunately reduced by thestatic analysis.

IV. SIMSED TOOL

SimSED has been developed in Java language (Jdk1.3,graphical library Swing). The tool enables the edition(settlement of components, link between components,aggregation), constraints analysis and the simulation of atransitic system. It also includes a library of components thatcan be parameterised. If the components the designer needsare in the library, the workshop is defined through agraphical interface by selecting and linking the components.Designer can also develop his own views and components inJava language. The code writing is largely simplified by theopportunity to use some templates. The designer has to focuson the definition of the dynamic behaviour of components.Controls can be written in Java and simulated through thesimulation engine of SimSED. They can also be developedand simulated using ISaGRAF. SimSED is indeed open andcan exchange with other simulators through an OPC (OLEfor Process Control) connection. The interest is to simulateand test controls that will be really implemented, without anytranscription. In addition, it enables the simulation to bedistributed [8].

As an example, a part of the transitic system Fig. 1 ismodeled and simulated using both SimSED and ISaGRAF.Fig. 6 presents the edition interface. The differentcomponents are settled, linked together, linked with I/O ofISaGRAF control programs. Their graphical views thatappear here as boxes with inputs are also chosen during thisphase.

The constraints view of each component is obtained byright click. The static analysis is performed when severalcomponents are selected and aggregated.

V. INTEGRATION

The last step concerns the integration of both control andphysical parts of the system. The obtained model has to beimplemented on operational architecture. The differentcomponents are well parameterised, chosen and organised.The control of each component is coherent, the componentbehaviour is correct and the majority of the problems have

been detected and eliminated.

Fig. 6: Edition interface of SimSED Tool

The aim of this paper is to present a component-based approach for the design of transitic systems and their implementation on operational architecture. It considers a flow that applies from specifications to integration the same model. This model is obtai

Using the operative part view, it is possible to start theinstallation of modelled entities. Each part of the transiticsystem can be fit up. The choice of physical parts is veryeasy because all parameters are fixed and the characteristicsof the components (conveyors, elevators, consignments,sorters, etc.) to install are well known and unambiguous.

Using the control part view, it is possible to implement thecode on controllers. ISaGRAF enables to generate directlythe code that must be load on the controller. Control can beimplemented on standards Programmable Logic Controllers(PLC) or on dedicated controllers. We develop at theLESTER laboratory a dedicated controller called nano-controller. The advantages of a nano-controller are describedbellow:

- the nano-controller is smaller than a classic controller

and can be installed very close to the physical parts it hasto control (connections, time to transmit orders toactuators and to receive information from sensors arethen reduced),

- many nano-controllers can be used to execute very

quickly the control of each low level components and amore global standard PLC can be used to execute thehierarchical control in a distributed manner,

- a nano-controller can be dedicated to specific control

tasks,

- a nano-controller is synthesised considering the

partitioning problem: several control tasks can beimplemented in software and others in hardware,

- a nano-controller is synthesised taking into account the

control task it has to execute and the operationalcomponent it has to control. Therefore, it is possible toanticipate the memory size, the number of I/O, theprocessor speed, etc.

Actually, the operational architecture for the nano-controller is composed of a NIOS Processor (it is aconfigurable RISC Processor) and a dedicated module forlow level communication by means of ASI-bus (ActuatorsSensors Interface bus). This dedicated module is describedusing VHDL (Very high speed integrated circuits HardwareDescription Language) and is synthesised on a FPGA (FieldProgrammable Gate Array). The control code is executedmainly by the NIOS Processor (software part) and somespecific treatments are implemented on the FPGA (hardwarepart). The nano-controller can be seen as an embeddedsystem or SOC (System On Chip) [9] dedicated to specificcontrol tasks described by the control part view of thecomponents.

VI. CONCLUSION

The aim of the presented method is to propose acomponent-based model of a transitic system and to validatethis system conjointly with its prototyping. On the basis ofthe obtained model, the prototyping step enables choice ofphysical parameters and control elaboration. The validationstep is based on simulation and a more formal approachbased on constraints satisfaction. The degradation risk duringthe on-site test is then reduced and the method enables to test

different possible solutions. The model is then implementedon the operational architecture. Parts of the transitic systemhave to be put together on the workshop and controls have tobe implemented on controllers (classical PLC or dedicatednano-controllers).

Further works would improve the component model byadding an other view stored in the library: the monitoringview. Monitoring view analyses whether the system followsthe specifications, from both operating part and control partlevel. During an integration phase, it would be synthesised onthe nano-controller in order to implement a reconfigurationprocess. We study also an other architecture to co-ordinatethe distributed components: the heterarchical one. The multi-agent paradigm could be used to model the entities with amore sophisticated control part view allowing the system tobe automatically reconfigured when disturbances appears.

VII. REFERENCES

[1]A. Doniavi, A.R. Mileham and L.B. Newnes, "Systems

Modelling Methodologies in the ManufacturingEnvironment", in proceedings of 15th IMACS WorldCongress, Vol. 5, Berlin, august 1997, pp. 373-378.[2]T. Kamigaki and N. Nakamura, "An Object-Oriented

Visual Model - Building and Simulation System forFMS Control", Simulation, vol. 67, n°6, 1996, pp. 375-385.[3]J.S. Mouchard, P. Berruet, J.L. Philippe, J.P. Guyomar,

"Modeling, simulating and validation: an application tothe design of transitic systems", in proceedings of IFACMCPL2000, Grenoble, July 2000, pp. 109-114.[4]P. Berruet, J.S. Mouchard, J.L. Philippe, J.P. Guyomar,

"Modeling and validation of transitic systems based onreusable components", in proceedings of IIIS/IEEEconference SCI’2001, Orlando, July 2001, Vol.3,pp. 286-291.[5]J. Cuelar, I. Wildgruber, D. Barnard, "Combining the

design of industrial systems with effective verificationtechniques", in proceedings of FME’94, Barcelona1994, pp. 639-658.[6]R. Bartak, "Constraints Programming: In Pursuit of the

Holy Grail", in proceedings of WDS’99, Prague, TchecRepublic, June 1999.[7]ISaGRAF User Guide, CJ International, 1997.

[8]R.W. Tarr and R.W. Jacobs, "Distributed Interactive

Simulation: What is it and where is it going", inproceedings of SCS'95, Ottawa, Canada, 1995.[9]M Courvoisier, M. Combacau, M. Paludetto, The

industrial electronics handbook, CRC & IEEE Press,1997.

本文来源：https://www.bwwdw.com/article/sksm.html