12th DAAAM INTERNATIONAL SYMPOSIUM
"Intelligent Manufacturing & Automation: Focus on Precision Engineering "
24-27th October 2001
XML based Manufacturing Data Exchange
Kittl, B. & Baumann, C.
Abstract: Using different EDP applications for manufacturing control in a heterogeneous systems landscape requires high-performance, platform-independent and easy to implement communication mechanisms. This paper describes a mechanism developed on the basis of TCP/IP, HTTP and XML and optimized to meet shop-floor communication requirements.
Keywords: XML, TCP/IP, HTTP, distributed systems
1. INTRODUCTION
During the past years both Ethernet and TCP/IP have developed into standard communication technologies in manufacturing. This crucial step has solved many interface problems between shop-floor applications and machine and systems control. As a next step based on this development, the integration of shop-floor applications is to be facilitated and improved further by using the widely accepted standard technologies of HTTP and XML (Bray et al., 2000), which have proven effective for Internet and intranet applications over many years.
2. PROBLEM STATEMENT
Computer integrated manufacturing (CIM) is to enable the integration of all EDP applications and business management software directly or indirectly involved in the manufacturing process and its preparation. In this context, the main challenges are data integration and the seamless incorporation of diverse functionalities into lean business processes tailored to the individual company's needs. In the field of business management software, these requirements have led to the development of parameterizable integrated standard software. These powerful applications claim to unite all required functionalities in a single EDP application. However, apart from tending to get very complex and difficult to implement, these systems force users to obtain all necessary functionalities from the same supplyer rather than composing a customized system from the most suitable applications supplied by different software manufacturers. Due to these drawbacks, a trend reversal has already set in: in the near future, major software manufacturers will shift their focus towards developing lean basic systems and enabling the simple integration of extra functionalities provided by specialized manufacturers. This development is essentially founded on the concepts for open, distributed systems that only emerged in recent years. In manufacturing, however, comprehensive systems could not be developed due to the wide variety of functionalities and their substantial differences depending on the individual user's requirements (Angerer & Stopper, 2000). Hence this field is still characterized by a multitude of separate applications that are very difficult to integrate into an overall system.
The need to fulfill specific requirements as economically as possible has prompted the development of different system components, essentially resulting in a highly heterogeneous systems landscape: a plethora of different EDP components which hampers the development of a simple, horizontal communication structure. Consequently there is a need for standardized mechanisms enabling data exchange between the components of distributed systems - universal mechanisms that are geared to the heterogeneous nature of the systems landscape. Accordingly, the development described in this paper focused on providing a service for data exchange between components and automated manufacturing. This service developed is based on the open standard XML (Extensible Mark-up Language) and enables communication between different applications run on a local computer or on system components distributed in a network.
3. THE MDX communication mechanism
Based on the concept of using HTTP and XML to exchange data between different shop-floor applications, the MDX (Manufacturing Data Exchange) communication mechanism was developed at the Institute of Production Engineering of the Vienna University of Technology in association with partner companies. Without influencing existing communication links, the MDX specification covers all shop-floor communication needs known to date. What is more, its structure is sufficiently open to enable the unproblematic integration of additional requirements without influencing existing communication links.
The MDX specification is subdivided into three distinct areas:
Specific communication functionalities defined at the application level allow for bi-directional data exchange between distributed applications. These functionalities are integrated into the existing applications and enable exchange with neighboring systems of all data objects relevant for the shop-floor (jobs/ operations, machines, tools).
A communication protocol based on standardized TCP/IP socket technology and containing elements of HTTP is used to ensure communication between the distributed applications at the network level.
To respond to the need for bi-directional communication without polling, the following approach was taken: by placing a PUT request, a "provider" system that makes available data can transfer information to the partner system, or "user". Independently of this process, the user system may obtain data from the provider by placing a GET request. This allows for event-driven communication while at the same time offering an opportunity to synchronize several systems.
However, since a strict distinction between user and provider systems is hardly possible at the shop floor, a system may also fulfill both functions simultaneously. For example, a tool machine provides machine data while at the same time using tool data (master data, setup data). Similarly, the shop control system is both a provider of tool data and a user of machine data. If another system is integrated (e.g. visualization), the shop control system becomes the provider of machine data for all tool machines, etc. In order to enable this kind of bi-directional communication, systems that integrate the provider and user need to implement one HTTP server and one HTTP client for each. The contents and format of the relevant data to be transferred must be specified. Data format definition is based on the standardized XML technology.
4. Advantages of using MDX
In general terms, the advantages of using HTTP and XML can be summarized as follows:
· HTTP and XML can be used right away in an existing TCP/IP network. This also implies that communication between shop-floor applications is not only possible within the LAN (e.g. at field level) but, if necessary, also immediately in the WAN (Internet, VPN).
· The HTTP and XML specifications are freely available, i.e. applications communicating with these technologies do not constitute proprietary specialized solutions.
· HTTP and XML are available for all (standard) hardware and OS platforms.
As regards application development, MDX presents the following advantages:
· Software libraries, test programs etc. are available for almost every system platform, which significantly facilitates development and testing while at the same time improving on the reuse of self-developed software modules.
· The standards HTTP and XML considerably simplify the separate development of modules (e.g. by different manufacturers). Once the type of data to be exchanged has been specified, the individual modules that will ultimately be linked can be developed in almost complete independence, and the need for integration tests is brought down to a minimum.
By consequence, the installation time required for new shop-floor applications coupled with HTTP an XML can be reduced quite substantially.
MDX also brings far-reaching simplifications for routine operations and system expansions. For example, integrating a new application that requires expanded data from another system is possible without any modifications to third systems.
Moreover, using HTTP and XML also significantly improves database connectivity, given that one and the same communication mechanism is used for data transfer between manufacturing applications and for communication with (XML-enabled) databases. Currently, two different database solutions are known in the market: firstly, there are "native XML databases" that store XML data in specific internal data structures, which has proven particularly advantageous in handling changing data structures. Alternatively, existing relational databases can be "XML-enabled" by add-in programs, in which case the data available in XML format is stored in the form of linked tables.
5. MDX application example
Subsequent to the definition of MDX a prototype system was developed, implemented and tested. As a next step, the experiences and conclusions thus gathered were applied to the specification, serving as the basis for setting up and installing a genuine system. Additionally, the MDX functions were encapsulated in COM (Component Object Model) calls (Comella-Dorda, 2001). In the Microsoft environment, services offered by the interface can thus be addressed comfortably via Active-X components.
The specific task at hand consisted in linking the cell control system of an NC machine tool to a shop control system. The jobs scheduled for the machine tool and all required resources are managed autonomously by the cell control system. This data, in turn, is provided by a comprehensive shop control system. Progress messages and status changes regarding the resources managed by the cell control system must equally be reported to the shop control system.
The following data must be exchanged between the coupled systems:
· Tool data (master data, setup data and tool status data)
· Job data (master data, operation plans, completion status)
· Machine-related information (messages, alarms
· NC programs are transferred in both directions.
Implementing the new solution for a leading worldwide manufacturer of injection molding equipment showed the practical advantages of using MDX. These are best illustrated by the following examples:
· The installation time could be reduced to approximately one day, i.e. linking the cell control system to the shop control system only required a brief shutdown. This advantage, in addition to lower personnel expenses for software developers, led to a further substantial reduction in costs.
· Additional requirements identified by the time the system was operational (- i.e. a necessary expansion of the range of data transmitted -) could be smoothly incorporated in the specification and implemented in the respective subsystems without any interference in the existing communication.
6. CONCLUSION
After introducing HTTP and XML for the purpose of communication, the next step should logically consist in establishing SOAP (Simple Object Access Protocol) as a standard protocol in manufacturing. SOAP (Gudgin et al., 2001) is equally based on HTTP and XML and defines a method for exchanging information between two systems. In essence, this means that applications can provide different functionalities that can subsequently be invoked by the partner systems directly via SOAP. This will further reduce the development and installation times of communication modules while rendering communication mechanisms more flexible. Consequently, implementing the MDX specification on SOAP is considered the next task.
7. REFERENCES
Angerer, B. & Stopper, M. (2000). An Automatic Streaming Service (ASS) for Open Data Exchange in Factory Automation Systems Using XML, Proceedings of the 4th IEEE Internation INES Conference, ISBN 961-6303-23-6, Portoroz, September 2000
Bray, T.; Paoli, J.; Sperberg-McQueen, C.M. & Maler, E. (2000). Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000, Available from: http://www.w3.org/TR/REC-xml
Comella-Dorda, S. (2001). Component Object Model (COM), DCOM, and Related Capabilities, Available from: http://www.sei.cmu.edu/str/descriptions/com.html
Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P. & Berners-Lee, T. (1999). Hypertext Transfer Protocol -- HTTP/1.1, Available from: http://www.w3.org/Protocols/rfc2616/rfc2616.html
Gudgin, M.; Hadley, M.; Moreau, J. & Frystyk, H. (2001). SOAP Version 1.2, World Wide Web Consortium (W3C) Technical Report, Available from: http://www.w3.org/TR/soap12/
Authors: Dr. Burkhard Kittl, Dr. Christian Baumann, E-mail: kittl@mail.ift.tuwien.ac.at, baumann@mail.ift.tuwien.ac.at
both: Institute for Production Engineering, Vienna University of Technology, Karlsplatz 13 / 311, A-1040 Wien
Phone: 0043 1 58801 31101, Fax: 0043 1 58801 31199