A JAVA TM-BASED FRAMEWORK FOR DISTRIBUTED SUPERVISION AND CONTROL OF INDUSTRIAL PROCESSES Martí, P.1 , Aguado, J. C. 1 , Rolando, F. 2 , Velasco M. 3 , Colomar, J. 3 , Fuertes, J.M. 1 (1) Automatic Control Dept., FNB, Universitat Politècnica de Catalunya. C/ Pau Gargallo 5, 08028 Barcelona, SPAIN. T: 3493 4017917, F: 3493 4017045 Email: {pmarti,jaguado,pepf}@esaii.upc.es
(2) Dip. Automatica e Informatica, Politecnico di Torino, C. Duca degli Abruzzi 24, 10123 Torin, ITALY. T: 3493 401 1690 Fax: 3493 401 7045 Email:
[email protected] (3) Facultat de Nàutica de Barcelona, Universitat Politècnica de Catalunya. Pl/ Palau 28, 08003 Barcelona, SPAIN. T: 3493 4017917, F: 3493 4017910 Email: {mvelasco,jcolomar}@bec.fnb.upc.es
Authors are members of the DINBARCO group, (Distributed Internet-Based Remote Control) within the LEA-SICA (European Associate Laboratory of Intelligent Systems for Automatic Control).
Abstract. This paper provides an image of an ongoing research, within a field that is continually evolving, the distributed control of processes. The objective of this project is to remotely, or even locally, supervise and control an industrial process, providing a framework to integrate the process and its control system in the Internet. This framework will provide, by using objected oriented methodologies, general patterns to implement communication needs and to represent virtual industrial processes, which will be mapped to the real world, and its control. As a result, the control and monitoring of any industrial process will be attainable with independence of its physical location, as expected from a client-server architecture. This framework will be based on Java, which is becoming an emerging technology in the Internet as well as in the industrial field.
1.
INTRODUCTION
Two strong tendencies are presently characterizing the industrial automation field. First, the increasing utilization of flexible and powerful distributed systems, and second, the expanding role of Internet and Intranets as communication backbones. There are indeed some drawbacks, the main of them being the excessive delay that a remote Internet connection nowadays implies. In spite of this problem, we can say that process supervision and punctual control actions can nevertheless be adequately performed by means of existing communication networks and technologies, no matter how distant the plant can be. This possibility, mainly when it can be the only chance of minimally controlling a remote process, makes worthy to explore the Internet-based control. A few attempts have been done in order to combine these two tendencies, but past implementations were only specific solutions for a particular application, and it is highly desirable to try to plan a more general approach. The goal of this paper is to present a general methodology to accomplish a remote distributed supervision and control via Internet, as in Fig. 1.
(Internet) Client
Virtual Plant
Real Plant Figure 1. Project general scheme In a first stage of the project, different communication ways have been analyzed [4][9] so as to achieve the capability to perform remote supervision and control actions. Of course, it has to be clearly stated that, because of the Internet present characteristics, control actions have to be considered as linked to special events and not continuous in time. Nevertheless, it is important to provide a model that foresees the possibility of this particular communication. As a second step, a brand new architecture has been created to virtually model industrial plants, by means of object oriented methodologies, and with the objective of either remotely or locally supervise and control these plants. By following a client-server philosophy [1], the necessary structures have been devised to represent a virtual plant, which is to be either partially or totally reflected in the client entity. The third part of the project studies, as in [13], the mechanisms able to provide the communication and
information exchange between a real and a virtual plant. Every possible real process should be considered in order to build a global interface able to deal with whatever industrial process it could came across. Anyway, in spite of having clearly divided the project into three subtopics, some implementation decisions have to be taken by considering the overall operation and goals. The structure of the paper is as follows. Section number two remarks the motivation and objectives of the project. The third section presents its development, and is divided into three subsections explaining the necessities and available implementations, the communication choice and the architecture of the virtual plant. Section number fourth illustrates the operation of the system, and finally the fifth one draws some conclusions from the development of this ongoing project, and points out some directions for future research.
3.
DEVELOPMENT
In the early stages of the project, a preliminary study was made so as to determine which available technologies and methods would better suit our purposes. At that time, it was specially important to take into account all the necessary requirements of a remote modeling, supervision and control system of industrial processes. The next step mainly consisted in the design and implementation of the communication scheme, upon which the virtual plant was to be built. By the nature of the project, the communication was always intended to go from the client (whether remote or local) to the virtual plant in the plant server, and then to the real one. The final part, which is still in process, comprised the design and implementation of a virtual plant in order to test the feasibility and true performance of the global project. Let us see then, these stages one by one. 3.1 Preliminary study
2.
MOTIVATION AND OBJECTIVES
The motivation of the problem is twofold. On the one hand, it is aimed at finding a global solution that brings together the above-mentioned main tendencies in industrial automation, distributed control and Internet. On the other hand, a practical application of the final product is pursued. It is well known that many commercial distributed systems employ proprietary architectures, and there is an undeniable lack of standardization in the field of communication protocols. Our first goal, then, its to set industrial plants free from their physical reality, components and relationships among them, by means of virtual plants, as in [8]. That way, an abstracter representation will be created, making thus possible the remote control and supervision of any piece of industrial equipment, integrated in our system with independence of their manufacturer and communication software. Those virtual plants will be worldwide accessible by means of the Internet and the TCP/IP (Transfer Control Protocol/Internet Protocol). The second objective of the project is the application of the developed architecture, in order to provide both the industrial and academic worlds with a software tool that grants the wider access to the supervision and control of industrial plants. From an economic point of view, among their biggest advantages will be the capability of easily and economically integrating very different and remote pieces of equipment. From a learning reality, one possibility is the training in automatic control of remote plants, as can be illustrated by [5] and [16].
As it was commented before, the first question was to determine the requirements of an environment aimed to modeling, supervising and controlling industrial processes. From a general point of view, any of such systems should assure, among others, the following characteristics: § § § § § § § §
Flexibility, scalability and reusability. Enabling the communication among the different plant components. Allowing remote accesses and executions. Providing a graphic and user-friendly interface. Supplying communication with another existent software and firmware. Granting on-line modifications Being platform-independent and presenting the minimum environment cost. Offering a communication interface through Internet.
The first conclusion from these requirements is the necessity of employing an object-oriented methodology [6][7]. That way, the environment is by definition flexible, scalable and reusable, meanwhile the modeling each component of the plant as an object assures their intercommunication just by invoking their methods. Once the general approach was chosen, the next aspect was the particular object-oriented language and its developing environment. The core of the whole project was the remote communication via Internet, and also an open interaction with another software and firmware. Two solutions appeared fulfilling those requirements, namely JavaTM and CORBA [12]. The advantages of JavaTM, included, besides the possibility of programming the virtual plant, on the one
hand the Internet communication by means of the API RMI (Remote Method Invocation) [15] (see Fig. 2). On the other hand, it allowed by using JNI (JavaTM Native Interface) the needed interaction with different software and firmware. Java Object
Java Object
RMI – Interface Client ( Stub)
Java Object
Java Object
RMI – Interface Server (Skeleton)
RPM (TCP/IP) Figure 2: JavaTM communication environment CORBA stands for Common Object Request Broker Architecture. This platform permits remote and local interaction among processes written in different programming languages [12], thus solving both the communication through Internet (see Fig. 3) and the collaboration with other software and firmware. On the other hand, it was clear that by choosing this solution, the problem of selecting a programming language for the implementation of the project was merely postponed.
Java Object
C++ Object
... Object
C++ Object
... Object
Interface (IDL)
Interface (IDL)
ORB - Client (Stub)
ORB Server (Skeleton) IIOP (TCP/IP)
Figure 3: CORBA communication environment Both platforms, according to their documentation, presented very similar characteristics, but in order to determine their true performance, a communication test was implemented. This experience tried not only these high- level solutions, but also included the low level implementation of Sockets, in order to assess the delays induced by these more general architectures. A JavaTM remote object, performing a very simple operation, was created on the server machine. The operation was simple in order not to affect significantly the communication time, which is the one we wanted to compare. It is not that significant in this context to describe all the experimental details of the test. We just think it is worth to point out how the values found do not have an objective significance when considered alone, but are interesting to compare the technologies between them. The actual numerical values would change significantly
by using different machines, networks, or operating systems, but the proportion between them is expected not to vary too much. With client and server executed on different machines of the same type, running the same operating system and the same JavaTM Virtual Machine, the times were calculated as the average value between 5000 invocations.
SOCKETS
RMI
CORBA
1.65 ms
3.8 ms
4.65 ms
Talking about a distributed control environment, these timing results are important whenever we have to execute operations requiring a repeated invocation of the same method in the same object. If we consider executing a simple punctual operation, the timing results stop being that significant. In this case we can identify a set-up time during which the object is remotely identified, instantiated and initialized, before the client can actually invoke a method. The set-up time is certainly much longer than the time of a single invocation. In this case the results we found do not have a noticeable importance. The realization with Sockets was actually the simplest one. It is important to consider that the service implemented for testing purposes was quite simple. The task of writing code, using Sockets, able to run the communication between a client and a server, offering several methods, accepting numerous parameters with different data type can be quite a challenging work. Also the speed, which is certainly a strength point of the implementation with Sockets, can be significantly affected by the way the communication protocol is implemented. A heavy messaging scheme could bring to quite different results from those we obtained in this simple case. RMI shows anyway quite a good performance. The new implementation of this technology adds important features that have been for years a privilege of CORBA developers. Some of them are: the persistence of an object reference (thus, the possibility to reconnect to an object after a system crash), the support for remote object activation (the client can reactivate an object that has been downloaded from the server who needed resources for other objects), support for custom socket type (that RMI can use for remote calls) and other improvements that for instance brought to a significant performance improvement between the releases 1.1 and 1.2 [9]. Another significant advantage of RMI involves the security: the Security Manager available with RMI helps the developers to protect the local resources from code that could damage them and, in general, allows the programmer to implement quite a complete security system [8]. CORBA has the advantage of being a deeply tested solution for distributed computing. In addition, the
support for most major programming languages, at the moment, makes of it probably the better choice in case the developers are faced to the need of using many existing code sources in non-JavaTM languages. Nevertheless, CORBA is a heavier technology, compared to RMI, to build an independent and easy to use communication platform. JavaTM was chosen as the programming environment because that way the user would only need a web browser –including the Java virtual machine- to remotely access any plant. Anyway, both technologies are involved in the process of approaching the long sought real-time operation as can be seen in [2] and [3]. 3.2 Communication scheme After selecting JavaTM as the design platform, the next task was the definition of a communication scheme (see Fig. 4) Server
Client Application Java
Server Application Java JNI/CORBA Virtual Plant Server Interface RMI
RMP over TCP/IP
One crucial point is the connection between the real and the virtual plants, by means of the plant controller. It is so because the access to the real variables can exceedingly increase the demanded time and resources for the communication process. There are several possible solutions. The simplest and zero-cost way is found when the plant controller can be coded in JavaTM, thus granting direct access and communication.
Client
Clients Interface RMI
It is important to remark that this communication architecture permits the existence of several virtual plants, either corresponding to real ones or not. On the other hand, one of the goals of the project was its operation with a minimum number of resources. According to that philosophy, the server machine only needs to include the JavaTM virtual machine, a web browser if local control is desired, and a small server HTTP, usually coded in Java. It is not necessary to offer the regular capabilities of a web server, and it can run without any commercial software. The client machine only needs to run a web browser including the JavaTM virtual machine.
Plant Controller Java
Plant Controller Non- Java
Real Plant
BUS
Figure 4: Communication Scheme An industrial plant is assumed to be always connected to a plant controller (usually but not necessary, by means of a fieldbus). If that controller is written in JavaTM, the communication to the virtual plant in the can be straightforward. Nevertheless, the most common case implies a controller coded in any other programming language, and the necessity to communicate with processes in Java via JNI, CORBA or some other solutions. Anyway, this plant controller interacts with the server plant application, always coded in JavaTM and modeling the virtual plant. This application, which will be further described within the next section, allows both the communication with the plant controller and a number of clients, by means of the application interface RMI.
On the other hand, when an existent software perform the plant control, it is necessary to integrate the software libraries and drivers by means of JNI or CORBA to enable the communication. But the situation can be worst if the controller does not provide these drivers and libraries, and a specific solution has to be found (OPC, DDE, ...) 3.3 Security It is basic to address the security issues [11], both from the point of view of Java-provided capabilities, and from the perspective of the programmed application. The growing potentialities of the JavaTM language and the fast development of network communications have recently risen the interest about the security of the Java platform. The aim is to have at our disposal a secure platform where Java-enabled applications can run. The platform (JDK, Java Development Kit) also provides tools and services (written in JavaTM in order to be system independent) to adjust the security of platform and applications [13]. Since the access to the resources is anyway mediated by the Virtual Machine, a class called Security-Manager can restrict the actions that non-trusted code is allowed to performed. The security-Manager class is then customizable so that the developer can actually build a security policy suiting the application. On the other hand, to customize this class can be quite a challenging work, requiring deep knowledge of computer security. The Java platform originally offered a single security scheme, know as sandbox model. Within this model, local code was completely trusted and had access to all
the resources, while downloaded code (applets) had access only to a few limited resources, in order to prevent dangerous operations. An evolution of this original security model was introduced by the signed applets. In this new model, the downloadable code can contain a digital signature. If the digital signature key is “trusted” by the receiver (that is supposed to have an archive of trusted signature keys), then the code is treated exactly as if it was local and can have access also to the critical resources. The last evolution in the security models lets the programmer customize the security policy with little effort and without real programming, by means of tools provided in the JDK. In the very last release, it is possible to extend the access control structure without having to write new specific methods. In addition, from a security point of view, there is not anymore a significant difference between local code (Java applications) and remote code (applets). Every required level of security can be defined within both of them. In the project application, firewalls are defined and every client is forced to fit in a given profile that grants reads and modification access to the value of any subset of process variables.
3.4. Virtual Plant The virtual plant structure is the key point where the whole project is based, and it comes determined by three important characteristics. In the first place, a virtual plant has to be available to represent any real industrial plant, any of its components and any inner relationship among them. In other words, generality is needed.
• •
A container can contain another or other containers, and it can be contained by another or other ones. A container can be remotely configured and can remotely supply information about its content.
The first property allows the existence of complex data structures. For instance, we could represent a kitchen as a container which includes an oven and a fridge. Those two new containers could provide, for instance, its temperature, the state of its door ... The structure would be tree-like and the corresponding leaves would always be the virtual representation of the real variables of the plant (both continuous and digital ones). The abstract representation would include every property of the included containers, but from a practical point of view, it is enough to store a tree of names, meanwhile properties associated to every name will be kept in a separate table. That way, the plant server and the client can store the same information, making possible to have client and server processes within the same machine with a minimum cost. The containers structure can be created and properly connected by means of only two primitives in the Plant Server configuration procedure. Their names are Put_New_Node and Delete_New_Node, and after their application the whole plant and any of its components have their properties available. So as to configure and access the plant, the client user is provided with a graphic interface that shows the tree structure as it is being created. The same environment also allows the users to determine the properties of any container, find out if its properties are structural or physical ones, and characterize its remote access policy (see Fig. 7)
A second important aspect is the necessity of a remote access to the plant. This implies, on the one hand, that the remote client must know how to get to the plant and its elements in order to construct its own partial o complete image of the virtual plant. On the other hand, its is necessary to assure the perfect correspondence between any reference to the plant or its components in the client and the plant or its elements in the server. Finally, this virtual plant is designed in order to continuously interact with its real environment. This means that any configuration or change must be dynamic and allowed in execution time.
Figure 7. Plant definition
The chosen structure for the representation of the virtual plant is very simple. Maybe the main feature of an industrial plant is the capability of recursively include other plants, and that property can be represented by a structure of “containers”. Thus, a container will be the basic unit of a virtual plant, and it will present two important treats:
There are a couple of properties worthy of being remarked as specially important. The first one is the real location of the variable, which will completely determine the way it could be accessed. This property can collect, for instance, an address within a data acquisition card, or in a fieldbus, or even in Internet (IP address).
A second important characteristic is the one stored below the name of task, which collects a code of actuation when a given event occurs. For instance, it could express the necessary alarm when the high temperature limit of a fridge is trespassed. Every plant property can be remotely modifiable, and that implies the possibility of altering the global behavior. Obviously, not any user will be granted these modification rights, but every client will be assigned a given profile. This profile will rule not only the action the user can perform, but also the information he or she will have accessible. According to this property, different users will get a different structure of the plant, and only top authorized ones will see the global architecture. The implementation of containers in JavaTM is accomplished by means of an object derived from the available HashTable structure. Its methods have been properly modified in order to enable their remote accessibility, that is the possibility of reading and writing its values from any terminal. Each container includes four methods: The first one, Get, returns the contents of any container, thus allowing the instantiation of the next level containers from the received list of names. When this action is performed on a physical variable container, the result is its present value. Of course, the application of this method will be recursive in order to instance every element composing the plant. The second method, Set, permits to add up, both remotely and locally, new containers to the current one, and, of course, fix the value of real variables. This method, altogether with the two that will follow, allows the complete configuration of a virtual plant. The third one, Get_properties, simply returns a list of pairs of property names and its correspondent values. Finally, the method Set_properties is designed to alter existing properties, by specifying their names and their desired new value. It is clear that every authorized user is given the possibility of accessing and modifying both the structural properties and the physical values of the plant, by means of the above explained methods, and the access can be either remote or local.
4 OPERATION The real operation, as shown in Fig. 8, can distinguish three logical entities (not necessarily physical ones), clients, plant servers and an object server.
Object Server (5) (3)
(4) (2) (7)
(1) (9)
Client
Plant Server
(6) (8) Figure 8: Operating structure
Real Plant
Observing the Figure 8, it is possible to understand how the whole controlling system is designed. Let us analyze each element. We are going to proceed backwards, from the plant to the clients, because the requirements for every single component of the system are implied in this direction. Let us remember first that we will consider a very general scheme where the situation is basically the most complicated we want to be able to treat. In many cases the situation will be easier than the one we show, with less elements and with some of the processes running on the same host. 4.1 Operation of the Plant Servers. The Plant Servers (PS) are the entities where the control and supervision processes are executed. Since we are trying to project a generic control system, independent from the actual plant to control, it is not possible to give detailed specifications. The Plant Servers execute the software able to communicate directly with the real plant through the appropriate interfaces (connection to a fieldbus, to a SCADA, etc). Depending on the plant we may need one or more actual devices performing this role. Plant Server Server Service
Server Service
JNI/CORBA Server Service
Figure 9. Services to the plant We can describe a single Plant Server (figure 9) as a device able to execute one or more processes, providing the services needed to control and supervise the plant. We will call Server Service (SS) each one of these services. Just to make an example we can consider a software process able to communicate, through the field-bus, to the plant, accomplishing the basic task of switching the plant off. The Switch_off service is a SS executed on one PS. This is a simple example of a control SS. Let us consider then a software process able to communicate to the plant and retrieve a value measured by a sensor on the plant, for example a temperature. This is a supervision SS.
A PS can execute many SS, on the other hand it can happen that some particular constraints about timing, interactions between SS, bus positioning, etc, can impose a specific relative location between different SS acting on the same plant. Both PS and SS can be executed on different platforms, such as personal computers, workstations, custom devices, etc. It is not possible to decide at this point the requirements for a machine executing specific Server Services. The SS has certainly to be developed closely integrated with the real plant and, from that point of view, the resources will be sized to it. Depending on the plant, we might need very powerful computing resources or, in some other case a simple device can be enough. In different contexts, we may have the SS process either as a part of Plant Server application (both written in Java, probably by the same developers), or a part of stand-alone application written in whatever language. Anyway there has to be communication between the SS and the PS application. This is evident in case they belong to the same application, but it has to be provided in case they are two different processes. Depending on the language of the interacting entities we can use different techniques. RMI can be used in case of Java applications, JNI or CORBA can be the solutions in case the SS are written in a different language. 4.2 Operation of the clients. The most general case is when there are more than one client, and they are placed remotely and connected to the Object Server through a TCP/IP network. Local clients and single client are simpler possibilities, which are included in the general case. The requirements for a client are basically simple: it has to be a device able to browse the Internet through a Java 2 compliant browser. At the moment, this requirement means that we will be using a generic computer running one of the most common operating system (Windows, MacOS, Unix, Linux, …) supporting the most used browsers and plug ins (Netscape, InternetExplorer, Opera, HotJava). On the other hand, the market is now beginning to offer new possibilities. New devices able to browse the net are appearing, such as mobile telephones, set top boxes to be connected to a TV, fixed telephones with extended features, etc. 4.3 Operation of the Object Server. This component has a crucial but simple role in the system. Its main task is to operate as an interface between the Clients and the Plant Servers. An HTTP server is running on the Object Server (OS), in order to send to the clients all the information about the plant to be controlled (web pages) and the services offered by the system. One or more applets are available in this server so that the clients can download and execute them to carry out the actual supervision and control. RMI allows a client to execute a method on the server and offers a simple application called rmiregistry that provides a naming service. In other words, a service
offered by the rmiregistry is used by the servers to register the names of the methods they offer. The rmiregistry takes track of the methods’ names and offers than another service that can be invoked by the clients to identify the methods. The client has to make a request to the rmiregistry in order to have access to the remote method. RMI imposes a limit that can cause problems in a context like the one we are dealing with. The limit is that the rmiregistry has to run on the same host as the server processes. This limitation would imply that the client has to know the network addresses of all the Plant Servers before being able to invoke the methods (SS) that they offer. This would limit seriously the possibility to add new services or to move and change the old ones. For this reason we implemented a Java application called Registry Agent (RA), accomplishing a crucial task. The idea is that the we want the clients being aware only of the network address of the OS, but we want them to be allowed to use the services offered by all the Plant Servers. The Object Server executes the rmiregistry and executes the RA. Each Plant Server communicates with the RA using RMI, but acting as a client in this context. The SS are then registered in the central rmiregistry by the RA. The clients also communicate with the RA to retrieve the information about the SS available in the system. After this phase, the client can invoke the methods communicating directly with the plant server, without using the Object Sever. The requirements for the Object Server are really quite simple at the moment. We need to execute an HTTP server, the rmiregistry and the Registry Agent. Implementations of the rmiregistry are offered for all the major operating systems, and this application requires really few resources. The HTTP server and the agent are written in Java and since there is no need for the server to offer all the features of a normal web server, it is not necessary to use any commercial software (which would be anyway not desirable in this case). The requirements then collapse into one: the Object Server environment must be able to execute a Java application, that is, it has to be equipped with a Java Virtual Machine. We want to stress how the role of the Object Server is important but not heavy. This is a very useful characteristic, because this entity can be a critical one in case it breaks. The clients are multiples, the Plant Servers can be multiples and the Server Services can be moved between them, but the Object Server has to work properly. It is good to have a small, cheap and easy to substitute device in such a crucial position. 4.4 The operation step by step Now let us get to the stages of the operation (see again Fig. 8). In the first place, the Plant Server registers the plant and every of its elements (step 1), using the RA running in the Object Server, in order to make them
accessible to the clients. From that moment on, a client can contact the Object Server –or any other machine, if different from its own, where the appropriate web page is maintained- (step 2) by means of a web browser. Then, the client gets an applet that enables it for the control of any plant (step 3). Beyond this point, any new container (element of the plant) that the client wants to access, has to be first “ordered” to the Object Server (steps 4 and 5) to make it accessible for the client. After that, the client can access the element (first instantiation) (step 6) and get it (step7), obtaining a new tree or the corresponding leaves. This means that any further access to the same container performing regular operations would be direct between the client and Plant Server (steps 8 and 9). The RMI technology always imposes a certain time offset or delay in the remote object re-creation. Fortunately, it only happens in the instantiation, meanwhile Internet completely determines the response times when in the regular operation. This remote representation of a plant can be addressed from two different points of view: •
•
A first possibility is obtaining the structure of the first element, and then performing the remote instantiation of every found object. After that, the process is repeated and the tree-like structure is completely explored level by level (in width). The advantage of this approach are the availability of every element in execution time without any delay. Of course the main drawback is the accumulated delay when the connection is first established, which can be really important. A complementary solution creates instances of the elements only when the users needs them. Obviously this policy implies a fast first access to interesting variables, but a little delay whenever the crucial structures have not been instantiated yet.
In this project, the possibility of choosing one or the other approach remains, and it is the user who, before accessing the plant for the first time, should specify the desired policy. Once the virtual plant has been configured within the client, the Object Server no longer appears in the communication scheme. From now on, every supervision or modification performed in the client is automatically performed on the real plant via the Plant Server.
5 CONCLUSIONS The main objective of the project was the design and implementation of a software architecture that grants distributed supervision and control of industrial plants via Internet.
Lately, different technologies have appeared in the market allowing that operation. Some of them are being tested, and some already operate without any difficulty but, as far as we know, all of them are not more than specific solutions to a given problem. Our contribution then, takes profit from two main forces in the industrial control field, the wide-spread usage of Internet and the improvements in computer networking capabilities, which have started to permit real distributed control. But our proposal is different from the others mainly in two aspects, trying to fight the still persistent lack of standardization in the industrial control. On the one hand, it completely relies in JavaTM, and only on it, taking advantage of the RMI extension, its present and its promising future capabilities. On the other hand, the JavaTM classes are employed to achieve a representation general enough to model unknown industrial plants without any code recompilation effort. This is the presentation of an ongoing research project, and there are some topics on security and consistency that are still under study, but the communication bases have been set and successfully tested. At the present, continued experiments are taken place in order to fully implement this architecture and try to achieve an operation as close to real time as possible, provided the application needs it and the technology allows it.
REFERENCES [1] Aldrich J., Dooley J., Mandelsohn S., Rifkin A., (1998) “Providing Easier Access to Remote Objects in Client-Server Systems”, Proc. of the 31st Hawaii International Conf. on System Sciences, vol. 7, pp. 366-375. [2] Carnahan L., Ruark M. (1999) “Requirements For Real-time Extensions. For the JavaTM Platform”. NIST. (http://www.sdct.itl.nist.gov/~carnahan/real-time/intro.html)
[3] Currey, Jon (1999) “Real-Time CORBA”. Highlander Communications. (http://www.real-time.org/presentations/ rt-corba/RTCorba_RTAS99/screens.html) [4] Curtis D. (1997) “Java, RMI and CORBA” a white paper by the Dir. Platform Technology Object Management Group. (http://www.omg.org/library/wpjava.html) [5] Deponte J., Muller H., Pietrek G., Schlosser S., Stoltefuss B. (1997) “Design and Implementation of a System for Multimedial Distributed Teaching and Scientific Conferences”, Proc. International Conf. on Virtual Systems and Multimedia, pp156165.
[6] Dollimore,J. (1997) “Object-based Distributed Systems” Draft material for 3rd edition of Distributed Systems – Concepts and Design. DCS, University of London. [7] Guijun W., Ungar L., Klawitter D. (1998) “A Framework Supporting Component Assembly for Distributed Systems ”, Enterprise Distributed Object Computing Workshop, 1998. Proceedings, pp. 136-146. [8] Lumpp T., Gruhler G., Kuchlin W. (1998) “Virtual Java Devices. Integration of Fieldbus Based Systems in the Internet”, IECON’98. Proc. of the 24th Annual Conf. of the IEEE Ind. Electronics Society, Vol. 1, pp. 176-181. [9] Medeiros D. J., Watson E. F., Carson J. S. and Manivannan M. S. (1998) “Distributed Simulation Modelling: a comparison of HLA, CORBA, AND RMI”, Proceedings of the 1998 Winter Simulation Conference. [10] Net.Re@ction (1999) “On-line Reactor Simulator Service”. (http://www.icetact.tcd.ie/netreaction/pagemain.html)
[11] Opto 22. (1999) “Opto 22’s Internet I/O Live Demo”. (http://www.internetio.com) [12] Orfali R., Harkey D. (1998) “Client/Server Programming with Java and CORBA” Second Edition. John Wiley & Sons, Inc., New York. [13] Reiter H., Kral C. (1997) “Interaction between JavaTM and LonWorks R“ 1997 IEEE International Workshop on Factory Communication Systems, pp. 335-340. [14] Rusty E.(1997) “Java Network Programming” O'Reilly. UPC code: 1400265285. [15] Sutherland D. (1997) “RMI and JAVA TM Distributed Computing”, JavaSoft TM, A Business Unit of Sun Microsystems, Inc. (http://www.javasoft.com/features/1997/nov/rmi.html)
[16] VCLab (1999) Virtual Control (http://www.esr.ruhrunibochum.de/VCLab/main.html)
Lab
2.1.
