Generic Control/Command Distributed System - ScienceDirect

European Journal of Control (2002)8:64±75 # 2002 EUCA

Generic Control/Command Distributed System ± Application to the Supervision of Moving Stage Sets in Theaters A. AõÈ touche1, A.L. Gehin2, N. Flix1 and G. Dumortier3 1 Hautes Etudes Industrielles, 2UniversiteÂ des Sciences et Techniques de Lille, Laboratoire d'Automatique et d'Informatique Industrielle de Lille, Villeneuve d'Ascq, Lille, France; 3ERIS Automation, Vienne en Arthies, France

Supervision system requires not only a high-speed system, but also high reliability (i.e. fault-tolerant systems), high flexibility (generic design) and high scalability (distributed design). Industrial applications have revealed these absolute needs that distinguish modern architectures from the classical ones. Combining top-level Research from three fields ± automation, distributed artificial intelligence (DAI) and distributed computer science, a supervision architecture is designed that fits all these criteria. Automation provided a functional description of the smart instruments, DAI, the modularity of multi-agents systems, and distributed database technologies, a reliable protocol for transactional processing. Keywords: Control/command distributed system; Distributed artificial intelligence; Fault-tolerant system; Multi-agents system; Transactional protocol

1. Introduction For productivity and security reasons, automation systems are becoming more and more complex and need the processing of more and more information to meet the optimization constraints to which they are submitted. Classical architectures for which processing is centralized cannot easily take into Correspondence and offprints requests to: A. AõÈ touche, Hautes Etudes Industrielles, Laboratoire d'Automatique et d'Informatique Industrielle, de Lille, Villeneuve d'Ascq, Lille, France.

account the resulting increase in data and processing flows and have to evolve towards distributed ones [1]. To distribute a system, two approaches can be used. In the first one, tasks are distributed, but the decision process remains centralized [2,3], and located on the level of the supervising processors; that implies a lot of time lost in communication, and a powerful central decision engine, but the system can not keep getting slower when the number of driven processes increases. In the second approach, the intelligence of each driven process is exploited, and the central supervision engine just has to make the decisions that require a global view over the system. make sure that the system remains safe (not only for itself but also for users) and fully running. In this case the communication is a lot lighter, and huge calculators are not needed. The latter approach is issued from distributed artificial intelligence (DAI) and can be easily applied using multi-agent system (MAS) concepts [4,5]. That is the method we have followed for the generic control/ command system (GCC) presented here. The proposed supervision system differs widely from the classical ones, since it was designed starting from three main ideas: Scalability, it can drive an almost unlimited number of devices. Received April 7 1999; Accepted in revised form October 15 2001. Recommended by M. Silva and G. Cohen.

65

GCC Distributed System

Genericity, it can easily apply to any kind of application and Management of intelligent processes on several levels, the driven processes can make local decisions, the supervisor processes make the global ones.

In this paper, firstly the global supervision kernel called Yule32 is described. In Section 2, the solutions chosen to develop GCC are discussed. In Section 3, their implementation is detailed.

The best way to resolve ``multi-intelligence management'' is to consider each ``thinking'' element as autonomous. Then the communication between all the elements that are supposed to work together can be a model, expecting that each one will achieve its own mission. The proposed model is based on results on MAS description, particularly in the ``communicating agents'' field: the qualities of such a design are widely proved, as in the work [6±8] on a mobile robot. The ``scalability'' is a consequence of MAS modeling, since as many agents as wanted can be ``lived''. The ``genericity'' is obtained by offering the user an easy description method for new devices, while keeping the MAS exactly the same. In this paper, a GCC module for distributed system is presented. It runs in a global supervision kernel called Yule32 [9]. Results can be applied to such applications as supervision of moving stage sets in theaters, access control, centralized building management and batch-process driving. The case of the supervision of moving stage sets in theaters will be taken into account to illustrate this article. To deal with such applications efficiently, the system is able to drive any instrument on the network from any user station and thus can manage allowances, conflicts, and faults. Up-to-date technologies, distributed computing, MAS and transactional protocol are used in the Yule32 extension for this distributed control/command system named GCC.

