- Email: [email protected]
Building Distributed Architectures by the Interconnection of Intelligent Instruments
Copyright © IFAC Information Control in Manufacturing, Nancy - Metz, France, 1998
BUILDING DISTRIBUTED ARCHITECTURES BY THE INTERCONNECTION OF INTELLIGENT INSTRUMENTS A. Bouras1,2 ,M. Staroswiecki1
1 LAIL URA CNRS 1440 Bat P2, UFR d'IEEA, Univ des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq cedex-France, e-mail: [email protected] 2 Ecole des Mines de Douai, 941 Rue Charles Bourseul 59508 Douai cedex France
Abstract: In this paper we present a generic intelligent instrument descriptive model and an aggregation mechanism which allows to model composite instruments resulting from the interconnection of simple ones. The interoperability is defined as the possibility for the set of interconnected instruments to meet the application constraints. The supervisory language of the overall distributed control structure is calculated. Copyright © 1998 IFAC Keywords: Intelligent instruments, Interoperability, Distributed Architectures.
1. INTRODUCTION
Automated system design based on intelligent instruments is a very difficult task, since it rests on the integration of instruments functionalities which may largely differ from one supplier to another one, and which may meet more or less precisely the overall system needs. The possibility of meeting the specifications of a given application by building up a distributed architecture through the interconnection of a set of intelligent instruments will be refered to as the interoperability property of these instruments. In this framework, interconnection means that a given set of instruments are able to exchange data and control information, through a communication system which might for example be a local area network. The possibility to communicate data and messages using a given LAN protocol is refered to as the intercommunication property. One immediately sees that intercommunication constitutes a necessary condition, not always easy to fulfill, but in very few cases is this condition a sufficient one.
The intelligent instrument concept appeared when sensors and actuators began to integrate their own processing power, at drastically decreasing costs. The impact of the technical revolution in the area of sensors and actuators can be analyzed according to three viewpoints. -As tools dedicated to a precise function, their performances depend on their processing power. -As industrial products, their life cycle contains several phases. In configuration, implementation, exploitation, test and maintenance phases, intelligent sensors or actuators can propose different services to different users. -As components of automated systems, whose increasing complexity justifies the trend from centralized architectures towards distributed ones, intelligent sensors and actuators are the most appropriate equipments to receive part of the data and processing flows, so as to perform locally a part of the global application.
Assessing the interoperability property supposes a precise knowledge of the functionalities which are
559
offered by each equipment, hence it is necessary that should be stabilized a certain number of concepts allowing the description of intelligent instruments and the manipulation of their models. The three-fold analysis of an intelligent instrument leads to three possible approaches for its modeling. • The first viewpoint leads to a descriptive analysis in terms of the services the instrument is able to provide its users (Staroswiecki and Bayart, 1996; Bouras et al, 1995). • The second viewpoint leads to an analysis in terms of User Operating Modes (USOM) so as to specify the instrument different exploitation types (Staroswiecki and Bayart, 1996). • The third viewpoint leads to an analysis in terms of constraints to be fulfilled in order to guarantee the interoperability of an equipment set in the framework of a given application (Bouras and Staroswiecki, 1997). The first two viewpoints describe the instrument as it is provided by its supplier. The third one describes the application the instrument will contribute to. Using a generic external description model presented in Staroswiecki and Bayart (1996) and the interoperabilty check fITst introduced in Bouras and Staroswiecki (1997), this paper presents a contribution to the formalization of the design of the overall distributed application, and to the determination of its supervisory language. We do not intend to model the intercommunication requirements or to study the impact of fieldbuses on systems architectures (Klaseen and Sydir, 1995; Neumann et aI, 1995), nor to optimize the distribution of application functions on the local processing stations (Sinclair, 1987) or to validate some critical time constraints (Joseph, 1996). Merely, we intend to show how it is possible to systematically build up high level services (those the user sees at the application level) from low level ones (those the individual instruments are able to provide), and how the services should be organized in order to fulfill some application requirements. The first part of the paper will discuss the interoperability issues, and present the generic external model we propose for the description and manipulation of intelligent instruments. In the second part, we show that the application constraints lead to organize the services into a menu graph. The third part describes the determination of the set of the allowable requests sequences which constitute the supervisory language of the overall application. An illustrative example is provided in the last part.
the field level. Easy interconnections should characterize distributed automated systems based on intelligent instruments. However many efforts have been devoted to the communication function, in the view of field bus standardization, it is only very recently that those efforts led to the EN50170 norm at the European level (EN50170, 1996). The design of a distributed application using field instruments issued from different constructors is not only based on the use of a common communication standard. Given the infinite number of performable functions and possible implementations of intelligent instruments, some design rules are imperative in order to propose 'open' concepts allowing a compatibility between the field devices offered by different constructors. This is the main reason why, in addition to the communication protocol layers (in most field buses layers 1, 2 and 7 of the OSI model), different working groups have focused on description standards for the so-called «application layer» (mainly through the use of function blocks (ISA/SP50, 1993; PRIAM, 1995; Westbrock, 1992». The generic functional internal model of an intelligent instrument (Riviere et aI, 1996; Gehin, 1994) is intended to provide such an open description, in order to validate the interoperability property.
2.2 Interoperability We define the interoperability of a set of instruments as the possibility to build an application using this set of instruments, at a given cost. In fact it is always possible to make different instruments work together, writing specific drivers, and adaptation software in a coordination layer. However, the cost of this layer could sometimes be so high that one better chooses other field level components. Interoperable instruments should induce minimal (or at least affordable) extra costs for the coordination layer. This coordination layer has to insure: • That data and requests addressed from one instrument to another one are interpreted and executed by the receiver exactly as the sender expects. • That the application constraints are satisfied during the system operation. To anticipate the interoperability of a set of components it is therefore required first to precisely model each component 'intelligence', second to express the application constraints, in order to check if they can be derived in terms of instrument behaviors, third to express the set of the requests which may be addressed to the interconnected instruments and which satisfy the constraints.
2. INTEROPERABILITY
2.1 Intercommunication Automated systems can be build using several hardware architectures that allow a communication at
560
2.3 A Generic External Model of Intelligent Instruments
requests sequences) is easy to derive, as we will see later.
To integrate the interoperability considerations in the intelligent instrumentation concept it is necessary to describe the intelligent instrument as it is seen through the communication network, this means form an external viewpoint, i.e. without any description of how internal processing are realized (Staroswiecki and Bayart, 1996). For an external entity the intelligent instrument may be described as a process proposing services which manipulate variables and make use of resources. A service is processed on the reception of a specific request. The set of all the requests an intelligent instrument «understands» constitutes its supervisory language. According to the resources availability, the services may run in nominal or degraded versions. The resources availability is determined by the instrument Fault Detection and Isolation (FDI) ability (Cassar et aI, 1992; Cocquempot, 1993). When no version of a service can be run, the service becomes unavailable. To avoid users incompatible requests, the set of services of an intelligent instrument is organized into coherent subsets called User Operating Modes (USOM). A USOM is a subset of services that the user may require in a given situation in the life cycle of the intelligent instrument. At each time, the instrument is in a given current USOM: the only services whose execution is allowed are those belonging to this mode, requests for any other service are automatically rejected. The definition of the set of USOM, and for each of them, the list of services and changing mode conditions, specify the instrument USOM management system and may be represented using a state graph. The transitions represent the changing mode conditions which may include some conditions about the availability of particular services. Appendix 1 gives a description of the generic external model of an intelligent instrument in the Backus Naur norm protocol language (C46-645).
3. APPLICATION CONSTRAINTS We characterize the architecture of a distributed system fifst by its components, second by their interconnection system. Each of the instruments, as well as the communication network (Tricquet et al, 1997), can be described by the generic external model given in the first part. From a global point of view, the application we want to build has to provide some services, while satisfying some constraints (e.g. specific on/off-procedure, ordered sequences of actions,...). Thus, the interoperability of the instruments we want to use in the frame of the application we want to build rests on the possibility to obtain the set of the services of the application from the set of the services of the aggregated instrument which represents the system architecture. Interoperability cannot be achieved when the former cannot be obtained using the latter. When the instruments are interoperable, the simplest situation is the one in which the application does not forbid any of the possible services (or sequence of services) provided by the overall aggregated instrument. In this case, the instruments are interoperable at the cost of an overall control level which only has to provide at each time the proper (coherent) combination of the individual USOMs. However, the general case introduces constraints which forbid some services (or sequences of services) so that the interoperability cost is increased by the cost of the elaboration of some software which guarantees the constraints satisfaction.
3.1 What is a constraint? The absence of constraint is seen by the user as the possibility to execute at any time any service of his choice on any instrument. The supervisory language of the application is in that case the supervisory language of the composed instrument which aggregates all the low level ones. However the user's choice is seldom open. For example, a start procedure might introduce an order relation on a subset of services. Although all necessary resources for the execution of a service are available, some conditions might have to be true before the service becomes activable by the user. These conditions are called constraints. A service is activable at a given time, if its execution can be requested at this time. The activability of a service s is a binary variable A(s,t) such that A(s,t) =1 iff the service (s) is activable at time t. We postulate that a constraint on a service is formulated by a condition which has to be true in order for the service to be activable. This means that
2.4 Aggregated (high level) instruments High level (virtual) instruments may be considered, which interconnect low level ones. As an example, a heater (high level instrument) is defined by the interconnection of a burner, a fuel pump, an ignitor and a ventilator (simple or low level instruments). The aggregation of simple instruments into higher level ones is obtained through simple model manipulations : the set of the services of a composed instrument is the union of the sets of the services of the elementary ones, while its USOM graph is the asynchroneous product of the low level USOM graphs (Bouras, 1997). The supervisory language of an aggregated instrument (the set of all the possible
561
there exists an assertion whose evaluation determines whether the service is activable or not. The set of such assertions expresses the global constraints repercussion on the operating level.
We suppose that the time granularity is small enough so that two events don't happen at the same time. A steady state operation step (SSOS) is a time interval [Tk;Tk+ 1[ during which the state of the system does not change. \f t E [Tk;Tk+ 1[ X(t) = X(Tk) Let us consider the set of the possible SSOS of a given application. The application is coherently designed if, for each service, there exists at least one SSOS during which the service is activable. "Is E SeA) 3 Tk ,Tk+ 1 and X[Tk] such that "I t E [Tk, Tk+l[ A(s,t) = 1 The menu Il[X(T0] (or Ilk if no confusion is possible) associated with an SSOS is the subset of all the services which are activable during this SSOS. Remarks: 1- A menu might be empty; in this case the system is said to be non controllable by the user during the corresponding SSOS. 2- The same menu can be associated to different SSOS. Let E[X(T0] (or E k if no confusion is possible) the subset of events of E(A) that can happen when the system is in the state X(T0. The knowledge of (Il[X(T 0] ; E[X(T0]) allows to determine all the possible J,l[X(Tk+l)] Proof: S+[e(Tk+l)] and S-[e(Tk+1)] are known for each possible e(Tk+1). The menus J,l[X(Tk+1)] are deduced from J,l[X(TJ] by the following operation: Ilk+l = [Ilk U S+(ek+l)] \ S-(ek+l) (1) with ek+l E E k ~ E(A) The triple [Il(X(Tk)]; e(Tk+1); J,l[X(Tk+1)]] is unique. The couple (Il[X(TJ]; e(Tk+1» defines Il[X(Tk+1)] in a unique way.
3.2 Expression and effect ofa constraint To express a constraint returns to express the assertion that describes it. At each evaluation time, three possible situations have to be considered : 1. The assertion truth value changes from '0' to '1' in which case the service becomes and remains activable until event '2' happens. 2. The assertion truth value changes from' l' to '0' in which case the service becomes and remains unactivable until event' 1' happens. 3. The assertion truth value is unchanged, in which case the activability of the service remains unchanged. In the general case, a given assertion may affect not only one but a subset of services. An event 'e' is defined by the change of one or several assertions truth values. It can therefore be characterized by: - S+(e)={ set of the services that become acti vable when event e happens}. - S-(e)={ set of the services that become unactivable when event e happens}. Remark 1: A user sees the set of services that he can activate invariable until an event occurs. Remark 2: An evident coherence criterion is: \f e S+(e)flS-(e)=0.
3.3 Application definition An application A is defined as a set of services, SeA), associated with a set of conditioning events E(A). A =({sd {ej}) Si E SeA), ej E E(A) The relation between events and services may be expressed using assertions constructed from logic variable to which we apply Boolean and temporal operators (Wieczorek, 1994). Our aim is to determine at each time which services are activable. In order to avoid relative or absolute time measurement we use events occurences as time markers. A service is constrained iff events eo and el exist such that: el ~ rf] A(s) <=) when et happens s becomes activable eo ~ -,A(s) (:::::) when eo happens s becomes unactivable. At time T k the state of the system X(Tk) is defined by the sequence of all the events that occurred on the time window [To,TJ where To is a given time origin, e(T j ) is the ilb event, and T i is its occurring time. X (TJ = [e (Tl); e (T2); ... ; e (Tk)]·
3.4 Graph representation It is possible to express the application constraints by representing menus and events in a state graph. Proof : The different menus (J..LJ of an application and the events conditioning the different services can be obtained applying equation (1) from a given initial menu. Let us consider the embedding case in which any event of E(A) can possibly appear at each state of the system. Equation (1) becomes : Ilk+l = [Ilk u S\ek+l)]\ S-(ek+l) (2) with ek+l E E(A) Thus, at a given step the knowledge of Jlk allows to determine all the possible Jlk+l' The system (2) defines therefore a Markov process (Chung, 1967; Cullmann, 1975) which can be represented by the following graph (Gondran, 1979) : G~( 1t; T)
where 1t c peS) the set of all the subsets of S, and
562
T = {(fli; ej; fl0 e P(S)XE(A)XP(S) / flk=[J..LjUS+(ej)]\S-(ej) } The graph G~ represents the most exhaustive case in which all the foreseeable possibilities are anticipated. The system (1) is slightly more difficult to analyze. In fact, the set E k does not depend on the menu flk but merely on the state X(T0 of the system, so that the two following problems have to be considered: 1how to tackle with the events of the set E(A)\Ek 2- how to take into account the fact that the same menu flk could be associated with different states. The first point is easy to solve since it is sufficient to eliminate the non existing transitions from the graph
In a first step, we will formalize the notion of a composed service, then provide a means to construct the set of all the allowable composed requests.
4.1. Supervisory instrument
language
of an
aggregated
The requests that may be formulated by the users are those which concern the individual instruments. Those requests are more or less distant in time. We consider requests sequences as requests for composed services of the aggregated instrument. In order to calculate all those request sequences, we modeIise them as words which are built using two vocabularies. Let SG be the set of the services of the aggregated instrument, and Ri the request for the service si. Let V R be the vocabulary: V R = {Ri, / si e SG}, V R* is the set of the words obtained by the concatenation of elements from YR. Let T be the decimal representation language of the time variable (e.g. 1Os). We define the supervisory language associated with the set SG as any concatenation of words which belong to V R*or T. Using classical notations : Lu(SG) = (V R * + T)* Example: RI 5 R 2 10 R 3 E Lu(SG) Let us notice that Lu(SG) contains all the control sequences which may be issued from the user. It can be seen as the set of user controlled sequences.
Gw The second point may be solved by modifying the transition conditions of G~ which correspond to events belonging to the intersection of different EK sets at different SSOS. The modification procedure is easy to define (Bouras, 1997) and will appear in the example of part 5. The result of the transformation of G~ in order to take into account the actual system (1) is a graph which is called the graph of menus resulting from the application constraints (GMRAC). 4. SUPERVISORY LANGUAGE We are now interested in the supervisory language of the aggregated instrument which represents the distributed application. The requests that can be addressed to the system are vectors whose components represent, at each time, the individual requests which are addressed to each of the elementary instruments. Since the application constraints introduce time considerations, we are interested in determining the set of all the allowable requests sequences. We will consider request vectors such that only one component changes at a time. This means that we do not study the parallel operation of the distributed system (of course such operation exists, and is quite simple to consider in our framework), but we restrict our attention to individual instruments requests sequences. The interest of such a determination may be justified from two viewpoints : - on one hand, the determination of all the allowable requests sequences gives a means to build fault safe systems in the sense that those erroneous requests which would not fit any allowable requests sequence could be on line recognised and rejected, - on the other hand, any sub-sequence of an allowable requests sequence could be implemented as a high level composed request, which allows to build different hierarchical control levels for the distributed system.
4.2. Supervisory language ofthe application At the application level, the pertinent concept is that of sequences of services and events which allow the user to follow a path in the GMRAC (or to remain in one of the GMRAC menus). By the GMRAC definition, such sequences satisfy the application constraints. However, their execution is only possible if the whole path they refer to in the GMRAC can really be performed. From a general point of view, this might be false, since a path could contain events which might never occur (e.g. waiting for a signal from a failed sensor). This is the reason why we will define the supervisory language of the application retaining those composed services which include only events whose occurrence can be ascertained. Let G(X,U) a GMRAC, and eij an event such that (i, eij, j) E U. eij is user dependant iff its associated assertion makes use exclusively of words w e Lu(SG). The controlled sub graph of G(X,U) is G(u)=[X,Uu ] where Uu={T=(i,eij,j)e U /eij is user dependant}. Let us now define Ls(G(u» the vector of the languages whose words represent the paths which allow to leave each node of the graph G(X,U) using only user dependant events.
563
Ls1(G(u»
of them is stopped. The starting sequence is the following: - Conveyor B rotation in a chosen direction : left to 51; right to 52 - 5 seconds later, rotation of conveyor A - 10 seconds later: opening of extractor El and/or E2 The normal stop is obtained through the inverse procedure. - stop of extractors El and/or E2 - 10 seconds later, stop of conveyor A - 5 seconds later, stop of conveyor B.
Ls2 (G(u» Ls(G(u» =
Let now L~(G(u» the language of all the sequences a user may formulate in the menu J..l without leaving it. It is easily defined from e(Jl)={ e/ T(,e,)U }, the set of the events associated with output transitions of the menu Jl in the GMRAC, and LU(Jl) the language of all the sequences the user may formulate in the menu Jl.
ISilO L~(G(u»={
w
E
Lu(J..l) / tie
E
11
~[j!]
e(J..l), w does not depend
on e}
Conveyor A---.~
The vector associated with all the nodes of the graph G(X,U) is :
)_
L~l(G(U» L~(G(u»
4(G(u» =
Figure 1 : Handling installation
The services offered by the different actuators are the following (we only consider the manual operation USOM) : Extractor El DO: open Dl: close D2: open Extractor E2 D3: close Conveyor A 04: rotate D5: stop Conveyor B D6: rotate left D7: stop rotate left D8: rotate right D9: stop rotate right
Ls(G(u» - resp. L~(G(u» - are the vectors of the outcoming (resp. stable) paths of G(X,U) with respect to its nodes. Those paths depend only on user dependant events, so we may decide to create a composed request with any of the sub-paths, since its execution may be planified in advance. It is now easy to show that the language which expresses all the composed services of the application is (Bouras, 1997) : L(application)= Ls(G(U»T.L~(G(u» = ~ 4i LS~i
5. EXAMPLE
5.2 Expression of the operating constraints in a GMRAC
We illustrate by an example how constraints are expressed, and we give the corresponding GMRAC and supervisory language. This example is used in several papers (Bucki et ai, 1991a, b,c, 1994), and has been chosen by its authors to illustrate the automation by decisional analysis. The distributed architecture results from the interconnexion of 4 (possibly intelligent) actuators.
Fig. 2 shows the obtained GMRAC. In this graph, the transitions labelled x/y mean that the sequence y followed by x is true. 5uch sequences result from the transformation of the graph G~ pointed out in §3.5, in order to obtain the Markov property.
5.3 Supervisory language of the application 5.1 Example description
The set of the composed requests the system could be provided with is given in its general form by the following:
A handling installation comprises two silos containing each a different product. Each one is serviced by an extractor (El or E2). As shown in fig. 1, the conveyors A and B can be controlled in one or two directions, in order to fill up the tanks 51 or 52. Conveyors have no stocking possibilities, it is therefore necessary to avoid to pour products if one
[((T D8 T<5s D9)*D8 T~5s D9 T)* D8 T ~5s «D4 T<10s D5 T)*D4 T~lOs (D5 T<5s 04 T)*D5 T~5s )* 04 T>lOs {02 T «D3 T<10s D2 T)* T<10s (DO T D 1 T<10s)* Do T (02 T D3 T)* D2 T (Dl T DO T)* )* [D3 T~lOs +
564
(D3 T105 ]} * (05 T<5s D4) D5 T~5s (04 T5s (04 T5s 07 T)*D6 T~5s «04 T105 ]} * (05 T<5s 04) D5 T~5s (04 T<105 05)* 04 T ~10s)* 05 T~5s (04 T<105 05)* 07]*
corresponds to the existence of events whose occurrences condition the activabilities of the different services. These event occurrences define a chronology that manages the way to propose services to the user, thus at each step the instrument proposes a set of services called menu. Menus and events can be represented in a state graph expressing the constraints repercussion on the operating level. From this graph, it is possible to deduce the application supervisory language, which contains all the high level requests which satisfy the application constraints. A very simple example of a handling process has been provided to illustrate the way such a supervisory language is built. However, the modelling approach applies to any kind of process components for which the notion of service can be defined. An application to process control (namely the analysis of process reconfiguration possibilities) can be found ,in (Staroswiecki and Gehin, 1998).
REFERENCES Bouras, A., M. Bayart, M. Staroswiecki (1995), Specification of Smart Instruments for Intelligent Control, IEEE SMC, Vancouver, Canada. Bouras, A., M. Staroswiecki (1997), How can Intelligent Instruments Interoperate in an Application Framework ? A Mechanism for Taking into Account Operating Constraints, IFAC SICICA'97, Annecy, France. Bouras, A. (1997), Contribution a la conception D5 d' architectures reparties: modeles generiques et interoperabilite d'instruments intelligents, Ph. O. thesis, University Lille 1. Bucki, J., Y. Pesqueux, L. Lasoudis, (l991a), BCOD: La conception orientee objets decisionnels, Groupe HEC, 78351 Jouy-en Josas cedex France. Bucki, J., Y. Pesqueux (1991b), Organe decisionnel et controle-delegation et automatisation, CR 388/1991, Groupe HEC, Les cahiers de recherche, Chambre de Commerce et d'Industrie de Paris. Bucki, J., Y. Pesqueux, (1991c), Systeme d'information, Groupe HEC, 78351, Jouy-en Josas, cedex France. Figure 2 : Constraint graph of the manual operation of the handling Bucki, J. ,Y. Pesqueux, (1994), Modes de marche des installation systemes automatises, Revue Francaise de Gestion Industrielle. 1. C 46-645 Normalisation Franc;aise AFNOR Cassar, J. Ph., M. Bayart, M. Staroswiecki (1992), 6. CONCLUSION Hierarchical Oata Validation in Control Systems Using Smart Actuators and Sensors, IFAC To antICIpate the interoperability of a set of SICICA 92, Malaga, Spain, pp 209-214. intelligent instruments in an application framework Chung, K.L. (1967), Markov Chains with Stationnary requires models which formalize their functions, the Transition Probability, Springer-Verlag, Berlin data they handle, the supervisory language which Heidelberg, New York. gives access to their services. Cocquempot, V. (1993), Surveillance des processus The application finality is expressed in terms of industriels complexes, generation et optimisation sequences to be executed and in terms of constraints to be respected. An application constraint
565
Modeling Approaches, Measurement and control. Vol29 July/August. Seredynski, F. (1991), Task Allocation by a Team of Learning Automata, Proc. of the 6 th Int. Conf. on Methodologies for Intelligent Systems, North Carolina. Sinclair, J. B. (1987), Efficient Computation of Optimal Assignments for Distributed Tasks~ Parallel and Distributed Computing,. 4, pp. 342362. Staroswiecki, M., M. Bayart (1996) Les actionneurs intelli gents. Hermes, Paris. Staroswiecki, M., M. Bayart (1996), Models and Languages for the Interoperability of Smart Instruments, Automatica, 32, No. 6, pp 859-873,. Staroswiecki, M., A. L. Gehin (1998), Analysis of System Reconfigurability Using Generic Component Models, UKACC Int. Conf. Control '98, Swansea, UK. Tricquet, S., A. L. Gehin, N. Devesa, M. Bayart, B. Toursel (1997), Fieldbus Considered as a Smart Instrument : Modelization Using a Generic External Model, IFAC SICICA'97, Annecy, France. Westbrock, J. (1992), Device Description Language Specification-Document COM-20, Revision B. Wieczoreck, M. J. (1994), Locative Temporal Logic and Distributed Real Time Systems, PhD, Proefschrift wiskunde en informatica nijmegen.
des relations de redondance analytique, Ph. D. thesis, University Lille I. Cullmann, G. (1975), Initiation aux chaines de Markov, Masson, Paris EN50170, (1996), Interoperability WordFip, WordFip field Bus, 2 rue Bone, 92160 Antony, France (web : wordfip.org). Gehin, A. L. (1994), Analyse fonctionnelle et modele generique des capteurs intelligents - application a la surveillance de I' anesthesie. Ph. D. Thesis, University Lille I. Gondran, M., M. Minoux, (1979), Graphes et algorithmes, Eyrolles, Paris. ISAlSP50 (1993), User Layer Technical Report for the Fieldbus Standard. Joseph, M. (1996), Real Time Systems: Specification,Verification and Analysis, Prentice Hall International. Klaseen, E. L., J. J. Sydir (1995), The Definition of Interoperability Architectures for Intelligent Devices Using Abstract Models, IEEE WFCS'95, Leysin, Switzerland, pp. 237-245. Neumann, P., C. Diedrich, R. Simon (1995), Necessary Extensions of Fieldbus System for Distributed Processing, IEEE WFCS'95, Leysin, Switzerland, pp. 247- 254. PRIAM (1995), (Prenormative Requirements for Intelligent Actuation and Measurement (19921995). Project Information, ESPRIT Project 6188. Riviere, J. P., M. Bayart, 1. M. Thiriet, A. Bouras, M. Robert (1996), Intelligent Instruments. Some
566
Appendix 1 Generic Model of an Intelligent Instrument:= :={ } :={ } :={ } :={ } :=
BUILDING DISTRIBUTED ARCHITECTURES BY THE INTERCONNECTION OF INTELLIGENT INSTRUMENTS A. Bouras1,2 ,M. Staroswiecki1
1 LAIL URA CNRS 1440 Bat P2, UFR d'IEEA, Univ des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq cedex-France, e-mail: [email protected] 2 Ecole des Mines de Douai, 941 Rue Charles Bourseul 59508 Douai cedex France
Abstract: In this paper we present a generic intelligent instrument descriptive model and an aggregation mechanism which allows to model composite instruments resulting from the interconnection of simple ones. The interoperability is defined as the possibility for the set of interconnected instruments to meet the application constraints. The supervisory language of the overall distributed control structure is calculated. Copyright © 1998 IFAC Keywords: Intelligent instruments, Interoperability, Distributed Architectures.
1. INTRODUCTION
Automated system design based on intelligent instruments is a very difficult task, since it rests on the integration of instruments functionalities which may largely differ from one supplier to another one, and which may meet more or less precisely the overall system needs. The possibility of meeting the specifications of a given application by building up a distributed architecture through the interconnection of a set of intelligent instruments will be refered to as the interoperability property of these instruments. In this framework, interconnection means that a given set of instruments are able to exchange data and control information, through a communication system which might for example be a local area network. The possibility to communicate data and messages using a given LAN protocol is refered to as the intercommunication property. One immediately sees that intercommunication constitutes a necessary condition, not always easy to fulfill, but in very few cases is this condition a sufficient one.
The intelligent instrument concept appeared when sensors and actuators began to integrate their own processing power, at drastically decreasing costs. The impact of the technical revolution in the area of sensors and actuators can be analyzed according to three viewpoints. -As tools dedicated to a precise function, their performances depend on their processing power. -As industrial products, their life cycle contains several phases. In configuration, implementation, exploitation, test and maintenance phases, intelligent sensors or actuators can propose different services to different users. -As components of automated systems, whose increasing complexity justifies the trend from centralized architectures towards distributed ones, intelligent sensors and actuators are the most appropriate equipments to receive part of the data and processing flows, so as to perform locally a part of the global application.
Assessing the interoperability property supposes a precise knowledge of the functionalities which are
559
offered by each equipment, hence it is necessary that should be stabilized a certain number of concepts allowing the description of intelligent instruments and the manipulation of their models. The three-fold analysis of an intelligent instrument leads to three possible approaches for its modeling. • The first viewpoint leads to a descriptive analysis in terms of the services the instrument is able to provide its users (Staroswiecki and Bayart, 1996; Bouras et al, 1995). • The second viewpoint leads to an analysis in terms of User Operating Modes (USOM) so as to specify the instrument different exploitation types (Staroswiecki and Bayart, 1996). • The third viewpoint leads to an analysis in terms of constraints to be fulfilled in order to guarantee the interoperability of an equipment set in the framework of a given application (Bouras and Staroswiecki, 1997). The first two viewpoints describe the instrument as it is provided by its supplier. The third one describes the application the instrument will contribute to. Using a generic external description model presented in Staroswiecki and Bayart (1996) and the interoperabilty check fITst introduced in Bouras and Staroswiecki (1997), this paper presents a contribution to the formalization of the design of the overall distributed application, and to the determination of its supervisory language. We do not intend to model the intercommunication requirements or to study the impact of fieldbuses on systems architectures (Klaseen and Sydir, 1995; Neumann et aI, 1995), nor to optimize the distribution of application functions on the local processing stations (Sinclair, 1987) or to validate some critical time constraints (Joseph, 1996). Merely, we intend to show how it is possible to systematically build up high level services (those the user sees at the application level) from low level ones (those the individual instruments are able to provide), and how the services should be organized in order to fulfill some application requirements. The first part of the paper will discuss the interoperability issues, and present the generic external model we propose for the description and manipulation of intelligent instruments. In the second part, we show that the application constraints lead to organize the services into a menu graph. The third part describes the determination of the set of the allowable requests sequences which constitute the supervisory language of the overall application. An illustrative example is provided in the last part.
the field level. Easy interconnections should characterize distributed automated systems based on intelligent instruments. However many efforts have been devoted to the communication function, in the view of field bus standardization, it is only very recently that those efforts led to the EN50170 norm at the European level (EN50170, 1996). The design of a distributed application using field instruments issued from different constructors is not only based on the use of a common communication standard. Given the infinite number of performable functions and possible implementations of intelligent instruments, some design rules are imperative in order to propose 'open' concepts allowing a compatibility between the field devices offered by different constructors. This is the main reason why, in addition to the communication protocol layers (in most field buses layers 1, 2 and 7 of the OSI model), different working groups have focused on description standards for the so-called «application layer» (mainly through the use of function blocks (ISA/SP50, 1993; PRIAM, 1995; Westbrock, 1992». The generic functional internal model of an intelligent instrument (Riviere et aI, 1996; Gehin, 1994) is intended to provide such an open description, in order to validate the interoperability property.
2.2 Interoperability We define the interoperability of a set of instruments as the possibility to build an application using this set of instruments, at a given cost. In fact it is always possible to make different instruments work together, writing specific drivers, and adaptation software in a coordination layer. However, the cost of this layer could sometimes be so high that one better chooses other field level components. Interoperable instruments should induce minimal (or at least affordable) extra costs for the coordination layer. This coordination layer has to insure: • That data and requests addressed from one instrument to another one are interpreted and executed by the receiver exactly as the sender expects. • That the application constraints are satisfied during the system operation. To anticipate the interoperability of a set of components it is therefore required first to precisely model each component 'intelligence', second to express the application constraints, in order to check if they can be derived in terms of instrument behaviors, third to express the set of the requests which may be addressed to the interconnected instruments and which satisfy the constraints.
2. INTEROPERABILITY
2.1 Intercommunication Automated systems can be build using several hardware architectures that allow a communication at
560
2.3 A Generic External Model of Intelligent Instruments
requests sequences) is easy to derive, as we will see later.
To integrate the interoperability considerations in the intelligent instrumentation concept it is necessary to describe the intelligent instrument as it is seen through the communication network, this means form an external viewpoint, i.e. without any description of how internal processing are realized (Staroswiecki and Bayart, 1996). For an external entity the intelligent instrument may be described as a process proposing services which manipulate variables and make use of resources. A service is processed on the reception of a specific request. The set of all the requests an intelligent instrument «understands» constitutes its supervisory language. According to the resources availability, the services may run in nominal or degraded versions. The resources availability is determined by the instrument Fault Detection and Isolation (FDI) ability (Cassar et aI, 1992; Cocquempot, 1993). When no version of a service can be run, the service becomes unavailable. To avoid users incompatible requests, the set of services of an intelligent instrument is organized into coherent subsets called User Operating Modes (USOM). A USOM is a subset of services that the user may require in a given situation in the life cycle of the intelligent instrument. At each time, the instrument is in a given current USOM: the only services whose execution is allowed are those belonging to this mode, requests for any other service are automatically rejected. The definition of the set of USOM, and for each of them, the list of services and changing mode conditions, specify the instrument USOM management system and may be represented using a state graph. The transitions represent the changing mode conditions which may include some conditions about the availability of particular services. Appendix 1 gives a description of the generic external model of an intelligent instrument in the Backus Naur norm protocol language (C46-645).
3. APPLICATION CONSTRAINTS We characterize the architecture of a distributed system fifst by its components, second by their interconnection system. Each of the instruments, as well as the communication network (Tricquet et al, 1997), can be described by the generic external model given in the first part. From a global point of view, the application we want to build has to provide some services, while satisfying some constraints (e.g. specific on/off-procedure, ordered sequences of actions,...). Thus, the interoperability of the instruments we want to use in the frame of the application we want to build rests on the possibility to obtain the set of the services of the application from the set of the services of the aggregated instrument which represents the system architecture. Interoperability cannot be achieved when the former cannot be obtained using the latter. When the instruments are interoperable, the simplest situation is the one in which the application does not forbid any of the possible services (or sequence of services) provided by the overall aggregated instrument. In this case, the instruments are interoperable at the cost of an overall control level which only has to provide at each time the proper (coherent) combination of the individual USOMs. However, the general case introduces constraints which forbid some services (or sequences of services) so that the interoperability cost is increased by the cost of the elaboration of some software which guarantees the constraints satisfaction.
3.1 What is a constraint? The absence of constraint is seen by the user as the possibility to execute at any time any service of his choice on any instrument. The supervisory language of the application is in that case the supervisory language of the composed instrument which aggregates all the low level ones. However the user's choice is seldom open. For example, a start procedure might introduce an order relation on a subset of services. Although all necessary resources for the execution of a service are available, some conditions might have to be true before the service becomes activable by the user. These conditions are called constraints. A service is activable at a given time, if its execution can be requested at this time. The activability of a service s is a binary variable A(s,t) such that A(s,t) =1 iff the service (s) is activable at time t. We postulate that a constraint on a service is formulated by a condition which has to be true in order for the service to be activable. This means that
2.4 Aggregated (high level) instruments High level (virtual) instruments may be considered, which interconnect low level ones. As an example, a heater (high level instrument) is defined by the interconnection of a burner, a fuel pump, an ignitor and a ventilator (simple or low level instruments). The aggregation of simple instruments into higher level ones is obtained through simple model manipulations : the set of the services of a composed instrument is the union of the sets of the services of the elementary ones, while its USOM graph is the asynchroneous product of the low level USOM graphs (Bouras, 1997). The supervisory language of an aggregated instrument (the set of all the possible
561
there exists an assertion whose evaluation determines whether the service is activable or not. The set of such assertions expresses the global constraints repercussion on the operating level.
We suppose that the time granularity is small enough so that two events don't happen at the same time. A steady state operation step (SSOS) is a time interval [Tk;Tk+ 1[ during which the state of the system does not change. \f t E [Tk;Tk+ 1[ X(t) = X(Tk) Let us consider the set of the possible SSOS of a given application. The application is coherently designed if, for each service, there exists at least one SSOS during which the service is activable. "Is E SeA) 3 Tk ,Tk+ 1 and X[Tk] such that "I t E [Tk, Tk+l[ A(s,t) = 1 The menu Il[X(T0] (or Ilk if no confusion is possible) associated with an SSOS is the subset of all the services which are activable during this SSOS. Remarks: 1- A menu might be empty; in this case the system is said to be non controllable by the user during the corresponding SSOS. 2- The same menu can be associated to different SSOS. Let E[X(T0] (or E k if no confusion is possible) the subset of events of E(A) that can happen when the system is in the state X(T0. The knowledge of (Il[X(T 0] ; E[X(T0]) allows to determine all the possible J,l[X(Tk+l)] Proof: S+[e(Tk+l)] and S-[e(Tk+1)] are known for each possible e(Tk+1). The menus J,l[X(Tk+1)] are deduced from J,l[X(TJ] by the following operation: Ilk+l = [Ilk U S+(ek+l)] \ S-(ek+l) (1) with ek+l E E k ~ E(A) The triple [Il(X(Tk)]; e(Tk+1); J,l[X(Tk+1)]] is unique. The couple (Il[X(TJ]; e(Tk+1» defines Il[X(Tk+1)] in a unique way.
3.2 Expression and effect ofa constraint To express a constraint returns to express the assertion that describes it. At each evaluation time, three possible situations have to be considered : 1. The assertion truth value changes from '0' to '1' in which case the service becomes and remains activable until event '2' happens. 2. The assertion truth value changes from' l' to '0' in which case the service becomes and remains unactivable until event' 1' happens. 3. The assertion truth value is unchanged, in which case the activability of the service remains unchanged. In the general case, a given assertion may affect not only one but a subset of services. An event 'e' is defined by the change of one or several assertions truth values. It can therefore be characterized by: - S+(e)={ set of the services that become acti vable when event e happens}. - S-(e)={ set of the services that become unactivable when event e happens}. Remark 1: A user sees the set of services that he can activate invariable until an event occurs. Remark 2: An evident coherence criterion is: \f e S+(e)flS-(e)=0.
3.3 Application definition An application A is defined as a set of services, SeA), associated with a set of conditioning events E(A). A =({sd {ej}) Si E SeA), ej E E(A) The relation between events and services may be expressed using assertions constructed from logic variable to which we apply Boolean and temporal operators (Wieczorek, 1994). Our aim is to determine at each time which services are activable. In order to avoid relative or absolute time measurement we use events occurences as time markers. A service is constrained iff events eo and el exist such that: el ~ rf] A(s) <=) when et happens s becomes activable eo ~ -,A(s) (:::::) when eo happens s becomes unactivable. At time T k the state of the system X(Tk) is defined by the sequence of all the events that occurred on the time window [To,TJ where To is a given time origin, e(T j ) is the ilb event, and T i is its occurring time. X (TJ = [e (Tl); e (T2); ... ; e (Tk)]·
3.4 Graph representation It is possible to express the application constraints by representing menus and events in a state graph. Proof : The different menus (J..LJ of an application and the events conditioning the different services can be obtained applying equation (1) from a given initial menu. Let us consider the embedding case in which any event of E(A) can possibly appear at each state of the system. Equation (1) becomes : Ilk+l = [Ilk u S\ek+l)]\ S-(ek+l) (2) with ek+l E E(A) Thus, at a given step the knowledge of Jlk allows to determine all the possible Jlk+l' The system (2) defines therefore a Markov process (Chung, 1967; Cullmann, 1975) which can be represented by the following graph (Gondran, 1979) : G~( 1t; T)
where 1t c peS) the set of all the subsets of S, and
562
T = {(fli; ej; fl0 e P(S)XE(A)XP(S) / flk=[J..LjUS+(ej)]\S-(ej) } The graph G~ represents the most exhaustive case in which all the foreseeable possibilities are anticipated. The system (1) is slightly more difficult to analyze. In fact, the set E k does not depend on the menu flk but merely on the state X(T0 of the system, so that the two following problems have to be considered: 1how to tackle with the events of the set E(A)\Ek 2- how to take into account the fact that the same menu flk could be associated with different states. The first point is easy to solve since it is sufficient to eliminate the non existing transitions from the graph
In a first step, we will formalize the notion of a composed service, then provide a means to construct the set of all the allowable composed requests.
4.1. Supervisory instrument
language
of an
aggregated
The requests that may be formulated by the users are those which concern the individual instruments. Those requests are more or less distant in time. We consider requests sequences as requests for composed services of the aggregated instrument. In order to calculate all those request sequences, we modeIise them as words which are built using two vocabularies. Let SG be the set of the services of the aggregated instrument, and Ri the request for the service si. Let V R be the vocabulary: V R = {Ri, / si e SG}, V R* is the set of the words obtained by the concatenation of elements from YR. Let T be the decimal representation language of the time variable (e.g. 1Os). We define the supervisory language associated with the set SG as any concatenation of words which belong to V R*or T. Using classical notations : Lu(SG) = (V R * + T)* Example: RI 5 R 2 10 R 3 E Lu(SG) Let us notice that Lu(SG) contains all the control sequences which may be issued from the user. It can be seen as the set of user controlled sequences.
Gw The second point may be solved by modifying the transition conditions of G~ which correspond to events belonging to the intersection of different EK sets at different SSOS. The modification procedure is easy to define (Bouras, 1997) and will appear in the example of part 5. The result of the transformation of G~ in order to take into account the actual system (1) is a graph which is called the graph of menus resulting from the application constraints (GMRAC). 4. SUPERVISORY LANGUAGE We are now interested in the supervisory language of the aggregated instrument which represents the distributed application. The requests that can be addressed to the system are vectors whose components represent, at each time, the individual requests which are addressed to each of the elementary instruments. Since the application constraints introduce time considerations, we are interested in determining the set of all the allowable requests sequences. We will consider request vectors such that only one component changes at a time. This means that we do not study the parallel operation of the distributed system (of course such operation exists, and is quite simple to consider in our framework), but we restrict our attention to individual instruments requests sequences. The interest of such a determination may be justified from two viewpoints : - on one hand, the determination of all the allowable requests sequences gives a means to build fault safe systems in the sense that those erroneous requests which would not fit any allowable requests sequence could be on line recognised and rejected, - on the other hand, any sub-sequence of an allowable requests sequence could be implemented as a high level composed request, which allows to build different hierarchical control levels for the distributed system.
4.2. Supervisory language ofthe application At the application level, the pertinent concept is that of sequences of services and events which allow the user to follow a path in the GMRAC (or to remain in one of the GMRAC menus). By the GMRAC definition, such sequences satisfy the application constraints. However, their execution is only possible if the whole path they refer to in the GMRAC can really be performed. From a general point of view, this might be false, since a path could contain events which might never occur (e.g. waiting for a signal from a failed sensor). This is the reason why we will define the supervisory language of the application retaining those composed services which include only events whose occurrence can be ascertained. Let G(X,U) a GMRAC, and eij an event such that (i, eij, j) E U. eij is user dependant iff its associated assertion makes use exclusively of words w e Lu(SG). The controlled sub graph of G(X,U) is G(u)=[X,Uu ] where Uu={T=(i,eij,j)e U /eij is user dependant}. Let us now define Ls(G(u» the vector of the languages whose words represent the paths which allow to leave each node of the graph G(X,U) using only user dependant events.
563
Ls1(G(u»
of them is stopped. The starting sequence is the following: - Conveyor B rotation in a chosen direction : left to 51; right to 52 - 5 seconds later, rotation of conveyor A - 10 seconds later: opening of extractor El and/or E2 The normal stop is obtained through the inverse procedure. - stop of extractors El and/or E2 - 10 seconds later, stop of conveyor A - 5 seconds later, stop of conveyor B.
Ls2 (G(u» Ls(G(u» =
Let now L~(G(u» the language of all the sequences a user may formulate in the menu J..l without leaving it. It is easily defined from e(Jl)={ e/ T(,e,)U }, the set of the events associated with output transitions of the menu Jl in the GMRAC, and LU(Jl) the language of all the sequences the user may formulate in the menu Jl.
ISilO L~(G(u»={
w
E
Lu(J..l) / tie
E
11
~[j!]
e(J..l), w does not depend
on e}
Conveyor A---.~
The vector associated with all the nodes of the graph G(X,U) is :
)_
L~l(G(U» L~(G(u»
4(G(u» =
Figure 1 : Handling installation
The services offered by the different actuators are the following (we only consider the manual operation USOM) : Extractor El DO: open Dl: close D2: open Extractor E2 D3: close Conveyor A 04: rotate D5: stop Conveyor B D6: rotate left D7: stop rotate left D8: rotate right D9: stop rotate right
Ls(G(u» - resp. L~(G(u» - are the vectors of the outcoming (resp. stable) paths of G(X,U) with respect to its nodes. Those paths depend only on user dependant events, so we may decide to create a composed request with any of the sub-paths, since its execution may be planified in advance. It is now easy to show that the language which expresses all the composed services of the application is (Bouras, 1997) : L(application)= Ls(G(U»T.L~(G(u» = ~ 4i LS~i
5. EXAMPLE
5.2 Expression of the operating constraints in a GMRAC
We illustrate by an example how constraints are expressed, and we give the corresponding GMRAC and supervisory language. This example is used in several papers (Bucki et ai, 1991a, b,c, 1994), and has been chosen by its authors to illustrate the automation by decisional analysis. The distributed architecture results from the interconnexion of 4 (possibly intelligent) actuators.
Fig. 2 shows the obtained GMRAC. In this graph, the transitions labelled x/y mean that the sequence y followed by x is true. 5uch sequences result from the transformation of the graph G~ pointed out in §3.5, in order to obtain the Markov property.
5.3 Supervisory language of the application 5.1 Example description
The set of the composed requests the system could be provided with is given in its general form by the following:
A handling installation comprises two silos containing each a different product. Each one is serviced by an extractor (El or E2). As shown in fig. 1, the conveyors A and B can be controlled in one or two directions, in order to fill up the tanks 51 or 52. Conveyors have no stocking possibilities, it is therefore necessary to avoid to pour products if one
[((T D8 T<5s D9)*D8 T~5s D9 T)* D8 T ~5s «D4 T<10s D5 T)*D4 T~lOs (D5 T<5s 04 T)*D5 T~5s )* 04 T>lOs {02 T «D3 T<10s D2 T)* T<10s (DO T D 1 T<10s)* Do T (02 T D3 T)* D2 T (Dl T DO T)* )* [D3 T~lOs +
564
(D3 T
corresponds to the existence of events whose occurrences condition the activabilities of the different services. These event occurrences define a chronology that manages the way to propose services to the user, thus at each step the instrument proposes a set of services called menu. Menus and events can be represented in a state graph expressing the constraints repercussion on the operating level. From this graph, it is possible to deduce the application supervisory language, which contains all the high level requests which satisfy the application constraints. A very simple example of a handling process has been provided to illustrate the way such a supervisory language is built. However, the modelling approach applies to any kind of process components for which the notion of service can be defined. An application to process control (namely the analysis of process reconfiguration possibilities) can be found ,in (Staroswiecki and Gehin, 1998).
REFERENCES Bouras, A., M. Bayart, M. Staroswiecki (1995), Specification of Smart Instruments for Intelligent Control, IEEE SMC, Vancouver, Canada. Bouras, A., M. Staroswiecki (1997), How can Intelligent Instruments Interoperate in an Application Framework ? A Mechanism for Taking into Account Operating Constraints, IFAC SICICA'97, Annecy, France. Bouras, A. (1997), Contribution a la conception D5 d' architectures reparties: modeles generiques et interoperabilite d'instruments intelligents, Ph. O. thesis, University Lille 1. Bucki, J., Y. Pesqueux, L. Lasoudis, (l991a), BCOD: La conception orientee objets decisionnels, Groupe HEC, 78351 Jouy-en Josas cedex France. Bucki, J., Y. Pesqueux (1991b), Organe decisionnel et controle-delegation et automatisation, CR 388/1991, Groupe HEC, Les cahiers de recherche, Chambre de Commerce et d'Industrie de Paris. Bucki, J., Y. Pesqueux, (1991c), Systeme d'information, Groupe HEC, 78351, Jouy-en Josas, cedex France. Figure 2 : Constraint graph of the manual operation of the handling Bucki, J. ,Y. Pesqueux, (1994), Modes de marche des installation systemes automatises, Revue Francaise de Gestion Industrielle. 1. C 46-645 Normalisation Franc;aise AFNOR Cassar, J. Ph., M. Bayart, M. Staroswiecki (1992), 6. CONCLUSION Hierarchical Oata Validation in Control Systems Using Smart Actuators and Sensors, IFAC To antICIpate the interoperability of a set of SICICA 92, Malaga, Spain, pp 209-214. intelligent instruments in an application framework Chung, K.L. (1967), Markov Chains with Stationnary requires models which formalize their functions, the Transition Probability, Springer-Verlag, Berlin data they handle, the supervisory language which Heidelberg, New York. gives access to their services. Cocquempot, V. (1993), Surveillance des processus The application finality is expressed in terms of industriels complexes, generation et optimisation sequences to be executed and in terms of constraints to be respected. An application constraint
565
Modeling Approaches, Measurement and control. Vol29 July/August. Seredynski, F. (1991), Task Allocation by a Team of Learning Automata, Proc. of the 6 th Int. Conf. on Methodologies for Intelligent Systems, North Carolina. Sinclair, J. B. (1987), Efficient Computation of Optimal Assignments for Distributed Tasks~ Parallel and Distributed Computing,. 4, pp. 342362. Staroswiecki, M., M. Bayart (1996) Les actionneurs intelli gents. Hermes, Paris. Staroswiecki, M., M. Bayart (1996), Models and Languages for the Interoperability of Smart Instruments, Automatica, 32, No. 6, pp 859-873,. Staroswiecki, M., A. L. Gehin (1998), Analysis of System Reconfigurability Using Generic Component Models, UKACC Int. Conf. Control '98, Swansea, UK. Tricquet, S., A. L. Gehin, N. Devesa, M. Bayart, B. Toursel (1997), Fieldbus Considered as a Smart Instrument : Modelization Using a Generic External Model, IFAC SICICA'97, Annecy, France. Westbrock, J. (1992), Device Description Language Specification-Document COM-20, Revision B. Wieczoreck, M. J. (1994), Locative Temporal Logic and Distributed Real Time Systems, PhD, Proefschrift wiskunde en informatica nijmegen.
des relations de redondance analytique, Ph. D. thesis, University Lille I. Cullmann, G. (1975), Initiation aux chaines de Markov, Masson, Paris EN50170, (1996), Interoperability WordFip, WordFip field Bus, 2 rue Bone, 92160 Antony, France (web : wordfip.org). Gehin, A. L. (1994), Analyse fonctionnelle et modele generique des capteurs intelligents - application a la surveillance de I' anesthesie. Ph. D. Thesis, University Lille I. Gondran, M., M. Minoux, (1979), Graphes et algorithmes, Eyrolles, Paris. ISAlSP50 (1993), User Layer Technical Report for the Fieldbus Standard. Joseph, M. (1996), Real Time Systems: Specification,Verification and Analysis, Prentice Hall International. Klaseen, E. L., J. J. Sydir (1995), The Definition of Interoperability Architectures for Intelligent Devices Using Abstract Models, IEEE WFCS'95, Leysin, Switzerland, pp. 237-245. Neumann, P., C. Diedrich, R. Simon (1995), Necessary Extensions of Fieldbus System for Distributed Processing, IEEE WFCS'95, Leysin, Switzerland, pp. 247- 254. PRIAM (1995), (Prenormative Requirements for Intelligent Actuation and Measurement (19921995). Project Information, ESPRIT Project 6188. Riviere, J. P., M. Bayart, 1. M. Thiriet, A. Bouras, M. Robert (1996), Intelligent Instruments. Some
566
Appendix 1 Generic Model of an Intelligent Instrument
- :={
- :={
- :={
- :={
- :={
567