From Design to Integration of Transitic Systems A Component(4)

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.