2. General Framework

Supervision kernel : Objects / meta-objects database

2.1. Yule32 System Software substructure of Yule32 assumes all functionality of an industrial information system. It can be likened to a package that includes a full-featured development framework, a substructure (along the same line as component broker), a concentrator (such as middle-ware) and a philosophy, which extols that most of components in the system should be described and not hardly coded! As shown in the skeleton of Fig. 1, in that system the main components are A real-time supervision kernel built around an object/meta-objects database, called Generic object Data Base (GDB), acting like a micro-kernel operating system and offering basic behavior. It can receive Plug-In modules to extend its behaviors (new services such as NetDDE, SNMP, events manager and new drivers, providing necessary tools to control the instruments), A communication server, named GAD, that ful®lls syntactic translation into ®tting industrial protocols (ModBus/JBus, busCAN, etc.), A generic security agent (GSA) that checks identities and allowances using standard access control list (ACL) and Mandatory Access Control (MAC).

GDB Client GCC Client

GAD Server

Plug-Ins Modules

Application

User Station GDB Server

Driven Instruments

GSA Security Agent

GCC Server

Fig. 1. Architecture of Yule32 system.

66

For the last user, the way Yule32 runs is quite common, since it works as a client/server architecture, on a global network called primary network. A user operates from a client station, which connects transparently to one or more servers; servers drive the instruments they are plugged to (on their secondary networks), managing all transactions. 2.2. Role of GCC For theater supervision such as access control or any other application, a flexible system supposes that any operation can be performed from any client-station on the network. Moreover, when several users want to access the same resource (i.e. the same instrument or the same function offered by this instrument), some processes have to deal with locks to avoid conflicts. This problem arises as the number of concurrent processes increases. The architecture should be highly scalable, i.e. almost unlimited with the number of clients and servers. Finally, when any element of the control/command chain is broken (hardware or software failure) the system must recover a consistent state without any risk for humans or machines, without complex operation to handle. For above four reasons, GCC module of distributed control/command is necessary.

A. AõÈtouche et al.

objects [14]. Consequently, a command from a switch box directly plugged into an instrument will not be a problem, since it will be handled as a simple update of the instrument's state. It is not necessary to precise by state that the ef®ciency and the reliability of GCC strongly depend on this real-time service. Another dif®culty which is worth considering is the synchronization of several instruments. This case is found in the theater when a scenery element is too heavy to be moved by a single motor. Then it is necessary to synchronize several motors with no risk of for failure because it can destroy the element . . . . In this paper this operation mode will be called group running. Finally, the control/command module must be generic, i.e. it should be interfaced easily with any service-process offered by a network, and with any application using this process. The work in [15,16] suggested a coordination module called ARCHON (ARchitecture for Cooperative Heterogeneous ON-line Systems) that matched this functionality encapsulating any program to make it distributed; our realization is quite different since it is optimized for supervision. All speci®c characteristics of driven instruments will be loaded from description ®les, totally independently from the system's kernel; moreover, all application-speci®c processes like compilers will be implemented as removable plug-ins.

2.3. Specific Constraints To develop the GCC system considering all possible running configurations, the supervision of theaters, where driven devices are speed controllers for motors that move stage sets, has been chosen. This application brings out all the tricky points that can be met in any application mentioned above; particularly the essential following points: Driven devices are considered as smart instruments such as theater supervision and access control. These instruments are built around microcontrollers and provided with communication facilities [10±13]. On-board processors make all quick (``reactive'') decisions, so upper level units that provide supervision service ± Personal Computers for example ± have to deal with this decentralized intelligence to complete their mission. It supposes that the supervisors own a real-time image of the instruments they drive, which is quite ambitious. This function is offered by the Generic object Data Base module, where images are called proxy

