From Design to Integration of Transitic Systems A Component Based Approach

A Component Based ApproachThierry COUDERT1, Pascal BERRUET, Jean-Luc PHILIPPELESTERUniversité de Bretagne SudCentre de rechercheRue Saint MaudeBP 9211656321 LORIENT CedexFranceTel: (33/0)2.97.87.45.25Fax: (33/0)2.97.87.45.05email: {thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.frTOPICAL AREA:INDUSTRIAL INFORMATION TECHNOLOGYSUBJECT AREA: Intelligent transportationFlexible manufacturing systemIndustrial automationCADCIMKEYWORDS: Transportation systemsComponentsDesignSimulationIntegrationControl1 Contact authorA Component Based ApproachThierry COUDERT*, Pascal BERRUET, Jean-Luc PHILIPPELESTER, Université de Bretagne SudCentre de recherche, rue St Maude, BP 92116, 56321 LORIENT Cedex, FranceTel: (33/0)2.97.87.45.25 fax: (33/0)2.97.87.45.05email :{ thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.frABSTRACTThe 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 obtained from design requirements. Two steps are then conjointly performed: validation and prototyping. The validation step is based 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 an operational architecture. The different parts of the transitic system corresponding to the model have to be installed and the control has to be implemented on controllers. Controllers can be classical Programmable Logic Controllers or dedicated controllers. A new kind of controller developed at the LESTER Laboratory is described: the nano-controller.A Component-Based ApproachThierry COUDERT, Pascal BERRUET, Jean-Luc PHILIPPEUniversité Bretagne SudLESTER - Centre de RechercheRue de Saint Maude - BP 9211656321 LORIENT Cedex - FRANCE{thierry.coudert, pascal.berruet, jean-luc.philippe}@univ-ubs.frAbstract –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 obtained from design requirements. Two steps are then conjointly performed: validation and prototyping. Validation is based on simulation and a more formal approach. Prototyping enables choice of parameters and control elaboration. The last step is the integration. The different parts of the workshop have to be installed and controls implemented on classical Programmable Logic Controllers or on dedicated ones: the nano-controllers.I. INTRODUCTIONTransitic systems are particular manufacturing systems that transport parcels from different locations with a fast flow and dispatch them to their right locations. They are composed of different types of conveyors, elevators, consignments, sorters, and automated guided vehicles (Fig. 1). Conveyors can be linear, curved, and circular. They can have pneumatic jacks, stops, and switchings.Designers of such manufacturing systems are confronted to many problems. The complexity requires modular approaches in order to decompose very large and complex design problems in more simple ones. The best appropriateness between functional solutions and material architecture has to be obtain at the earliest stage of design. Facing very competitive markets, time to design and implement a new transitic system has to be reduced. A transitic system has to be robust, easy to maintain, easy to control, flexible, modular and fault tolerant. Several solutions are possible with different costs and have to be evaluated in order to choose the optimal one. The reusability aspect is also very important enabling designers to reuse some validated parts.This work concerns a major project that provides a framework from design to integration of transitic systems including both control and material part. The goal is to propose to designers a component-based model enabling them to choose the different physical parts of the real system, to design the control, to check the behaviour of the controlled system and to test it before on-site implementation. When the different components are well parameterised, chosen and organised, the control is coherent and the system behaviour is consistent with specifications, the obtained model can be implemented on an operational architecture.Fig. 1: Example of transitic systemThe general approach is summarised Fig. 2. It considers a flow that applies from specifications to integration the same component-based model obtained from design requirements (modelling step). On the basis of this model, two steps are then conjointly performed: prototyping and validation. The prototyping step enables choice of physical parameters and control elaboration. The validation step is based on simulation and a more formal approach based on constraints satisfaction. The model is then implemented on the operational architecture (integration step). Parts of the transitic system have to be put together on the workshop and controls have to be implemented on controllers.Fig. 2: Design flow approachThe component-based model, built from components chosen in a library, is defined in section II. In section III, validation and prototyping steps are described by the definition of the different analysis methods and the methodology for control design. Section IV presents a tool named SimSED developed in collaboration with the Sydel society. This tool enables to exploit our approach and is very helpful for designers. The section V presents the integration step.II. MODELLINGThe approach needs to model physical environment on which the control is going to interact [1]. A component-based model has been adopted. It provides a clear and easy way to reuse previously modeled elements or to modify the system’s internal structure.A component models a part of a transitic system, at the level 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 an assembling of components. Different sub-models (Operating part, Constraints, Control part) of the workshop are obtained from these views.The component description uses a black-box formalism. Inputs / Outputs relative to physical flow (connected with variables corresponding to parcels' passing) are separated from Inputs / Outputs that give account of information relative to sensors, actuators, communication, …All components include parameters providing adaptability to different design. They are stored in a library as validated ready-to-use models. This enables reusing [2].An aggregation procedure has been developed. It consists in obtaining one component of level n from several components of level n-1 brought together. As components have the same structure at any abstraction level, the hierarchical component can easily be stored and reused for future workshops design.The complete workshop model is obtained by successively aggregating components until having one representing the whole system. If the study is based on an existing system, the first step consists in a structural splitting up in order to get components [3].A. Operating part viewOperating part view models possible physical behaviour of the modeled entity.This model includes both discrete evolutions of the component and physical laws (linear or not), in order to represent mechanical, pneumatic and/or hydraulic phenomena. 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 of realistic possible behaviour of the modeled entity, without any limitation on its inputs.As phenomena can be very complex to get, this view can be obtained based on a structural splitting up approach. Beside elements such as elevator (with several inputs and outputs), sorter (with several consignment areas), conveyor with ejection jack and stop, the library also includes basic elements such as pneumatic jack with return effect, sensor models…B. Constraints part viewConstraints view expresses with a given syntax the different functions, a component can perform, and what it demands from adjacent components.The syntax is based on the concept of predicate. A predicate provides the constraints that condition a function. Four main functions have been identified: to switch, to regulate, to observe and to transport. Other functions, called secondary functions, characterise all other actions the component 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 an information variable.In a predicate the function is linked to a set of constraints with a necessity operator (requires) or an implication operator (if), depending whether the function is imperative or not.Constraints are expressed with "Destination.Type.Item". Destination indicates the targeted components, referring to the I/O they are connected. Three types are possible: Service (constraint relative to a "service" function), State (constraint relative to a "state" function) and Parameter (relation concerning a physical parameter of a component). Item characterises the name of the function or the relation about a parameter.In order to illustrate the constraint part view of a component, an example of sorter component is presented Fig. 3. This kind of component is used to sort parcels in the transitic system. Several parcels can be ejected by the jack when they are detected, others keep straight on.This example contains two components: a sorter component and a ramp component. The sorter component is linked 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.Fig. 3: Example of sorter componentAn example of predicate concerning the sorter component is detailed below:L1: To_Switch requiresL2:((Upstream11.Service.To_Space_out_Parcels)andL3:(Downstream12.State.To_Send_Present_Parcel)andL4:(Eject_Input.State.To_Send_Parcel_Eject) and L5: (Downstream12.Parameter.Sensor_Position =Parcel_width))This means that this component has to ensure a switching function. This function requires that (L1):- the previous adjacent component linked by the inputUpstream11 has to space parcels out (L2);- the next adjacent component linked by the outputDownstream12 (i.e. the ramp component) has to send to the sorter component a message of presence of parcel (L3);- the input called Eject_Input has to be linked to acomponent (eventually a control output) that delivers an ejection order (L4);- the sensor position of the next adjacent componentlinked by the output Downstream12 has to be equal to the width of a parcel (L5).C. Control part viewControl part view expresses the control essentially discrete of the modeled entity. This control can be effective. This means that it gives the actions sequences the succession of which immediately depends on the previous action or directly on a sensor. In this case, control outputs directly fit physical output based on cards.Control can also be considered at a higher level. In this case, it co-ordinates some entities, implementing some management strategies (especially during the aggregation of several components).Control part view is written using the IEC 61131languages (essentially sequential function charts and structured text). The control part design is described in section III.D. Graphical viewGraphical view enables to display, with more or less details, the component during the simulation phase.It also enables to take manual action of an operator into account (e.g. push-button on a control panel).It can be noticed that a component has not necessarily a graphical view. A single graphical view can be affected to a set 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 does not imply a complex graphical view to display relevant information.III. VALIDATION AND PROTOTYPINGIn the proposed approach, validation and prototyping steps are 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 validation procedure. It is a compromise between proof and simulation methods [4]. Static analysis checks the coherence of the model and dynamic analysis has only to focus on the behaviour of the system and needs the control.Components setting and control design represent the prototyping step. Components setting consists in setting the physical parameters (in the operating part view) and in linking the different components. Control part design consists in developing the discrete control of the system. Using the component-based model of the system, component setting is first performed. Then, the static analysis checks the coherence of the model. If the coherence is not established (see section III.A), it is necessary to modify the components setting and to start a new static analysis.Control part design can be performed jointly with the static analysis using the results of this analysis as guidelines or independently (see section III.B). Next step is the dynamic analysis (see section III.C). It enables to check the behaviour of the components during their exploitation using a simulation method. If this simulation points out problems to the designer, the control or the parameters have to be modified and a new complete procedure has to be performed.Otherwise, the model can be validated.A. Static analysisStatic analysis enables a design to be checked, before simulation. The static analysis is performed using the constraints view.Predicates and more precisely constraints are checked during the aggregation of components. The problem is not only to find good values for components parameters but also to check whether adjacent components provide requested services.As classical algorithms for CSP (backtrack, constraint propagation [5], [6]) are not suitable for our problem, an algorithm has been developed. The principle consists, for each selected component, in checking:-whether it is possible to deal with each constraint of a predicate (i.e. the targeted component is selected for the aggregation step),-whether the constraint is satisfied.The status of a predicate is then inferred from its constraints’ one. The algorithm provides an error message if some constraints linked to main functions are not satisfied. If some constraints linked to a secondary function can not be satisfied, the function is removed and a warning message is provided. The designer has then to confirm this choice. Once the aggregation is completed at the level of the final transitic system, if some predicates remain unsolved, the system then contains some design errors: some components are missing or are not well organised, some specification of co-ordination control are missing, some parameters are not fitted. For instance, static analysis can notify to designer that the position of the sensor (Fig. 3) is not correct.This static analysis can be used during prototyping. After the selected components have been set and joined together, this kind of analysis validates the choices of the designer and also provides guidelines for the control part design (section B). However, static analysis only validates necessary conditions. Another analysis, more accurate, is imperative in order to check the behaviour of the controlled system: the dynamic analysis (section C).B. Control part designThe control part design is based on the intrinsic modularity and reusability of the components in a hierarchical structure. Control part is described by means of sequential function charts (SFC) and structured text (IEC 61131) and can be stored in a library for reusing. Therefore, in order to perform the control part design of a new component, designer can reuse an archived and validated control part (if the component has similar characteristics).Our component based model uses a hierarchical multi-level architecture. Consequently, the proposed control architecture is a hierarchical one. When components of level n are selected for aggregation, the co-ordination of the different control parts has to be specified at level n-1. This control part of higher hierarchical level is called hierarchical control part of the aggregated component (Fig. 5).Req/AckFig. 5 : Hierarchical controlThe hierarchical control part is also described by means of one SFC. The goal of this high level SFC is to co-ordinate the execution of low level SFCs. The co-ordination is obtained by the way of the input and output called Req/Ack of 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 part sends an acknowledgement (Ack). Several aggregated components can be aggregated using the same method. Therefore, the control part of the aggregated component can receive requests from higher level and sends acknowledgements. If low level control parts have to communicate, they have to exchange data through the hierarchical control part.1) Control part design methodology: In order to obtain the entire control part of the workshop, a bottom-up approach is used. The designer has to take ready-to-use basic components in the components library and to start the aggregation procedure. During this procedure, only the hierarchical control part has to be specified at high level. For the low level control parts, designer has only to set the parameters. It consists in adapting the name of the different variables to the new aggregated component according to an appropriate and generic formalism.In order to obtain the hierarchical control part, designer has to perform two steps. First, if data have to be exchanged between low level components, hierarchical control part has to ensure the transfer. This step consists in writing equality between concerned inputs and outputs. Secondly, if the low level SFCs have to be co-ordinate, the high level SFC has to be written using the IEC 61131-3 language. These steps can be guided using constraints part view as described below. 2) Use of constraints part view for control part design: In order to define the hierarchical control part, designer can be help by the results of the static analysis step. The constraints view of the underlying components enables to obtain some inputs/outputs and the functions the hierarchical control part has to perform.a) If some constraints relative to "state" functions have a destination different than other adjacent components, the hierarchical control part has to satisfy these constraints.For example, let the constraint L4 : (Eject_Input.State.To_Send_Parcel_Eject). If there is no adjacent component able to send an ejection order to theinput Eject_Input (then, there is no component linked and static analysis shows that constraint L4 is not satisfied), designer has to write a control function in the hierarchical control part providing this order.b) If a constraint relative to a "state" function has a destination that concerns an other adjacent component, the hierarchical control part must to have an associated input to be 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 the output Downstream12. The constraint impose to this component (the ramp component) to provide a message when a parcel is detected by the sensor. Therefore, in the hierarchical control part, an associated input has to be used.3) Control part writing: Controls have to be written in order to simulate the effects on the system and finally, to implement them on programmable logic controllers. They can be written using softwares that are compatible to the IEC 61131 standards. ISaGRAF software [7] has been used to write the different controls and to automatically translate them to programmable logic controllers. This kind of software enables Instruction List, Ladder Diagram, Structured Text, and Sequential Function Chart. The hierarchical control is automatically translated into hierarchy of SFCs. The co-ordination of several SFCs by the upper level SFC is performed using global variables. These variables represent the Ack/Req I/O previously described. When the control part design step is terminated, it is necessary to begin the dynamic analysis.C. Dynamic analysisDynamic analysis enables to study the behaviour the system 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 both operating part and control part of the whole system. This stage has then to be performed after control obtaining. The joint simulation is performed using SimSED tool (see section IV).The visualisation of possible problems is performed using the graphical model of the system. This model is automatically obtained from the graphical views of the selected components. Some components, that display curves, can also be added. Problems like critical speed or acceleration, low sensor tolerance, parcels collision are revealed. Another frequent detected problem is the presence of non-exclusive transitions between several exclusive control states.Simulation is attractive. It is the reason why it is largely used in industry. The drawback is that the system is only validated according with a set of scenarii. The range of scenarii to be checked can be fortunately reduced by the static analysis.IV. SIMSED TOOLSimSED 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 a transitic system. It also includes a library of components that can be parameterised. If the components the designer needs are in the library, the workshop is defined through a graphical interface by selecting and linking the components. Designer can also develop his own views and components in Java language. The code writing is largely simplified by the opportunity to use some templates. The designer has to focus on the definition of the dynamic behaviour of components. Controls can be written in Java and simulated through the simulation engine of SimSED. They can also be developed and simulated using ISaGRAF. SimSED is indeed open and can exchange with other simulators through an OPC (OLE for Process Control) connection. The interest is to simulate and test controls that will be really implemented, without any transcription. In addition, it enables the simulation to be distributed [8].As an example, a part of the transitic system Fig. 1 is modeled and simulated using both SimSED and ISaGRAF. Fig. 6 presents the edition interface. The different components are settled, linked together, linked with I/O of ISaGRAF control programs. Their graphical views that appear here as boxes with inputs are also chosen during this phase.The constraints view of each component is obtained by right click. The static analysis is performed when several components are selected and aggregated.V. INTEGRATIONThe last step concerns the integration of both control and physical parts of the system. The obtained model has to be implemented on operational architecture. The different components are well parameterised, chosen and organised. The control of each component is coherent, the component behaviour is correct and the majority of the problems havebeen detected and eliminated.Fig. 6: Edition interface of SimSED ToolUsing the operative part view, it is possible to start the installation of modelled entities. Each part of the transitic system can be fit up. The choice of physical parts is very easy because all parameters are fixed and the characteristics of the components (conveyors, elevators, consignments, sorters, etc.) to install are well known and unambiguous. Using the control part view, it is possible to implement the code on controllers. ISaGRAF enables to generate directly the code that must be load on the controller. Control can be implemented on standards Programmable Logic Controllers (PLC) or on dedicated controllers. We develop at the LESTER laboratory a dedicated controller called nano-controller. The advantages of a nano-controller are described bellow:-the nano-controller is smaller than a classic controller and can be installed very close to the physical parts it has to control (connections, time to transmit orders to actuators and to receive information from sensors are then reduced),-many nano-controllers can be used to execute very quickly the control of each low level components and a more global standard PLC can be used to execute the hierarchical 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 be implemented in software and others in hardware,- a nano-controller is synthesised taking into account the control task it has to execute and the operational component it has to control. Therefore, it is possible to anticipate the memory size, the number of I/O, the processor speed, etc.Actually, the operational architecture for the nano-controller is composed of a NIOS Processor (it is a configurable RISC Processor) and a dedicated module for low level communication by means of ASI-bus (Actuators Sensors Interface bus). This dedicated module is described using VHDL (Very high speed integrated circuits Hardware Description Language) and is synthesised on a FPGA (Field Programmable Gate Array). The control code is executed mainly by the NIOS Processor (software part) and some specific treatments are implemented on the FPGA (hardware part). The nano-controller can be seen as an embedded system or SOC (System On Chip) [9] dedicated to specific control tasks described by the control part view of the components.VI. CONCLUSIONThe aim of the presented method is to propose a component-based model of a transitic system and to validate this system conjointly with its prototyping. On the basis of the obtained model, the prototyping step enables choice of physical parameters and control elaboration. The validation step is based on simulation and a more formal approach based on constraints satisfaction. The degradation risk during the on-site test is then reduced and the method enables to test different possible solutions. The model is then implemented on the operational architecture. Parts of the transitic system have to be put together on the workshop and controls have to be implemented on controllers (classical PLC or dedicated nano-controllers).Further works would improve the component model by adding an other view stored in the library: the monitoring view. Monitoring view analyses whether the system follows the specifications, from both operating part and control part level. During an integration phase, it would be synthesised on the nano-controller in order to implement a reconfiguration process. We study also an other architecture to co-ordinate the distributed components: the heterarchical one. The multi-agent paradigm could be used to model the entities with a more sophisticated control part view allowing the system to be automatically reconfigured when disturbances appears.VII. REFERENCES[1] A. Doniavi, A.R. Mileham and L.B. Newnes, "SystemsModelling Methodologies in the Manufacturing Environment", in proceedings of 15th IMACS World Congress, Vol. 5, Berlin, august 1997, pp. 373-378. [2]T. Kamigaki and N. Nakamura, "An Object-OrientedVisual Model - Building and Simulation System for FMS 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 to the design of transitic systems", in proceedings of IFAC MCPL2000, 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 on reusable components", in proceedings of IIIS/IEEE conference SCI’2001, Orlando, July 2001, Vol.3, pp. 286-291.[5]J. Cuelar, I. Wildgruber, D. Barnard, "Combining thedesign of industrial systems with effective verification techniques", in proceedings of FME’94, Barcelona 1994, pp. 639-658.[6]R. Bartak, "Constraints Programming: In Pursuit of theHoly Grail", in proceedings of WDS’99, Prague, Tchec Republic, June 1999.[7]ISaGRAF User Guide, CJ International, 1997.[8]R.W. Tarr and R.W. Jacobs, "Distributed InteractiveSimulation: What is it and where is it going", in proceedings of SCS'95, Ottawa, Canada, 1995.[9]M Courvoisier, M. Combacau, M. Paludetto, Theindustrial electronics handbook, CRC & IEEE Press, 1997.。