Nuclear Instruments and Methods in Physics Research A 389 (1997) 110-l 13
ELSEYIER
NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH SectlonA
YASB A development tool for intelligent multiplatform distributed control systems* Fulvio Bilk, Roberto Pugliese* Beamline
Control Group. Scientijic Diuision, Sincrotrone
Trieste, Pudriciuno
99, Triesfe 34012. Ital>
Abstract An extension of the basic client/server model has been designed to address interacting scenarios of decentralized, peer-to-peer collaborative computing where application can be modelled as a set of interacting but independent agents. Each agent is layered on top of an object-based, message passing communication substrate, which transparently manages the complexities of inter program asynchronous interactions across networks of heterogeneous computers. We have named such communication substrate YASB (Yet Another Software Bus). Ke,vwords: Computer
science; Software;
Distributed
control
1. Introduction Software developers in advanced research facilities, often face the problem of integrating a horde of different instruments, commercial tools and independent preexisting systems in a possibly distributed environment. The dream of the experimental scientist is to handle the whole as soon as possible through a graphical user interface on some workstations possibly without having to learn new application enabling and development environments. In this context system integration is an “art”. The components, even those whose “openness” is claimed, present a very low level interfacing capability. Due to the lack of a standardized approach, practically every integration problem is a completely new story which leads to little or no software reuse. Moreover, experimental scientists ask for more and more advanced features. Distributed applications present design costs which are not present in unitary systems due to increased control complexity. Intelligent control systems are really welcome in this environment. Applications such as automatic beamline alignment, advanced diagnostics and automatic analysis of the experimental data are still open problems. We strongly believe that middle ware is the
AIHENP96 abstract: SE-1 13 *Corresponding author. Tel.: + 39 40 3758024, fax: + 39 40 3758575, e-mail:
[email protected].
system; Software
bus; Component
software
key to stop re-inventing the wheel, reach software maturity and make a technology out of an art. A software bus, that is an underlying control model to co-ordinate information exchanges and networking software to implement that model, would enable to face integration problems at an higher abstraction level through a standardized methodology. With this in mind we have designed an extension of the basic client/server model based on the concept of agent, that is an independent software machine. Applications can be modelled as a set of interacting agents. Each agent is layered on top of an objectbased, message passing communication substrate, which transparently manages the complexities of inter-program asynchronous interactions across networks of heterogeneous computers. We have named such communication substrate YASB (Yet Another Software Bus). YASB has been designed to be easily portable across different platforms, integrable with commercial tools and in-home developed ones, extensible but with the mandatory constraint of being light weight.
2. A development tool for distributed systems Critical design issues for distributed systems include resource localization, inter-program communication on the network, co-ordination and synchronization, error handling and security. Co-ordination models are a way to handle coherently all these issues. A co-ordination
0168-9002/97/$17.00 Copyright 1.c)1997 Elsevier Science B.V. All rights reserved PI1 SO16S-9002(97)00057-O
F. Bilk. R. Pugliese ,INd.
lnstr. ami Meth. in Phys. Rex .4 389 (1997) lItI- 113
model establishes logical roles and behaviours for executing distributed interactions. A widely used co-ordination model is the client/server architecture where the client, request a service provided by the server [l]. A major limitation in the basic client/server model is its focus on clients requesting individual services. Clients often need to invoke multiple services, and sometimes they are themselves service providers. An extension of the basic client/server model has been designed to address this kind of interacting scenarios of decentralized, peer-topeer collaborative computing where applications can be modelled as a set of interacting but independent agents [?I. Agents are independent software machines, that is. active objects implemented in software, which are components of a computer system. Programming with agents thus involves constructing different specialized machines and then interconnecting them in order to achieve the required higher-level functionality. This is analogous to the way that hardware designers combine standard components to construct specialized circuit boards. One of the benefits of the agent paradigm is that agents tend to be relatively self-contained and autonomous. This is because agents are specialized, leading to a tendency to incorporate in them most of the elements required to perform their functionality. As a result, an agent and its environment are not very tightly coupled. This is highly desirable since it enables the agent to be reused in different contexts. In order to make the coupling between objects as weak as possible, communication between agents is based on a message-passing model. The essential feature of this model is that information between agents is exchanged by means of an intermediate artefact a message. The sender packages the information that it wants to send into a message and then dispatches it to destination. When the destination receives the message, it responds by performing the activity appropriate to that message.
YASB defines a weak programming model that must be followed when writing applications. In general an agent application (Fig. 1) can be modelled as a finite state virtual machine where state transitions happen when some message arrives on some input port (i.p.). An input port is associated with an application-dependent handler which implements an agent service. The handler decodes the message and does anything needed to satisfy the request, that is raise a state transition and/or communicate with other agents. The handler can thus send some message to some other agent through an output port (0.p.). YASB supports different categories of messages: ~ blocking: the Send procedure behaves as a Remote Procedure Call (RPC), after dispatching the message waits for the execution of the handler of the receiving agent.
Ill
i Fig. I. Agent application architecture.
~ no-blocking: the SendNoBlock behaves as a one-way RPC, after dispatching a message, immediately returns control to the caller, which then continues executing independently of the subsequent handling of the message. ~ call-back: the SendCallback returns without waiting for the results which will be sent back (when available) to the specified call-back input port (c.p.) of the caller. Generally a distributed application should be able to cope with two different kinds of events: external asynchronous events (such as an interrupt from some l/O device), and time-based events which are the basis of polling behaviours [3]. To support time-based events an agent can use an agenda that is a list of deferred or iterative actions. These actions (a.p.) behave as an input port despite the fact that their handlers are raised when an internal event, namely a time-out, occurs. Actions and ports can be created dynamically without any restriction. The YASB application model considers also user ports (u.p.). Through these kinds of ports an agent represents in an uniform and coherent view any application specific event which cannot be considered either an inter-agent communication event or a time-based one. 2.2. The agent nzanuge~ Agents can integrate generic control models to co-ordinate interactions. Particular control agents can be envisaged to implement specific control roles. An example is the Agent Manager (AM), that is a sort of bus controller which acts as an agent name server. The AM is a request broker, that is a dedicated control mechanism that mediates interactions between clients and servers. Brokers free clients from having to maintain information on how to obtain particular services. All applications that belong to a distributed system register the services they support as well as their location and possibly client interfaces with the broker.
11~.CONTROL~I~ISTRIBLJTFD
SYSTEMS
112
F. Bill@,R. Pq$iese i Nucl. Instr. and Met/r. in @vs. Res. ‘4 389 (1997) 110-I I3
Typically a broker provides a naming service. Depending on the broker model, services are registered dynamically (during runtime) or statically (during compile time). Brokers can support different interaction models. The forwarding broker provides one locus of control for all client requests and server responses. Failed interaction can be detected and re-attempted centrally, so that clients need not worry about fault tolerance and recoverability. However, excessive message traffic and request logging can degrade the overall performance. Handle-driven brokers reduce the potential for bottlenecks, because responses bypass the broker. Moreover: clients can store handles for later re-use, which can reduce broker traffic. However, handle-driven brokers shift the burden of detecting and managing faults to the clients. YASB adopts the handledriven approach with dynamic registration which seems more suitable to real-time environments. 2.3. Tlze application programming interjtice The YASB Application Programming Interface (YASBAPI) enables the development of agent-based applications. The API provides architectural components for mediating interactions between applications and managing an action agenda. Messaging systems typically provide a high-level application programming interface (API) for posting messages to outbound queues and for polling inbound queues to retrieve responses. This tends to push additional control behaviour into applications, impacting the distributed systems’ modularity, maintainability, and extendibility. To solve this problem, YASB-API is based on the agent object artefact. The programmer of an YASB agent initializes the bus, creates an agent object and sets it up by binding the required application specific code. When activated, the agent object transparently manages the complexities of inter program asynchronous interactions across networks of heterogeneous computers. YASB-API provides methods to configure the agent object that is. to create and destroy input and output ports and to manipulate the agent agenda. No direct support is provided for user ports, states and state transitions. Applications specific code can be bound to the agent through handlers, that is functions which are associated with input ports and agenda actions. The API incorporates primitives to pack all the primitive data types into YASB message objects. Separate primitives for blocking and no-blocking communication are provided. A call-back model of asynchronous messaging is also supported. A set of convenience functions to register, de-register and query the Agent Manager has also been added to the API. Agents can send messages and react to both requests and response messages, letting applications interact freely as full peers. In addition one agent can interact with multiple agents concurrently, through asynchronous messaging. The API has been designed to be highly portable and easily integrable. It has been implemented using TCP/IP as the underlying network techno-
logy and released as a C library on many UNIX platforms (HP-UX, OSF/l, Ultrix. Solaris) and real-time operating systems (LynxOS, OS/9). LabView, Java and Tcl/Tk versions of the tool will be soon available. YASB has also been integrated with other development environments as explained in the following examples.
3. Examples 3. I. Automatic beam alignment at the Super-ESCA beamline The Super-ESCA beamline has been designed for high resolution core level spectroscopy using soft X-ray synchrotron radiation. It receives the light from an undulator of the storage ring ELETTRA. The performance of the SuperESCA beamline is strongly affected by the alignment conditions i.e. all the optical components must be set to optimize flux and resolving power at the experimental station. The propagation process of the photon beam through the beamline has a complex structure. Many optimization schemes can be applied under the assumption of the existence of a mathematical model of the process [4]. However such a model may be too complex, it may not be precise nor even exist. Soft Computing methodologies such as neural networks, genetic algorithms. and fuzzy sets theory have been applied to a broad class of such real-world problems. We have implemented an adaptive controller which optimizes the beam alignment at the Super-ESCA beamline by using a behavioural model based on the fuzzy logic [S]. The system determines the position of some optical components which maximize the flux of photons at the photo-diode. The system architecture couples an AI and a real-time sub-system as parallel, cooperating components. The Intelligent Control Agent was developed using FuzzyCLIPS’ which can deal with exact, fuzzy, and combined reasoning, allowing fuzzy and normal terms to be freely mixed in the rules and facts of the knowledgebased system. The expert system shell was integrated with YASB. The knowledge-based system can thus control variables of the beamline equipment; moreover fuzzy inferences can be triggered by beamline equipment variable changes. The system is now under test and its behaviour is satisfactory. 3.2. The ELETTRA beamline control Kvstem The Beamline Control System (BCS) provides supervision and control of the beamline equipment: it has the
’ FuzzyCLIPS was developed by the Knowledge System Laboratory. National Research Council Canada.
developed both at the presentation level and at the process control level, even using application specific tools such as LabVIEW.
.i_- -._ _..~_ workstation DEC, HP, SUN Ultrix. OSF/l Solaris. HP-UX tmmhe
Personal Computer Window95 MacOS
4. Conclusion A development tool for multiplatform distributed systems has been designed. The middleware. which extends the basic client/server model to address application scenarios of decentralized, peer-to-peer collaborative computing. proved effective. portable and easily integrable with different application enabling environments. Further development work will concentrate on three main directions: encapsulating the API in a object-oriented framework which could be used to build extended co-ordination models; porting the tool on new operating system such as WindowsNT or QNX; release LabView. Java and TcliTk versions of the tool. We are also investigating the application area of soft computing techniques. Experimental scientists ask for more and more advanced features and intelligent control systems would be really welcome. Fig. 2. Beamline Control System distributed architecture
responsibilities to assure a “safe behaviour of the beamline” and to give the operator a uniform access to the instrumentation [6]. We are currently developing a release of the BCS based on YASB. The system presents a distributed multilayer architecture (Fig. 2). The presentation level is based mainly on UNIX graphical workstations (such as DECultrix, DEC-alpha, HP9000/7xx, SUN Spare): a synoptic interface implemented by DataViews and Motif agents enables a graphical navigation through the beamline instrumentation. The process control level is based on VME embedded systems with the Motorola 68030 processor (MVME147) and the LynxOS real-time operating system. An host equipped with a database management system and some bridge agents. plays the role of configuration, archiving and logging sub-system. From almost everywhere, beamline users can browse the beamline configuration and the logbook through a Web client. Application software can be
2 DataViews is ;L graphical V.I. Corporation.
visualization
package
developed by
Acknowledgements Special thanks are due to the staffs of the beamlines ESCA-microscopy and Super-ESCA. to Claudio Scafuri. Albert0 Steindler, Alessandro Abrami. Juray and Renata Krempasky for their support, useful suggestions, and continuous encouragement.
References Ul R.M. Alder.
Distributed coordination models for client. server computing. IEEE Computer (April lYY5). PI P. Harmon and C. Hall. Intelligent Software Systems Development (Wiley. 1993). L-11B. Selic. G. Gullekson and P.T. Ward. Real Time Ohjectoriented Modeling (Wiley. 1994). c41 M. Brown and C. Harris. Neurofuuy Adaptive Modeling and Control (Prentice-Hall, 1994). PI R. Pugliese and R. Poboni. Optimization of the synchrotron beam alignment using a .linguistic control scheme. Proc. ICALEPCS. 1995. C61 A. Abrami. F. Gagliardl. A. Galimberti and A. Savoia. The ELETTRA beamlines control system. ST S-TN-Y2.‘9. 1991.
IIe. CONTROL’DISTRIBUTED
SYSTEMS