3. Chosen Solutions for GCC 3.1. Control/Command System, User's Point of View The writing of an application using GCC architecture requires to interface the program with a client-station, using a very restricted set of functions that create, execute or destroy the commands. The client-station is connected to a coordinator± server that was chosen on the network among the running ones. Any command from this client has to be written in a user format, such as {axis1.go (height 15 m, speed 1 m/s);} The syntax is the same for prompted commands (keyboard, touch-screen, joysticks, etc.) as for recorded ones. In the field of theater supervision a complete record for a show is called a script, and can be edited with any text-editor. A script is composed of sequences that are

67


groups of commands executed simultaneously. By default, in case of a failure the system will return to the beginning of the sequence. A sequence is composed of several requests, that can be commands dedicated to instruments or to groups of instruments. Please note that this vocabulary will be used for any application. When the user has created a script, and is ordered to launch its execution, the coordinator manages all the process. It deals particularly with conflicts, allowances and recovering a consistent (stable) state in case of a failure. All these functions are totally invisible to the custom-application which is simply given the result of the script's execution . . . .

3.2. Modeling C/S Architecture as MAS To be a real distributed system, GCC has to assume that 1. The different entities of this system (i.e. the different software modules) are relatively independent. 2. These entities are able to communicate with each other, through interfaces that can be accessed easily. This modular and scalable architecture was used in particular for mobile robot [6], and widely proved its qualities in terms of flexibility and speed. In the field of DAI, the software entities which certify the properties above are called agents [17].

CLIENT AGENT 1

Coordination Interface (client)

Indeed, they match all properties of communicating agents (as opposed to purely situated agents): they are quite autonomous, they are able to communicate directly with other agents, they often have a partial representation of their environment, and they offer services to other agents. Moreover, their behavior tends to satisfy not only their own objectives, considering their resources, their skills, their perception, but also to consider the communication factor. For the theater application, three distinct types of agents can be distinguished: the client±agent, the coordinator±agent, and the executor±agent (Fig. 2). The role of a client±agent is simply to collect scripts from user-applications, and send them to a coordinator that it chooses among those running on the network. Then the chosen coordinator±agent is responsible for managing the execution of the scripts, which includes the following three important tasks: 1. Check whether the syntax of the script is valid in user domain format, and store it for back up. 2. Dispatch the different sequences to executors on the network, which includes localizing the targetinstruments in the global system for each request, checking whether the involved instruments are available or not for the script and ensuring synchronization if necessary. 3. Inform the client about the result of script execution.

Coordination Interface (client)

CLIENT AGENT 2

ODBC Interface (server)

Coordination Interface (server) SECURITY AGENT

Security Interface (server)

Security Interface

COORDINATOR AGENT

DATABASE AGENT

ODBC Interface

Execution Interface (client)

EXECUTOR AGENT 1

Execution Interface (server)

Execution Interface (server)

Execution Interface

EXECUTOR AGENT 2

Fig. 2. GCC as a multi-agents system (MAS).

EXECUTOR AGENT 3

68

To fulfil the above three functions, a fourth one which is not part of normal running but is also very important ± the back-up management, can be added. Presently, all required information to ensure the recovery of a consistent state in case of failure is stored by the coordinators in a distributed independent database. Finally, an executor±agent receives requests from coordinators (by sequences) and looks for the instruments on its own dependency. It has to translate the requests that are in a user format into commands in the supervisor semantic. For this purpose it retrieves the functional descriptions of the instruments provided in the expert format files, and objects that represent the instruments in the database. Then it decides according to the current state of the instruments if they can handle the requests, and informs the coordinator. When the latter decides to validate a sequence, the executor is responsible for the achievement of all the requests that concern the instruments it accepted to drive. Consequently, two communication interfaces have been brought out which GCC agents need to communicate with a coordination interface between clients and coordinators and an execution interface between coordinators and executors. Describing GCC as an MAS highlights interesting properties, in particular easy software re-using. If somebody wants to access any software module that was designed with MAS architecture, one just needs to know its communication interface. Precisely, any action of any agent can be analyzed as an act of language, as shown by [18], considering this single principle: ``Saying is doing''. Each message is associated with an action, and managed as any other kind of action. Then it is easy to match messages with their consequences; hence the description of our software implementation is based on communication acts. 3.3. Modeling Driven Instruments 3.3.1. Why GCC needs a Functional Model In General object Data Base supervisor internal structures and instruments are represented as containers and objects. The different parameters they handle are objects, like the different constraints they must respect; besides the services they offer are methods called telecommands which make the physical resources of the instruments accessible. The proxyobjects mentioned above are located here, and are updated in real-time. It allows us to elaborate other


