8th DAAAM INTERNATIONAL SYMPOSIUM

University of Zagreb, ICCU Dubrovnik, Croatia

22-25th October 1997

DISTRIBUTED INFORMATION EXCHANGE IN PRODUCTION ENVIRONMENTS

Baumann, Christian

Abstract: The use of Internet technologies within company internal networks („Intranets") is becoming more and more important today. Due to limitations to the Internet technologies Intranets can not be used at all levels of companies information systems (i.e. in technical/industrial surroundings). This article describes a project, which is presently running at the Institute of Production Technology (TU Vienna). The goal of the project is the development of a new architecture of communication so that Intranets can be used to fulfill the special demands of production environments.

Key words: Intranet, Internet, Industrial communication.

1. INTRODUCTION

There is a noticeable increasing demand for quick-reacting, agile production systems among small and medium-sized (SME) companies. This demand can only be partially covered by traditional planning and control methods because the internal system's flow of information is too sluggish and unflexible. The use of Internet technology within the companies („Intranet") appears to offer a solution to the problem, however, currently available Internet technology, especially in the area of online processing of data, the (quasi-) interactivity with the user and the communication which is still asynchronous, are still not able to entirely fulfill the demands of Intranet. The development of new concepts (Multi-Client/Multi-Server, synchronous communication on the Intranet) and the practical application of such concepts through the development of appropriate software tools is essential to this area.

2. STATUS QUO

Upon observing the currently used extent of the Intranet's Web technology it is apparent that it is mainly employed to distribute information onto users. This means that the major use is the presentation of data, either low dynamic or a lesser dynamic (e.g. calling up data bases). Only a small percentage of the real interactive system is used in practice; i.e. applications which use platform independent interfaces based on Web-Technologies. The existing Internet protocols are rarely used to inter-communicate between applications (except for the standard uses such as FTP, EMail, etc.) This is especially true for applications that are employed in production companies like production planning and control, scheduling, simulation, control of the flow of materials, tool and resource management, visualisation, logging, etc. Hardware components such as fieldbus-systems, sensor-actor-busses, programmable logical controls and DNC-networks that find use in the field of industrial environment can only be integrated into the Intranet at a very rudimentary level (if at all) today. The currently available technology is suitable for many applications, however, for other areas of utilisation it is much too limited. This is due to the fact that the original demands were much less than those that are emerging today. The following applications are solvable through the employment of today's existing technology using the Intranet.

• All applications that have a limited demand on the dynamics of information or show no need for synchronous communication.
• Applications in which simple user interfaces are sufficient or those that are not truly interactive.
• Integration of the most common data base systems usually with proprietary interfaces.

The question, in which areas the limitations lie and which starting bases for solutions result i.e. which elements must be expanded upon, can only be answered once the new demands have been defined.

3. LIMITATIONS OF CURRENT TECHNOLOGIES

The limitations that are faced when employing the Intranet in technical/industrial surroundings through the existing Internet/Web technology can be summarised as follows:

• The level of the interactivity with the user is too limited. Efficient user interface cannot be implemented through Web applications.
• The data exchange with the protocol HTTP is asynchronous. The client is responsible for fetching the data in this form of communication. Traditional technology (e.g. polling) cause an unjustifiably high burden on the system. Arising events (e.g. changes in data) can only be transmitted further to the client via detours.
• Systems designed to exchange high dynamic information are not able to be implemented. For this purpose the overhead created by HTTP, CGI and HTML is too large.
• The exchange of arising data from distributed places to distributed receivers is too complicated. The client-server model is too inflexible for this purpose or is too strictly interpreted by the existing technology.
• Interfaces for „foreign systems" are, if the really exist, incompatible. This obstructs an integration of various systems within the Intranet. This limitation is especially true in technical/industrial surroundings.

4. GOAL OF THE PROJECT

The goal of this project is to overcome the limitations that are described in the previous section. The new concepts have to use the existing technologyas a starting base. The systems that are to be developed should not replace the existing Internet technology but complete it and expand it. The scope of this project should include the background work that needs to be performed in order to form a basis for the development of the communication tool (definition of appropriate architecture of communication, development of protocol). This tool, which is adjustable according to need, should make possible the communication between the diverse EDP applications of producing companies such as product planning and control systems, electronic leitstands and production and machine data acquisition systems. The first step should be to define general requirements from the standpoint of the applications that should be connected and their requirement to communicate such as:

• Type and definition of data objects that are to be transferred.
• Services that the tools of communication should offer (creation, update, deletion, etc. of data objects).
• Error-processing.

In order to build upon these specifications, an appropriate architecture of communication needs to be designed and a protocol needs to be formulated. Outcomes of this step in the project is a prototype for a communication tool that should link different software modules. Subsequently, interfaces should be constructed and tested for the connection of other foreign products in the form of prototypes.

4.1 Architecture of Communication

Integral component of the total concept is the definition and development of a new architecture of communication („D.I.E."- Distributed-Information-Exchange) that meets the following demands:

• The definition of DIE builds onto the existing architecture of the Inter-/Intranet, respectively the WWW. This architecture should be expanded and not replaced.
• Numerous communication connections must be able to be established parallel without being hindered. e.g. DIE-links, Intranet, Web and proprietary applications based on TCP/IP as well as connections based on other network protocols.
• The construction of a Multi-Client/Multi-Server system must be possible. This means that information must be stored for retrieval as close as possible to the place of origin by appropriate „small" and independent server units. The data will be directly distributed on one or more partner applications.
• Parallel to this, the possibility must still be at hand to process the data in the „classical" Client-Server model (less „big" server, data saved from numerous sources).
• The possibility for a synchronous exchange of data must be at hand which means that a server must be able to initiate the communication with the client itself.
• The definition of events that trigger the transmission of data must be possible. Thereby, priority mechanisms must be taken into consideration i.e. certain applications receive date before others.
• The efficient transmission of high and extremely high dynamic data must be possible, thereby, unnecessary overhead must not emerge.
• The architecture should be especially tailored to fit the technical specifications of LANs i.e. to use their advantages (bandwidth, ...) over WANs.

4.2 Protocol

In order to actualise the new architecture of communication the development of a transmission protocol („D.I.E.P."-Distributed-Information-Exchange-Protocol) is needed which specifications follow:

• DIEP serves to secured synchronous exchange of user data within the architecture of a Multi-Client/Multi-Server environment.
• In addition, DIEP is used to exchange information about the status of participating communication partners.
• The way in which DIEP functions is similar to that of the HTTP protocol, however, with two fundamental expansions. First, communication can be initiated by the client as well as the server. Second, we plan to introduce a mechanism in the protocol itself which would make it possible to save a given state of communication.
• The DIE-protocol is based on TCP/IP. It is located in the layer 5 (application level) of the TCP/IP protocol-suite, this is comparable to the FTP protocol as well as Telnet or HTTP.
• DIEP uses the more dependable TCP protocol of the transport layer (layer 4) in order to transport application data. The UDP protocol can be used if needed to exchange status information, broadcast data, etc.

4.3 Interface

Interface specifications must be constructed in order to connect foreign systems. In order to be especially cautious of the connection of technical/industrial applications, one must make sure that the following points are fulfilled: In regard to software, the interfaces must cover the widest range possible, e.g.: Interfaces to local and distributed databases, operating system specific interfaces (OLE, DDE, ...), OS independent interfaces (Corba), mailer-interfaces, interfaces using binary or textfiles, etc. The same is true for hardware. Interfaces must be planned for the most common components used in job shops, for example Fieldbus systems, Sensor-actor busses, Serial devices, ... In order to make the employment of interfaces as flexible as possible, the interfaces must be configurable in wide ranges.

5. CONCLUSION

The new communication architecture D.I.E. - based on existing Internet technologies - allows the use of Intranets even for the complex demands of industrial communication systems in production environments. At the current state of the project the architecture and the protocol are defined and prototype applications have been established by the author. The experiments made on this prototype system positively verify the theory of the concept as well as the practical usability.

6. REFERENCES

Baumann, C. (1996): Intranets- Unternehmensinterne Informations- und Kommunikationssysteme, Proceedings of the 7th DAAAM Symposium, Katalinic, B. (Ed.), pp. 25-27.,Vienna, Oct. 96.

NCSA (1996): CGI - Common Gateway Interface, http://hoohoo.ncsa.uiuc.edu/cgi/overview.html

Nielsen H.F.; Gettys J. (1997). HTTP - Hypertext Transfer Protocol, http://www.w3.org/pub/WWW/Protocols/

Object Management Group Inc. (1996). The Common Object Request Broker:Architecture and Specification, http://www.infosys.tuwien.ac.at/Research/Corba/docu.html

Washburn, K.; Evans, J. (1994). TCP/IP: Aufbau und Betrieb eines TCP/IP-Netzes, Addison-Wesley

AUTHOR