- Email: [email protected]
Mode Management in a Distributed Intelligent Automated Production System
Copyright © IFAC Algorithms and Architectures for Real-Time Control, Ostend, Belgium, 1995
MODE MANAGEMENT IN A DISTRIBUTED INTELLIGENT AUTOMATED PRODUCTION SYSTEM M. BAYART, M. STAROSWIECKI, A.L. GEHIN L.A.I.L URA CNRS 1440 Bat P2, UFR IEEA Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq Cedex - FRANCE Tel: (33) 20434565 - Fax: (33) 203371 89 e-mail : [email protected]
Abstract: The paper presents the smart instrument generic description organized around User Operating Mode management. In order to build smart instruments based distributed architectures which include several components, we propose an ascendant method to build the User Operating Mode of a set of devices. An example, including a smart sensor and a smart actuator, illustrates our approach. Keywords: Intelligent control, Distributed control, Methodology, Smart sensors and actuators,
1. INTRODUCTION
necessary for all the operators who will intervene during the system life. Restricting our attention to the exploitation phase in which the real time considerations are crucial, the set of the corresponding services will be called Real Time Process Operating System (RTPOS) (Bayart and Staroswiecki, 1993).
The decreasing cost of microcontrollers and the development of field buses give rise to a new generation of field instruments : the smart sensors and actuators. These new components modify the structure of classical automation systems which become Distributed Intelligent Automated Production Systems (DIAPS) which are built using a hardware architecture allowing the communication at the field level of sensors, actuators and data processing stations. The Fig.l illustrates such an architecture.
Data processing station
The emergence of such systems is also due to the development of integrated automation concepts which consider the production system from a highest hierarchical point of view and take into account not only the control and regulation functions but also those which characterize the exploitation of the production system as well as the installation and dismanteling services. In that sense, all the functions of the life cycle of the production system are considered (supervision, maintenance, management, ... ). It's what we name the Process Operating System (POS) which is defined as the set of services which are
Smart Sensor
Fieldbus manager
Smart actuator
Fig. 1 : Illustration of the DIAPS concept The RTPOS Services are provided by a number of hardware or software processing. Particularly, 317
in sofar as it has to manage the activities of the instruments or of the subsystem, and on the other hand to provide the Actual Operating Mode of the instrument (or of the sub-systems) according to its state (or its components state).
sensors and actuators are field instruments whose local data processing capacities allow them to perform some functions of the RTPOS. The functional structure is given on Figure 2. We show in (Staroswiecki and Bayart, 1994) that sensors and actuators can be described by the same overall structure since they perform a part of its functions.
In a first part of this paper, we will define the concept of Actual Operating Mode which is the main characteristics of our generic models of intelligent instruments and rests on Operating Modes and services. In a second part, we will formulate the problem of User Operating Mode Management in a complex structure which links several intelligent instruments. Then, the last part of the paper will propose an ascendant method to build these User Operating Modes. An example illustrates our approach. 2. GENERIC MODELS OF INTELLIGENT INSTRUMENTS The generic models of intelligent instruments is composed of two parts : - the functional model which describes the intelligent device from the point of view of the functions that it puts at work in order to contribute to the RTPOS distribution. - the external ones which describes the device from the point of view of the services it is able to provide to an external entity (operator, other field instrument, computer .. ). In this paper, we are only adress to the external model.
Fig. 2 : Functional structure of a Real Time Process Operating System Thus an intelligent instrument will incorporate, besides the numeric communication possibility (TO COMMUNICATE), the following functions: - to MANAGE, in order to obtain different services in different phases of the life cycle: installation, configuration, parametrization, exploitation, maintenance ... - to VALIDA TE, which distributes at the local level some procedures of the global FDI system (Staroswiecki and aI., 1992). - to ELABORATE and to MANAGE the DATA BASE perform in the same way, at the local level, a part of these overall functions (virtual sensor, state estimation, maintenance history ... ). - in the case of a sensor, the function to INPUT is always present (Gehin, 1994; Robert and al., 1993) and in the case of an actuator, we find at least the function to ACT, completed with the functions to INPUT and to DECIDE in the case of closed loop actuator (Staroswiecki and Bayart, 1994; Iserman and Raab, 1992; Bayart and Staroswiecki, 1992)
In fact, the hardware architecture of an intelligent instrument includes: - communication links with the operators and with the automation system - processing unit(s) which allow the distribution of the RTPOS functions - memories which allow the distribution of the RTPOS data base A general representation of a smart instrument in control applications is given by Fig. 3. Darn
~----~---------r-----'Darn
Processing Output unit and interface local memory interface Signals
The advantage of such a decomposition is that it's possible to construct RTPOS architectures by means of the interconnexion of smart instruments and processing stations (PLCs, regulators, computers ... ). Each smart instrument or local station perform a part of the overall RTPOS functions. However, if some functions such as to ACT and to INPUT are necessary at the lowest level, others have to be implemented in a distributed way. In particular, in this paper, we focuse on the module "TO MANAGE" which is one of the main functions
Fig. 3 : Smart instrument in a control application The interfaces are the means by which the smart instrument interacts with its environment. They include interfaces with the operators, the automation system, the physical process.
318
run in a nominal way if the set of the ressources it needs are able to perform normally. Unfortunately, this is not always the case, and it may happen that some of the required ressources are faulty. Two situations are then possible: - the intelligent instrument designer has implemented no replacement procedure. In that case, the service becomes unavailable. - the designer has implemented at least one replacement procedure. In the case when the ressources this procedure needs are effectively operational, it can be run to replace the nominal one at each request which concerns this latter. In that sense, when faults occur on the ressources, it's not necessary to interrupt the service if a "degraded" version can be executed, which increases the robustness and thus the disponibility of the intelligent instruments.
2.1. Notion of services
A service is defined as a procedure whose execution results in the modification of at least one data of the local data base, or/and at least one signal on the output interface. It is executed on the reception of its specific request by the intelligent instrument, according to its local scheduling policy and its execution cannot be split, nor can it be partly requested. The description of a service consists first in the description of the result which is produced by its execution, they are the outputs. In order to define these obtained values, one will have to describe the computations which are done (algorithmic or sequencial procedures, qualitative or fuzzy inferences, .. ), the variables on which they are done (inputs variables) and the required ressources. Moreover, before its execution, a service must verify some activation conditions. So, a service is first described by :
Let D(sj) be the set of all the values that d(sj) can take. According to the availability of the res sources, at each value d(sj) is associated either the version of the service that it has to execute or nothing if the service becomes unavailable.
< Service> ::= < Inputs, Outputs, Procedure, Activation Condition, Ressources >
2.3. Services organization
Let 8 be the set of services the smart instrument is able to perform : 8 = {SI, s2, ... , sn}
The set of the available services characterizes, from an external point of view, an intelligent device. However, to avoid that the device performs incompatible services (initialization and production services for example), the set of the services has to be organized into coherent subsets, which we call User Operating Modes (USOM).
2.2. Nominal or degraded service
The set of services needs a set of hardware ressources which may belong to the intelligent device (sensors, memory, ... ) or be external (electrical or pneumatic supplying, ... ). The Fault Detection and Isolation (FDI) algorithms which are implemented in the smart instrument allows to know the state of a part of the ressources : those which can be supervised. (Bayart and al., 1992; Cassar and al., 1992; Bayart and ai., 1990).
Let M be the set of the User Operating Modes: M = {mj,j E J} Let Ls be the application which associates to a USOM, the set of the services which are offered to the operators in this mode. Let P(8) be the set of parts of 8. Ls is defined by : Ls : M ~ p (8)
For these ressources, we define an availability index which provide an image of their state. Let dri be the availability index of the ressource i, dTj can be a binary value (ressource is present or not), or can belong to the interval [0,1], it's the case for exemple, for a tool whose availibility index informs about its state (new, partially used, broken).
mj ~ Ls(mj) = 8 j,
with the following properties:
'v'jEJ,8j*0 Each USOM IDj contains at least one service.
'v' Si E 8, :3 j E J / Si E 8 j Each service belongs at least to one USOM.
From the dri of the set of ressources obtained from the FDI algorithms, we can build a word d(sj) which represents the service availibity index of the service j :
I
d(sj) = drj1
U 8j =8 , jeJ
The set M of the USOMs constitutes a covering of the set 8 of the services (Fig. 4).
I· .. I drji I· .. I ...
where rji are the ressources which are used by the service j. At a given instant, the service will 319
Set of the services User operating Mode 2
User operating Mode 1
Fig. 4 : Services and USOMs Fig. 5 : The USOMs deterministic automata
At each time, the intelligent device is in a current USOM : the only services it will accept to execute are those which belong to that USOM, in other words, any request for another service will be automatically rejected. Such an organization plays the role of a request filter and increases the operational safety of the intelligent device.
2.4. Actual Operating Modes An Actual Operating Mode (AOM) is a combination of the current USOM which results of a voluntary action in the intelligent instrument users, and the endured device state, which depends on the non faulty ressources at the current time. This combination defines in a unique way the list of the available services, as well as, for each of them, the version under which it is available, at each instant of time. In that sense, the AOM is described by the list of services which are allowed in the current USOM, with they availability index.
To insure coherence of the services, a USOM corresponds to a set of services that operators can require in a given situation of the life cycle. They are arranged taking account safety conditions, precedence constraints, activation conditions, ... off operation, configuration, manual or automatic mode, ... are example of USOM. Obviously, the list of the services of each USOM has to contain a "Set USOM" request, otherwise it would be impossible to leave the current USOM. The definition of the set of the USOMs and of the transition conditions completely specifies the intelligent instrument USOMs management system. Let S cm be the set of services required to move from one mode to another. The USOM organization can be described by a deterministic automata (Molinaro, 1992) G ={M, T, Scm } where: - M is the set of USOM - S cm is the of the "set USOM" services - T={(mj,sij,mj)/mjEM,
AOMj = {(s 1, d(s 0), ... (Si, d(si», ... }. However, it might happen that, in the case of non-availability of some specific services, a given USOM has no longer any signification. The "Automatic" USOM of a control valve, for example, has no signification in the case when the "Regulation" service is not available because the closing loop sensor is faulty. This is the reason why for each of the services which define a given USOM we have to define a limit value of the availability index which leads to identify the acceptance degree of degradation. This leads to divide the set of all the possible AOMj which can be obtained into two parts : one defines the nominal and the degraded USOM such that all the services can be rendered event under a degraded form, the other contains the cases which make the USOM meaningless.
Sij E S cm , mj E M is the set of transitions. As an example: the USOM organization given on figure 5 is described by : G ={M, T, Scm }
The Fault Detection and Isolation algorithms compute at each time, the state of the ressources and provide the availibility index of each ressource, and consequently of each service which belongs to the current USOM. Then, the AOM Management System has to determine the actual abilities of the intelligent instrument. In the case where the AOM becomes meaningless, some alarm should be dispatched to the instrument users and the AOM Management System could or not (depending on the specifications),
M = {ml,m2,m3,m4} Scm = {SI2, s23, s24, s34 ,s41' s42, S43} T = {(ml ,sI2,m2),(m2,s23,m3), (m2 ,s24' m4)' (m3,s34' m4)' (m4,s41' ml ),(m4,s42 ,m2 )(m4,s43, m3)'}
320
automatically apply a "Set USOM" request, whose destination would be an appropriately defined safe USOM. If the user wants to change the USOM and asks for a meaningless one, his request is rejected.
In our approach, the USOM of sub-systems are built in the same manner as for a device. So, we first define services of the sub-system then we build the USOM according to some constraints that we introduce.
This means that we have to define the availability of each USOM according to the availability of its services, then the transitions of the USOMs state graph (Fig. 5) have to be updated according to the evolution of the system so as to know, at each time the unavailable destination USOM. It's the role of the module "to manage" which is one of the main functions in sofar as it has on one hand, to manage the activities of the instrument and on the other hand to provide its Actual Operating Mode.
3.1. Definition of a service at the upper level Let us consider a sub-system, defined at the level n+ 1 and composed of P devices of level n. The external model of a sub-system is defined by the set of services that it renders and their organization in User Operating Modes. A service of such sub-system is naturally defined by its input data, output data, activation conditions, ressources and procedures. However, in this case, the procedure is built up on the services of the devices the sub-systems regroups.
3. DISTRIBUTED ARCHITECTURE
So the knowledge of the associated services of level n associate to a service of the upper level. allows to define completly this service.
The conception of Distributed Intelligent Automated Production Systems (DIAPS) needs to take into account the existence of USOMs in different intelligent devices which cooperate (Staroswiecki, 1993). In fact, the interoperability requirement supposes that when a device A presents a request to a device B, the latter is in a USOM such that this request is not rejected. In that sense, to insure coherence between the various levels of the automated system, we build the USOMs of each level according to the USOMs of the different devices which constitute it.
Let S be a service of the such sub-system, and let 8 = {s~, s~ , ... ,s~ , ... } be the set of services which are required for the execution of S. Each service consumes input data and produces output data. Let P( s~) be the produced data of s~, and let CC s~) be its set of consumed data. We can define the input (consumed data) and output (produced data) in the following way.
The proposed functional structure allows to build the various levels of the automated system according to the same scheme. Obviously, one of the main problems is to define the "To manage" module because the Actual Operating Mode of a sub-system is linked to the AOM of each device which compose it but also to the dependancy relations between these devices : a fault on a smart sensor can have consequences on the smart actuator which uses the sensor information.
The set of inputs of S is given by : CCS)
= UC(s~) / i
UC(s~) np(s~) i"j
The set of output is given by : peS)
In that sense, we have to define how to build the Actual Operating Mode of a sub-system. A first solution consists of building the USOM of the sub-system from the USOM of each device which compose it. This can be realized by defining asynchronous product of automata describing each device. Then, it's necessary to eliminate those USOM which are forbidden because they lead to incompatibility on the inferior level, and to define transitory modes which have to be introduced to allow to realize mode change on the devices of the inferior level (Biland, 1994; Feliot and aI., 1994). The interest of such an approach is to build automaticaly the USOMs automata for each level, the inconvenient is to have to eliminate some modes, without rules, only basing the choice on some knowledge about the wished result.
= UP(s~) / i
UP(s~) nC(s~)
i,tj
The set of ressources R(S) of the service S depends on the ressources of the service of level n. R(S) = U { rij / rij is used by s~ } i
Then, the availability index of the service according to the FDI capabilities is defined by a word deS) which is built from the availability index of each ressource that the FDI algorithm supervizes. In the same manner as in intelligent device, some procedures can be implemented to insure service S either in nominal version or in degraded ones.
321
The activation conditions are built according to the need of the level n+ 1. However, we have to insure that all activation conditions of the sin services of the level n, that the service S needs to be executed, are verified.
belong to the same USOM in the level n. Such a construction call for several remarks. First, the method avoids to associate some services which require incompatible services of a same device of level n, insofar as it respects the USOM of each device. However, services which belong to the same USOM in level n can be separated in level n+ 1. We could study the notion of incompatibility between services which not belong to the same device but which for example, share the same hardware ressource. '
At this point, we have defined a service of a composed component. We have now to define how to build the User Operating Mode so as to build coherent sub-systems.
When the regrouping of services is realized, we can have to choice between several possibilities. We, actually work on criteria which allows to select the best organization. When the set of USOM has been defined, the changing mode service is defined according to the changing mode service of the lower level.
3.2. Organization of services at the upper level
The User Operating Modes of the sub-system have to be organized insofar as the execution of the data processing associated to a service S in a given mode, can be done by calling services of the device of the level n without requiring any mode change at the level n.
Then, according to the state of the ressources of the devices which compose the sub-systrem, and the User Operating Mode selected by the user, we can know the Actual Operating Mode of the subsystem, and consequently the available services.
For each device which belongs to the sub-system, we know the application which associates to a USOM, the set of the services which are offered to the operators in this mode.
So, this method allows to build the external model of a sub-system composed of several intel~igent components. It leads to define only pOSSIble USOM according to the constraints associated with the USOM of the devices in the level n.
Ls : M~P(8)
mj
~
Ls(mj) = Sj,
So, for each service sin ' of a device I of the level n, we can provide the set of the USOM which allows the execution of this service.
4. EXAMPLE
Then, we can build a table in which the set of services {S} is placed on rows and the set of USOM of all the devices of the n level is put on columns . Each intersection is labelled I if the service is available in the considered user mode and 0 in the other case. Table 1 shows such table forp services S~+) (i = I , ... p).
...
j m).n
Sn+)
I
S~+)
0
)
S~+)
.. .
Let us consider the sub-system composed of two devices on level n. The first device, which can be for example a smart sensor, is described by its sets of services and two USOM : SI = {sll.sI2, s13. s14}
j ... m)+).
The table gives the lists of offered services in each mode for the device 1.
0
Ls(ml1)
1
sll s12 sl3 s14
1
1 1
Ls(mI2) 0 0
0 0
1
I
0
Table 2 : services and modes of device 1
Table I : Relations between modes and services When several services require the same modes on the device of level n, we can group them together and create an User Operating Mode for the subsystems . In the other cases, the services cannot belong to the same USOM of the sub-system since they need some services which do not
Fig. 6 : Changing modes of the device 1 322
m21 or to m12 and m21. We give the solution for the first case.
The device 2 which could be a smart actuator, is described by :
So, we define three USOM for the sub-system. 82 ={s21,s22,s23,s24}
s21 s22 s23 s24
Ls(m21)
Ls~m22)
1
0 1 1 0
0 0 0
SI S2 S3 S4
Ls(m23) 1 0 0 1
Ls(Ml) 1 0 0 1
Ls~
0 1 0 0
Ls(M31 0 0 1 0
Table 5 : services and modes of the sub-system
Table 3< services and modes of device 2
At each changing mode service correspond then, a combination of changing mode in the lowest devices. The transition graph of the sub-system is then given by:
Fig. 7 : Changing modes of the device 2 The services of the sub-system are defined by : SI requires s 11 and s21 S2 requires s 12 and s22 S3 requires s13 and s23 S4 requires s 11 and s24
Fig. 8 : Changing modes of the sub-system
In order to build the USOM of the sub-system taking into account the constraints of the USOM of the two devices, we build a table which links these services to the USOM modes.
SI S2 S3 S4
mll I 1 0 1
m12 I 0 1 1
m21 1 0 0 0
m22 0 1 I 0
5. CONCLUSION The external model of an intelligent instrument rests on the list of the services and their logical organization by means of the USOMs.
m23 1 0 0 1
A service is perfectly determined as soon as its characteristics (consumed and produced variables, data processing, activation conditions, ressources) have been specified for each of its versions, nominal or degraded. The User Operating Mode allows to structure the set of the services.
Table 4 : services of the sub-system and USOM modes of the devices
Then, the Actual Operating Mode is defined as the combination of the desired User Operating Mode which result of a volontary choice of the instrument users and of the endured device state which depends of the state of the device. The knowledge of the Actual Operating Mode gives the knowledge of the available services.
The service SI can be executed only if the device 1 is in USOM mll or m12 and the device 2 is in USOM m21 or m23, so we note all these possibilities. In the table, we look after rows which are include each in other or identical. They correspond to services which require the same modes at the lowest level. In this example, we can put together the services SI and S4 in the same USOM M 1. In fact, this USOM can correspond to m 11 and
Such a description coud be used for build distributed architectures based on smart instruments. In that sense, we have proposed an ascendant method which leads to build the set of services as well as the User Operating Mode of a sub-system from the structure of its devices. This 323
method can be apply at each level of a hierarchical structure of an automated production system. The advantages of this method is to build only necessary modes. It can be completed. on one hand. by introducing the notion of incompatibility between services which belong to different devices. what leads to forbid certain regrouping of services at the upper level. on the other hand. by finding criteria to choose the best solution when several regrouping of USOM of the level n+ 1 are possible.
Molinaro. P .• (1992) Kernext; langage de description des systemes de transition finis. Atelier Bordeaux-Montreal. Analyse des systemes de transition. 21 october. Robert. M. • M. Marchandiaux. M. Porte. (1993). Capteurs intelligents et methodes d'evaluation, Hermes. Paris. Staroswiecki. M. M. Bayart. J.P. Cassar. (1992). Repartition of Fault Detection Procedures in Distributed Intelligent Automation Systems. 8th IMEKO Symposium on Technical Diagnosis. Dresden. September.
REFERENCES Bayart. M .• P.H. Delmaire. M. Staroswiecki. (1990). Fault Detection and Isolation in Smart Actuators. Actuator 90. Breme. RFA. June.
Staroswiecki. M. (1993). Distributed System Supervision based on Intelligent Instruments. Int. Conf. on Fault Diagnosis. TOOL'DIAG 93. Toulouse. April.
Bayart. M. • A.L. Gehin. M. Staroswiecki. (1992). Fault Detection and Isolation and Mode Management in Smart Actuators. IFAC SICICA 92. Malaga. May.
Staroswiecki. M .• M. Bayart. (1994) Actionneurs intelligents. Hermes. Paris.
Bayart. M .• M. Staroswiecki. (1992). Smart Actuators : Generic Functional Architecture. Service and Cost Analysis. IEEE SICICI 92. Singapore. February Bayart. M. and M. Staroswiecki. (1993). Hierarchical Data and Processing Structures for the Integration of Production Processes. IFAC Workshop on Production Control in Process Industry. Diisseldorf. March. Cassar. J.P .• M. Bayart. M. Staroswiecki. (1992). Hierarchical Data Validation in Control Systems using Smart Actuators and Sensors. IFAC SICICA 92. Malaga. May. Biland. P .• (1994). Modelisation des modes de marche d'un systeme automatise de production. These de Doctorat. Ecole Centrale de NANTES, France. 18 fev 94. Feliot c.. M. Bayart. M. Staroswiecki. (1994). Specification fonctionnelle du systeme de decision de systemes automatises de production, ADPM'94. Automatisation des systemes de Production Mixte. SEE -ffiRA. Bruxelles. 23-24 november. Gehin. A.L. (1994). "Analyse fonctionnelle et modele generique des capteurs intelligents Application a la surveillance de l'anesthesie". These de Doctorat. Universite de Lille I. January. Iserman. R. and U. Raab (1992). Intelligent Actuators-Ways to Autonomous Actuating Systems. IFAC SICICA 92. Malaga. May.
324
MODE MANAGEMENT IN A DISTRIBUTED INTELLIGENT AUTOMATED PRODUCTION SYSTEM M. BAYART, M. STAROSWIECKI, A.L. GEHIN L.A.I.L URA CNRS 1440 Bat P2, UFR IEEA Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq Cedex - FRANCE Tel: (33) 20434565 - Fax: (33) 203371 89 e-mail : [email protected]
Abstract: The paper presents the smart instrument generic description organized around User Operating Mode management. In order to build smart instruments based distributed architectures which include several components, we propose an ascendant method to build the User Operating Mode of a set of devices. An example, including a smart sensor and a smart actuator, illustrates our approach. Keywords: Intelligent control, Distributed control, Methodology, Smart sensors and actuators,
1. INTRODUCTION
necessary for all the operators who will intervene during the system life. Restricting our attention to the exploitation phase in which the real time considerations are crucial, the set of the corresponding services will be called Real Time Process Operating System (RTPOS) (Bayart and Staroswiecki, 1993).
The decreasing cost of microcontrollers and the development of field buses give rise to a new generation of field instruments : the smart sensors and actuators. These new components modify the structure of classical automation systems which become Distributed Intelligent Automated Production Systems (DIAPS) which are built using a hardware architecture allowing the communication at the field level of sensors, actuators and data processing stations. The Fig.l illustrates such an architecture.
Data processing station
The emergence of such systems is also due to the development of integrated automation concepts which consider the production system from a highest hierarchical point of view and take into account not only the control and regulation functions but also those which characterize the exploitation of the production system as well as the installation and dismanteling services. In that sense, all the functions of the life cycle of the production system are considered (supervision, maintenance, management, ... ). It's what we name the Process Operating System (POS) which is defined as the set of services which are
Smart Sensor
Fieldbus manager
Smart actuator
Fig. 1 : Illustration of the DIAPS concept The RTPOS Services are provided by a number of hardware or software processing. Particularly, 317
in sofar as it has to manage the activities of the instruments or of the subsystem, and on the other hand to provide the Actual Operating Mode of the instrument (or of the sub-systems) according to its state (or its components state).
sensors and actuators are field instruments whose local data processing capacities allow them to perform some functions of the RTPOS. The functional structure is given on Figure 2. We show in (Staroswiecki and Bayart, 1994) that sensors and actuators can be described by the same overall structure since they perform a part of its functions.
In a first part of this paper, we will define the concept of Actual Operating Mode which is the main characteristics of our generic models of intelligent instruments and rests on Operating Modes and services. In a second part, we will formulate the problem of User Operating Mode Management in a complex structure which links several intelligent instruments. Then, the last part of the paper will propose an ascendant method to build these User Operating Modes. An example illustrates our approach. 2. GENERIC MODELS OF INTELLIGENT INSTRUMENTS The generic models of intelligent instruments is composed of two parts : - the functional model which describes the intelligent device from the point of view of the functions that it puts at work in order to contribute to the RTPOS distribution. - the external ones which describes the device from the point of view of the services it is able to provide to an external entity (operator, other field instrument, computer .. ). In this paper, we are only adress to the external model.
Fig. 2 : Functional structure of a Real Time Process Operating System Thus an intelligent instrument will incorporate, besides the numeric communication possibility (TO COMMUNICATE), the following functions: - to MANAGE, in order to obtain different services in different phases of the life cycle: installation, configuration, parametrization, exploitation, maintenance ... - to VALIDA TE, which distributes at the local level some procedures of the global FDI system (Staroswiecki and aI., 1992). - to ELABORATE and to MANAGE the DATA BASE perform in the same way, at the local level, a part of these overall functions (virtual sensor, state estimation, maintenance history ... ). - in the case of a sensor, the function to INPUT is always present (Gehin, 1994; Robert and al., 1993) and in the case of an actuator, we find at least the function to ACT, completed with the functions to INPUT and to DECIDE in the case of closed loop actuator (Staroswiecki and Bayart, 1994; Iserman and Raab, 1992; Bayart and Staroswiecki, 1992)
In fact, the hardware architecture of an intelligent instrument includes: - communication links with the operators and with the automation system - processing unit(s) which allow the distribution of the RTPOS functions - memories which allow the distribution of the RTPOS data base A general representation of a smart instrument in control applications is given by Fig. 3. Darn
~----~---------r-----'Darn
Processing Output unit and interface local memory interface Signals
The advantage of such a decomposition is that it's possible to construct RTPOS architectures by means of the interconnexion of smart instruments and processing stations (PLCs, regulators, computers ... ). Each smart instrument or local station perform a part of the overall RTPOS functions. However, if some functions such as to ACT and to INPUT are necessary at the lowest level, others have to be implemented in a distributed way. In particular, in this paper, we focuse on the module "TO MANAGE" which is one of the main functions
Fig. 3 : Smart instrument in a control application The interfaces are the means by which the smart instrument interacts with its environment. They include interfaces with the operators, the automation system, the physical process.
318
run in a nominal way if the set of the ressources it needs are able to perform normally. Unfortunately, this is not always the case, and it may happen that some of the required ressources are faulty. Two situations are then possible: - the intelligent instrument designer has implemented no replacement procedure. In that case, the service becomes unavailable. - the designer has implemented at least one replacement procedure. In the case when the ressources this procedure needs are effectively operational, it can be run to replace the nominal one at each request which concerns this latter. In that sense, when faults occur on the ressources, it's not necessary to interrupt the service if a "degraded" version can be executed, which increases the robustness and thus the disponibility of the intelligent instruments.
2.1. Notion of services
A service is defined as a procedure whose execution results in the modification of at least one data of the local data base, or/and at least one signal on the output interface. It is executed on the reception of its specific request by the intelligent instrument, according to its local scheduling policy and its execution cannot be split, nor can it be partly requested. The description of a service consists first in the description of the result which is produced by its execution, they are the outputs. In order to define these obtained values, one will have to describe the computations which are done (algorithmic or sequencial procedures, qualitative or fuzzy inferences, .. ), the variables on which they are done (inputs variables) and the required ressources. Moreover, before its execution, a service must verify some activation conditions. So, a service is first described by :
Let D(sj) be the set of all the values that d(sj) can take. According to the availability of the res sources, at each value d(sj) is associated either the version of the service that it has to execute or nothing if the service becomes unavailable.
< Service> ::= < Inputs, Outputs, Procedure, Activation Condition, Ressources >
2.3. Services organization
Let 8 be the set of services the smart instrument is able to perform : 8 = {SI, s2, ... , sn}
The set of the available services characterizes, from an external point of view, an intelligent device. However, to avoid that the device performs incompatible services (initialization and production services for example), the set of the services has to be organized into coherent subsets, which we call User Operating Modes (USOM).
2.2. Nominal or degraded service
The set of services needs a set of hardware ressources which may belong to the intelligent device (sensors, memory, ... ) or be external (electrical or pneumatic supplying, ... ). The Fault Detection and Isolation (FDI) algorithms which are implemented in the smart instrument allows to know the state of a part of the ressources : those which can be supervised. (Bayart and al., 1992; Cassar and al., 1992; Bayart and ai., 1990).
Let M be the set of the User Operating Modes: M = {mj,j E J} Let Ls be the application which associates to a USOM, the set of the services which are offered to the operators in this mode. Let P(8) be the set of parts of 8. Ls is defined by : Ls : M ~ p (8)
For these ressources, we define an availability index which provide an image of their state. Let dri be the availability index of the ressource i, dTj can be a binary value (ressource is present or not), or can belong to the interval [0,1], it's the case for exemple, for a tool whose availibility index informs about its state (new, partially used, broken).
mj ~ Ls(mj) = 8 j,
with the following properties:
'v'jEJ,8j*0 Each USOM IDj contains at least one service.
'v' Si E 8, :3 j E J / Si E 8 j Each service belongs at least to one USOM.
From the dri of the set of ressources obtained from the FDI algorithms, we can build a word d(sj) which represents the service availibity index of the service j :
I
d(sj) = drj1
U 8j =8 , jeJ
The set M of the USOMs constitutes a covering of the set 8 of the services (Fig. 4).
I· .. I drji I· .. I ...
where rji are the ressources which are used by the service j. At a given instant, the service will 319
Set of the services User operating Mode 2
User operating Mode 1
Fig. 4 : Services and USOMs Fig. 5 : The USOMs deterministic automata
At each time, the intelligent device is in a current USOM : the only services it will accept to execute are those which belong to that USOM, in other words, any request for another service will be automatically rejected. Such an organization plays the role of a request filter and increases the operational safety of the intelligent device.
2.4. Actual Operating Modes An Actual Operating Mode (AOM) is a combination of the current USOM which results of a voluntary action in the intelligent instrument users, and the endured device state, which depends on the non faulty ressources at the current time. This combination defines in a unique way the list of the available services, as well as, for each of them, the version under which it is available, at each instant of time. In that sense, the AOM is described by the list of services which are allowed in the current USOM, with they availability index.
To insure coherence of the services, a USOM corresponds to a set of services that operators can require in a given situation of the life cycle. They are arranged taking account safety conditions, precedence constraints, activation conditions, ... off operation, configuration, manual or automatic mode, ... are example of USOM. Obviously, the list of the services of each USOM has to contain a "Set USOM" request, otherwise it would be impossible to leave the current USOM. The definition of the set of the USOMs and of the transition conditions completely specifies the intelligent instrument USOMs management system. Let S cm be the set of services required to move from one mode to another. The USOM organization can be described by a deterministic automata (Molinaro, 1992) G ={M, T, Scm } where: - M is the set of USOM - S cm is the of the "set USOM" services - T={(mj,sij,mj)/mjEM,
AOMj = {(s 1, d(s 0), ... (Si, d(si», ... }. However, it might happen that, in the case of non-availability of some specific services, a given USOM has no longer any signification. The "Automatic" USOM of a control valve, for example, has no signification in the case when the "Regulation" service is not available because the closing loop sensor is faulty. This is the reason why for each of the services which define a given USOM we have to define a limit value of the availability index which leads to identify the acceptance degree of degradation. This leads to divide the set of all the possible AOMj which can be obtained into two parts : one defines the nominal and the degraded USOM such that all the services can be rendered event under a degraded form, the other contains the cases which make the USOM meaningless.
Sij E S cm , mj E M is the set of transitions. As an example: the USOM organization given on figure 5 is described by : G ={M, T, Scm }
The Fault Detection and Isolation algorithms compute at each time, the state of the ressources and provide the availibility index of each ressource, and consequently of each service which belongs to the current USOM. Then, the AOM Management System has to determine the actual abilities of the intelligent instrument. In the case where the AOM becomes meaningless, some alarm should be dispatched to the instrument users and the AOM Management System could or not (depending on the specifications),
M = {ml,m2,m3,m4} Scm = {SI2, s23, s24, s34 ,s41' s42, S43} T = {(ml ,sI2,m2),(m2,s23,m3), (m2 ,s24' m4)' (m3,s34' m4)' (m4,s41' ml ),(m4,s42 ,m2 )(m4,s43, m3)'}
320
automatically apply a "Set USOM" request, whose destination would be an appropriately defined safe USOM. If the user wants to change the USOM and asks for a meaningless one, his request is rejected.
In our approach, the USOM of sub-systems are built in the same manner as for a device. So, we first define services of the sub-system then we build the USOM according to some constraints that we introduce.
This means that we have to define the availability of each USOM according to the availability of its services, then the transitions of the USOMs state graph (Fig. 5) have to be updated according to the evolution of the system so as to know, at each time the unavailable destination USOM. It's the role of the module "to manage" which is one of the main functions in sofar as it has on one hand, to manage the activities of the instrument and on the other hand to provide its Actual Operating Mode.
3.1. Definition of a service at the upper level Let us consider a sub-system, defined at the level n+ 1 and composed of P devices of level n. The external model of a sub-system is defined by the set of services that it renders and their organization in User Operating Modes. A service of such sub-system is naturally defined by its input data, output data, activation conditions, ressources and procedures. However, in this case, the procedure is built up on the services of the devices the sub-systems regroups.
3. DISTRIBUTED ARCHITECTURE
So the knowledge of the associated services of level n associate to a service of the upper level. allows to define completly this service.
The conception of Distributed Intelligent Automated Production Systems (DIAPS) needs to take into account the existence of USOMs in different intelligent devices which cooperate (Staroswiecki, 1993). In fact, the interoperability requirement supposes that when a device A presents a request to a device B, the latter is in a USOM such that this request is not rejected. In that sense, to insure coherence between the various levels of the automated system, we build the USOMs of each level according to the USOMs of the different devices which constitute it.
Let S be a service of the such sub-system, and let 8 = {s~, s~ , ... ,s~ , ... } be the set of services which are required for the execution of S. Each service consumes input data and produces output data. Let P( s~) be the produced data of s~, and let CC s~) be its set of consumed data. We can define the input (consumed data) and output (produced data) in the following way.
The proposed functional structure allows to build the various levels of the automated system according to the same scheme. Obviously, one of the main problems is to define the "To manage" module because the Actual Operating Mode of a sub-system is linked to the AOM of each device which compose it but also to the dependancy relations between these devices : a fault on a smart sensor can have consequences on the smart actuator which uses the sensor information.
The set of inputs of S is given by : CCS)
= UC(s~) / i
UC(s~) np(s~) i"j
The set of output is given by : peS)
In that sense, we have to define how to build the Actual Operating Mode of a sub-system. A first solution consists of building the USOM of the sub-system from the USOM of each device which compose it. This can be realized by defining asynchronous product of automata describing each device. Then, it's necessary to eliminate those USOM which are forbidden because they lead to incompatibility on the inferior level, and to define transitory modes which have to be introduced to allow to realize mode change on the devices of the inferior level (Biland, 1994; Feliot and aI., 1994). The interest of such an approach is to build automaticaly the USOMs automata for each level, the inconvenient is to have to eliminate some modes, without rules, only basing the choice on some knowledge about the wished result.
= UP(s~) / i
UP(s~) nC(s~)
i,tj
The set of ressources R(S) of the service S depends on the ressources of the service of level n. R(S) = U { rij / rij is used by s~ } i
Then, the availability index of the service according to the FDI capabilities is defined by a word deS) which is built from the availability index of each ressource that the FDI algorithm supervizes. In the same manner as in intelligent device, some procedures can be implemented to insure service S either in nominal version or in degraded ones.
321
The activation conditions are built according to the need of the level n+ 1. However, we have to insure that all activation conditions of the sin services of the level n, that the service S needs to be executed, are verified.
belong to the same USOM in the level n. Such a construction call for several remarks. First, the method avoids to associate some services which require incompatible services of a same device of level n, insofar as it respects the USOM of each device. However, services which belong to the same USOM in level n can be separated in level n+ 1. We could study the notion of incompatibility between services which not belong to the same device but which for example, share the same hardware ressource. '
At this point, we have defined a service of a composed component. We have now to define how to build the User Operating Mode so as to build coherent sub-systems.
When the regrouping of services is realized, we can have to choice between several possibilities. We, actually work on criteria which allows to select the best organization. When the set of USOM has been defined, the changing mode service is defined according to the changing mode service of the lower level.
3.2. Organization of services at the upper level
The User Operating Modes of the sub-system have to be organized insofar as the execution of the data processing associated to a service S in a given mode, can be done by calling services of the device of the level n without requiring any mode change at the level n.
Then, according to the state of the ressources of the devices which compose the sub-systrem, and the User Operating Mode selected by the user, we can know the Actual Operating Mode of the subsystem, and consequently the available services.
For each device which belongs to the sub-system, we know the application which associates to a USOM, the set of the services which are offered to the operators in this mode.
So, this method allows to build the external model of a sub-system composed of several intel~igent components. It leads to define only pOSSIble USOM according to the constraints associated with the USOM of the devices in the level n.
Ls : M~P(8)
mj
~
Ls(mj) = Sj,
So, for each service sin ' of a device I of the level n, we can provide the set of the USOM which allows the execution of this service.
4. EXAMPLE
Then, we can build a table in which the set of services {S} is placed on rows and the set of USOM of all the devices of the n level is put on columns . Each intersection is labelled I if the service is available in the considered user mode and 0 in the other case. Table 1 shows such table forp services S~+) (i = I , ... p).
...
j m).n
Sn+)
I
S~+)
0
)
S~+)
.. .
Let us consider the sub-system composed of two devices on level n. The first device, which can be for example a smart sensor, is described by its sets of services and two USOM : SI = {sll.sI2, s13. s14}
j ... m)+).
The table gives the lists of offered services in each mode for the device 1.
0
Ls(ml1)
1
sll s12 sl3 s14
1
1 1
Ls(mI2) 0 0
0 0
1
I
0
Table 2 : services and modes of device 1
Table I : Relations between modes and services When several services require the same modes on the device of level n, we can group them together and create an User Operating Mode for the subsystems . In the other cases, the services cannot belong to the same USOM of the sub-system since they need some services which do not
Fig. 6 : Changing modes of the device 1 322
m21 or to m12 and m21. We give the solution for the first case.
The device 2 which could be a smart actuator, is described by :
So, we define three USOM for the sub-system. 82 ={s21,s22,s23,s24}
s21 s22 s23 s24
Ls(m21)
Ls~m22)
1
0 1 1 0
0 0 0
SI S2 S3 S4
Ls(m23) 1 0 0 1
Ls(Ml) 1 0 0 1
Ls~
0 1 0 0
Ls(M31 0 0 1 0
Table 5 : services and modes of the sub-system
Table 3< services and modes of device 2
At each changing mode service correspond then, a combination of changing mode in the lowest devices. The transition graph of the sub-system is then given by:
Fig. 7 : Changing modes of the device 2 The services of the sub-system are defined by : SI requires s 11 and s21 S2 requires s 12 and s22 S3 requires s13 and s23 S4 requires s 11 and s24
Fig. 8 : Changing modes of the sub-system
In order to build the USOM of the sub-system taking into account the constraints of the USOM of the two devices, we build a table which links these services to the USOM modes.
SI S2 S3 S4
mll I 1 0 1
m12 I 0 1 1
m21 1 0 0 0
m22 0 1 I 0
5. CONCLUSION The external model of an intelligent instrument rests on the list of the services and their logical organization by means of the USOMs.
m23 1 0 0 1
A service is perfectly determined as soon as its characteristics (consumed and produced variables, data processing, activation conditions, ressources) have been specified for each of its versions, nominal or degraded. The User Operating Mode allows to structure the set of the services.
Table 4 : services of the sub-system and USOM modes of the devices
Then, the Actual Operating Mode is defined as the combination of the desired User Operating Mode which result of a volontary choice of the instrument users and of the endured device state which depends of the state of the device. The knowledge of the Actual Operating Mode gives the knowledge of the available services.
The service SI can be executed only if the device 1 is in USOM mll or m12 and the device 2 is in USOM m21 or m23, so we note all these possibilities. In the table, we look after rows which are include each in other or identical. They correspond to services which require the same modes at the lowest level. In this example, we can put together the services SI and S4 in the same USOM M 1. In fact, this USOM can correspond to m 11 and
Such a description coud be used for build distributed architectures based on smart instruments. In that sense, we have proposed an ascendant method which leads to build the set of services as well as the User Operating Mode of a sub-system from the structure of its devices. This 323
method can be apply at each level of a hierarchical structure of an automated production system. The advantages of this method is to build only necessary modes. It can be completed. on one hand. by introducing the notion of incompatibility between services which belong to different devices. what leads to forbid certain regrouping of services at the upper level. on the other hand. by finding criteria to choose the best solution when several regrouping of USOM of the level n+ 1 are possible.
Molinaro. P .• (1992) Kernext; langage de description des systemes de transition finis. Atelier Bordeaux-Montreal. Analyse des systemes de transition. 21 october. Robert. M. • M. Marchandiaux. M. Porte. (1993). Capteurs intelligents et methodes d'evaluation, Hermes. Paris. Staroswiecki. M. M. Bayart. J.P. Cassar. (1992). Repartition of Fault Detection Procedures in Distributed Intelligent Automation Systems. 8th IMEKO Symposium on Technical Diagnosis. Dresden. September.
REFERENCES Bayart. M .• P.H. Delmaire. M. Staroswiecki. (1990). Fault Detection and Isolation in Smart Actuators. Actuator 90. Breme. RFA. June.
Staroswiecki. M. (1993). Distributed System Supervision based on Intelligent Instruments. Int. Conf. on Fault Diagnosis. TOOL'DIAG 93. Toulouse. April.
Bayart. M. • A.L. Gehin. M. Staroswiecki. (1992). Fault Detection and Isolation and Mode Management in Smart Actuators. IFAC SICICA 92. Malaga. May.
Staroswiecki. M .• M. Bayart. (1994) Actionneurs intelligents. Hermes. Paris.
Bayart. M .• M. Staroswiecki. (1992). Smart Actuators : Generic Functional Architecture. Service and Cost Analysis. IEEE SICICI 92. Singapore. February Bayart. M. and M. Staroswiecki. (1993). Hierarchical Data and Processing Structures for the Integration of Production Processes. IFAC Workshop on Production Control in Process Industry. Diisseldorf. March. Cassar. J.P .• M. Bayart. M. Staroswiecki. (1992). Hierarchical Data Validation in Control Systems using Smart Actuators and Sensors. IFAC SICICA 92. Malaga. May. Biland. P .• (1994). Modelisation des modes de marche d'un systeme automatise de production. These de Doctorat. Ecole Centrale de NANTES, France. 18 fev 94. Feliot c.. M. Bayart. M. Staroswiecki. (1994). Specification fonctionnelle du systeme de decision de systemes automatises de production, ADPM'94. Automatisation des systemes de Production Mixte. SEE -ffiRA. Bruxelles. 23-24 november. Gehin. A.L. (1994). "Analyse fonctionnelle et modele generique des capteurs intelligents Application a la surveillance de l'anesthesie". These de Doctorat. Universite de Lille I. January. Iserman. R. and U. Raab (1992). Intelligent Actuators-Ways to Autonomous Actuating Systems. IFAC SICICA 92. Malaga. May.
324