objects called states, which describe the current situation of each instrument, but modeling an instrument only by its current state is not enough for GCC. Actually, the executors need a more functional description to make the right decisions, as they have to know for each state actions can be completed and ones that cannot. Besides, in order to manage an instrument properly it is necessary to have a proper description of it! This implies a description in terms of modes: operating modes (manual, semi-automatic and automatic) and running modes (normal and degraded). Even if the instruments are not designed in accordance with this model, it is always possible to recast them into this mold, at least on the supervisor side. It has been the case for the first devices that were driven by GCC. 3.3.2. Modeling Instruments using a Graph of Menus As has been seen before, the driven instruments can be considered as smart instruments. As such they can be described by the external model proposed in [19,20]. The external model describes the device from the point of view of the services it is able to provide to external entities (operators, other field instruments, computers, etc.). A service is defined as a procedure whose execution results in modification of at least one data of the local data base or/and at least one signal on the output interface. The description of a service consists first in the description of the result produced by its running. The produced variables are those whose value is modified in the local data base or/and those it issues on the output process interface. In order to define the obtained values, one must describe the computations that are done (algorithmic or sequential procedure, qualitative or fuzzy interferences, etc.) and the variables on which they are done ± the consumed variables. A service is run on the reception of its specific request. If requests may be addressed to the device at any moment, for security reasons, the corresponding services may not be automatically run. For example, initialization and production services must not be simultaneously run. For that reason, the set of services has to be organized into coherent subsets called operating modes. The running of a service needs a set of resources, which includes hardware resources (sensors, memory, etc.) and information resources ± the consumed variables. If one of these resource is faulty fault-tolerant devices may integrated replacement procedure to perform the same service. We will say that a service is an ordered list of versions.

69


Each version is characterized by the resources it needs. In response to a request, the device runs the first version of the list whose resources are all non-faulty. In GCC architecture it is assumed that every executor owns a functional description of the instruments it controls. For that description, the external model suggested by [20] has been adopted. It includes The list of elementary services (also called lower level services) offered by the instrument, i.e. the list of indivisible actions which cannot be obtained by grouping other services. To each service a list of class numbers is associated which determines the running modes where the service is available. To each class number a version of the service corresponds, and when the service is called the instrument selects the version that matches to lowest class number, i.e. the ``less degraded'' running mode. An example will be given below. a graph of menus (also called graph of constraints) that represents all the possible transitions from one state to another. For each state it can directly be read which decisions (i.e. which actions) are possible and which state will result following any of these possible decisions. Of course, this considerably simpli®es the task of the supervisor's decision engine. a list of operating modes. The crossing from an operating mode to another is given on the graph of menus like a simple decision. lastly, a list of running modes with the corresponding class numbers.

an operator using a local joystick) have been separated (Table 1). Every other service is an upper level ones, and can be obtained by combining the lower level commands listed above. Another addition to this external description is that internal constraints that can be exploited directly by the instrument to make a local decision are distinguished from external constraints that can be handled only by the supervisor because an external view is required. In this case, a group of instruments must be synchronized, for example, the position of all the elements in the group must be got. Table 1. Decision of supervisor and instrument. Service

Decision of supervisor

Decision of instrument

Available in classes

Go up Go down Stop Emergency shut down (ES) Restart after ES Start pause End pause

DS0 DS1 DS2 DS3

