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.