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

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