DC0 DC1 DC2 DC3

0, 1, 2* 0, 1, 2 0, 1, 2 0, 1, 2, 3

DS4 DS5 DS6

DC4 Ð Ð

0, 1, 2, 3 0, 1, 2 0, 1, 2

*DC0 and DS0 are available in normal running (class 0), speedlimited running (class 1) and load-limited running (class 2). For example, if the device detects an abnormal temperature for the motors, it will switch to class 1. If the problem persists, it will switch to class 2.

Table 2. Internal and external constraints.

3.3.3. Example of a Speed Controller for Theater Supervision To illustrate and test external model [20] let it be applied it to a speed controller for theater supervision. The registered elementary services are listed below. The decisions DSi that are made by the supervisor (issued from keyboard/screen actions or from recorded scripts), and the decisions DCi that are made on the instrument side (either by the processor or by

Internal constraints

External constraints

Mechanical limit stops Over-loading Under-loading (the load probably dropped) Others Software limit stops (stage set-depending) Synchronization (grouped running) User identity Others

Table 3. Operating mode description. Operating mode

Description

MAN (manual) INST (install)

Manual driving from a ``switch box'', controlled by the supervisor (limit stops, etc.) Manual driving from a ``switch box'', mode for stage set installing not controlled by the supervisor Manual driving from a keyboard, a screen, etc. of the supervisor, controlled by this supervisor (limit stops, etc.) Automatic execution of a recorded show, (thus controlled by this supervisor)

MANSUP (manual-supervisor) SUP (supervisor)

70


4: Pause

{ D S6 }

D S5

D S6

5: M AN +

1:

M A N SU P + SU P

D S4

3:

{ D C 0, D C1, DC3 }

{ D S0, D S1, D S3, D S5 }

Stop

Stop

IN ST

DC3

D S3

6:

DC4

E.S .

E.S. D S0 + D S1

{ D S4 }

DC0 + DC1

{ DC4 }

DC2

D S2

DC3

{ DS2, DS3}

{ D C 2, D C3} 7:

2:

M ovem ent

Movement

Decision from supervisor

Decision from instrument

Fig. 3. Speed controller-graph of menus. Table 4. Running mode description. Running Mode

Class

Description

Normal Slow

0 1

Reset

2

Unavailable

3

Normal running Running with limited speed, (degraded mode) Running with limited speed, wait for arriving on a limit switch to reset, position sensor Instrument cannot be used

Constraints are quite numerous, but the following one can be quoted as an example (Table 2). For each decision a list of constraints is associated, and when a supervising process is about to execute a command it starts checking the corresponding parameters. As for operating modes, four types are registered given in Table 3. Finally, the running modes are given in Table 4. The resulting graph of menus is given by Fig. 3. A sample of a description file is given by Appendix A.

4. Implementation of GCC 4.1. Development Framework Globally, Yule32 project is developed for Windows NT platforms, in mixed C/C languages with the raw Win32 API (Application Programming

Interface ± we use a subset of this API to be compatible with Embedded NT). The communication interfaces between servers and clients processes are implemented using an specific library, built on the basis of Remote Procedure Call (RPC) and the Interface Description Language (IDL ± from CORBA). It provides features such as auto-discovery, auto-recovery and scalability from a standalone workstation to a full clustered enterprise level servers. All accesses to databases go through standard ODBC library (using SQL requests), in order to ensure that the software can be easily interfaced with any current enterprise product. The compilers have been written using the freeware GNU's Flex and BYacc tools. The GCC Execution module interfaces GDB (and the instruments accessed through GAD Server) with GCC Distributed Control/Command Server. It is implemented as a GDB service Plug-In. However, in order to allow their reusability for totally different applications (for example to develop an agent providing functionality comparable to ARCHON quoted above), GCC Server and Client parts have been developed totally independently from the GDB kernel. GCC Client module offers a very clear and simple set of functions, which allows the fast development of any application that requires distributed control/command. It is planned to interface it with GDB Client, in order to provide a single ``smart'' client

71


APPLICATION GCC CLIENT [ C r e a t e G r o u p C l o u d = ( a x i s 1 ,a x i s 2 ) ; ] { C l o u d .G O ( p o s i ti o n = 5 m , s p e e d = 1 m / s ) ; } Coordination interface (client)

Coordination interface (server)

GCC SERVER U S E R ' S SCRIPT CO MPILATIO N

Lexical analysis Syntactic analysis

Translation Plug-In

C l ie n t s S c r ip ts Sequences R eq u est 1 :

R eq u est 2 :

R e q u e s ts I n s tr u m e n t : A x i s 1 C om m and : T G O P a r a m e te r s : P o s it io n = 5 m S p e e d = 1 m /s I n s tr u m e n t : A x i s 2 E tc .

COORDINATION E x e c u to rs R e q u e s ts h a n d l e d E tc .

E x e c u t i o n i n t e r f a c e ( c l ie n t )

E x e c u tio n in te r fa c e (s e r v e r)

GCC EXECUTOR GDB SERVICE

CLIENTS MANAGEMENT C l ie n t s A llo w a n c e R e q u e s ts E tc .

REQUESTS HANDLING EXPERT COMPILER IN F E R E N C E E N G IN E (E x p e r t S y s te m )

The treatment of a script from its creation in the application to its execution by GDB commands is summed up by Fig. 4. As announced, the flowing of this script along GCC System following the different communication acts, between clients and coordinators first, then between coordinators and executors is described. The accreditation of the client is passed through the communication link so that at each speech act, the security agent can validate the transaction. Manipulated objects (states and telecommands) are secured with the client security token and not with the one from GCC Execution module.

Requests checker Telecommands interface

4.2. Client±Coordinator Communication An application initiates a script by calling gccCreateScript() client function, that sends a string containing this script to the coordinator (through coordination interface). At first, the coordinator isolates the different tokens (words), and checks the syntax. The sequences are distinguished between { } containing requests separated by semi-colons: {(executor.)instrument.command (parameters);} and the reserved parts between [ ] including information for the translation module: [CreateGroup group_name (instrument1, . . . );] Then syntax-validated requests go through a translation plug-in. Presently this plug-in just stores groups described in reserved parts and `èxplodes'' requests addressed to groups into requests addressed to instruments (of course there are as many requests as the number of instruments in the group). After checking and translating, the script is marshaled to a memory structure, ready to be transmitted to executors. Then the application can request the script to be executed, cancelled, resumed, destroyed . . . . Of course all these operations are gradually validated by the coordinator. The specificity of our software can not betotallydetailed inthispaper.Itcanbepointedoutthat RPC connection-points and asynchronous threads are used, which makes GCC a really powerful system. 4.3. Coordinator±Executor Communication

Fig. 4. Architecture of GCC software.

module that can use distributed functions if they are available for the task concerned. The skeleton of an application using GCC Client is presented in Appendix B.

Coordinator !Executors communication is quite a tricky point, since any deadlock at this stage can be lethal to GCC reliability. For this reason, a fault tolerant transactional protocol which is commonly used in distributed applications [1] (particularly for databases [21]), and is known for its wide reliability has been adopted. This protocol is 3PC (Three Phases

72

Commitment) [22]. It occurs in three stages: Firstly, the coordinator sends a ``prepare'' message to the participants; the latter ones send back their votes, so that the coordinator can either decide to go on or to abort the transaction (Phase 1). If the transaction goes on, the coordinator sends a message ``pre-validate'' to the participants, ordering them to lock the resources involved; the participants give back an `àck'' (Phase 2). During the last phase, the coordinator ®nally validates the transaction, which means that the participants can physically execute the request(s) (Phase 3). Now an example showing the 3PC protocol is applied to the communication between coordinators and executors (the Appendix D offers a sample of a typical dialog sequence). When a client requests the execution of a script, the coordinator really starts the coordination process, which enters Phase 1 by sending the requests of the first sequence (i.e. the first transaction) to all running executors of the network, and then waits for their responses. Each executor tests if any instrument is under its own control. If there is one response: 1. It tests if this instrument is available: not currently used by another process, accessible by the calling user, in accordance with the security agent. 2. It checks the request: It translates the request into a valid telecommand handle, using the expert descriptions: for example ``DS2'' into `Àxis1.Stop''. It considers the current state of the modeled instrument, the values of the parameters, and decides if the request is possible (always according to the expert data). At this stage it must also check that the constraints associated to each command are respected. These constraints are translated like the requests, and associated with the ®tting data in the driver's substructure. At the present they are processed as if . . . then . . . else statements, but eventually the existing Inference Engine is connected to make decisions, such as an Expert System. Then the executor sends its vote back to the coordinator. When all votes are collected, the coordinator decides to pre-validate or to abort the transaction; in the first case Phase 2 is carried out. At this stage the executors


lock the instruments concerned and the process goes on. If all instruments are locked, the coordinator validates the transaction (Phase 3): the physical execution of the requests (telecommands sending through the communication server) occurs here. Then 3PC protocol is repeated for each sequence (transaction) of the script. 4.4. Reliability and Error Recovery One of the main reasons why we opted for developing a distributed control/command module is its reliable behavior in case of system fault. This is what happens when one of the three links in the chain fails during a critical stage (the most interesting points are just quoted here). If a client fails while a script is being executed for itself, the coordinator properly ends the script according to the directives it has been given: it either terminates the whole script, or just terminates the current sequence (i.e. the current 3PC transaction). Then it destroys the script, since the client has not stored it. If a coordinator fails while a script is created but not terminated yet (i.e. waiting for execution order from client, inside a 3PC transaction for execution, etc.) the case is more complex. The client must elect a back-up coordinator among the running ones. This new coordinator will find in the distributed database all needed information to resume the scripts handled by the failed server (i.e. scripts structures including sequences, requests, 3PC current phase, etc.). In the mean time, the executors interrupt the sequence as they must do in 3PC protocol: they cancel the last transaction (sequence) by restoring the state of the instruments which are in the beginning of this transaction (in particular they are involved instruments). Finally, if an executor fails during the execution of a sequence, 3PC is interrupted as described above, and the coordinator notifies the client that the script is suspended. It can be resumed when the failed executor recovers.

5. Conclusions Due to the new results of the research done in automation, DAI and distributed computer science, a GCC distributed system has been proposed. The process components of this system are said to be intelligent due to their communication and processing facilities. They are described with an external viewpoint as entities providing services to users. Services are organized into operating modes and are accessible


through a menu which offers safety running. Faulttolerant aspect is taking account by the notion of several versions for a same service. These components have to cooperate between themselves to realize an application. To describe this cooperation and the communication it requires, the multi-agent approach is used. Each agent has a role, some competence and some resources and it can offer them to the others by the way of speaking. Describing GCC as a multi-agent system is interesting since it allows software reusing. A fault-tolerant transactional protocol adapted from the database domain has been used to define a reliability communication between the different agents. Applied to the supervision of moving stage sets in theaters, the proposed generic control/command distributed system has given good results.

References 1. Jalote P. Fault tolerance in distributed systems. Prentice Hall, PTR, 1994 2. Kutten S. Distributed computing. Lecture notes in computer science, Springer Verlag, Berlin, 1998 3. Decker K. Distributed problem-solving techniques: a survey. IEEE transactions on systems, man and cybernetics, 1987; 17: 729±740 4. Ferber J. Multi-agent systems: towards a collective intelligence. Addison-Wesley, Reading MA, 1998 5. Weiss G. Multi-agent systems. MIT Press, Cambridge, MA, 1999 6. Perebaskine V. Une architecture modulaire pour le controÃle d'un robot mobile autonome. In: PhD Thesis of University of Toulouse 3, 1992 7. Basran JS, Petriu EM, Petriu DC. Flexible agent based robotic assembly cell. In: IEEE International conference on robotics and automation, 1997, pp 3461±3466 8. Arkin RC, Balch T. Cooperative multi-agent robotic systems. In: Kortenkamp D, Bonasso RP, Murphy R (eds). Artificial intelligence and mobile robots, MIT/ AAAI Press, MA, 1998 9. Flix N, Dumortier G, AõÈ touche A, Gehin AL. Generic Control/Command Distributed System. In: Europeean Control Conference ECC'99, Karlsruhe, 1999

73 10. Staroswiecki M, Bayart M. Models and languages for the interoperability of smart instruments. Automatica 1996; 32: 859±873 11. Najafi K. Smart sensors. J Micromech Microeng 1991; 1: 86±102 12. Isermann R, Raab U. Intelligent actuators: ways to autonomous actuating systems. In: IFAC Symposium on Intelligent Components and Instruments for Control Applications, Malaga, 1992 13. Gehin AL, Logier R, Bayart M, Staroswiecki M, Cantineau D, Delecroix M. Application of the smart sensor concept to the anesthesia supervision. In: 15th Annual International Conference, IEEE engineering in medicine and biology society, San Diego, 1993 14. Ledoux T. Implementing proxy objects in a reflexive ORB. In: Workshop CORBA: implementation, use and evaluation as the 11th European Conference on objectoriented programming, 1997 15. Jennings NR. The ARCHON system and its application. In: Proceedings of 2nd International conference on cooperating knowledge based systems 1994, Keele pp 13±29 16. Jennings NR, Pople JA, Mamdani EH. Designing a reusable coordination module for cooperative industrial control applications. In: IEE Proceedings control theory and applications 1996; 143: 91±102 17. Ferber J. Multi-agent systems: towards a collective intelligence. Addison-Wesley, Reading, MA, 1998 18. Searle JR. Speech acts: an essay in the philosophy of language. Cambridge University Press, 1969 19. Bouras A, Staroswiecki M. Building distributed architectures by the interconnection of intelligent instruments. In: IFAC International symposium in control in manufacturing, Nancy, 1998 20. Bouras A, Staroswiecki M. How can intelligent instruments interoperate in an application framework? A mechanism for taking into account operating constraints. In: IFAC Symposium on intelligent components and instruments for control applications, Annecy, 1997 21. Besancenot J et al. Les SysteÁmes transactionnels: concepts, normes et produits. Hermes, collection informatique, 1997 22. Skeen D. Nonblocking Commit Protocols. In: International conference on management of data, 1981

74

Appendix Appendix A: Sample from a Speed Controller Description File (Coded in C Language) /* Correspondence decision ! action telecommand) */ /*Running modes */ DECISIONS { // DS0 on figure 3: ``go up'' // available for running modes of classes 0,1,2 D0 (0,1,2) TGo; // DS1 on figure 3: ``go down'' D1 (0,1,2) TGo; // DS2 on figure 3: ``stop'' D2 (0,1,2) TStop; // DS3 on figure 3: `È.S.'' D3 (0,1,2,3) TEmergencyStop; // DS4 on figure 3: ``restart for E.S.'' D4 (0,1,2,3) TAcquit; // goto mode MAN or INST on figure 3 // no corresponding command on the instrument yet D5 (0,1,2,3); // etc.

}

/* Decision matrix representing the graph of menus */ GRAPH { 1,2 {D0, D1}; // state m1 to state m2 on figure 3 1,3 {D3}; // state m1 to state m3 on figure 3 1,5 {D5}; // state m1 to state m5 on figure 3 3,1 {D4}; // state m3 to state m1 on figure 3 // etc. } /* Description of constraints */ CONSTRAINTS { // constraints that are common for all decisions (any class) D* { temperature < 65, load < 1250 kg, load > 950 kg }; // constraints that are decision-specific // for ``go up'' decision, limit speed and height // when degraded running (classes 1 and 2) D0 (1,2) {speed