Integrating Automation Design Information with XML and Web Services

Integrating Automation Design Information with XML and Web Services Mika Viinikkala Tampere University of Technology, Institute of Automation and Control, P.O. Box 692, 33101 Tampere Tel. +358 3 3115 3586, Fax. +358 3 3115 2340, mika.viinikkala@tut.fi Sami Lakka Tampere University of Technology, Institute of Automation and Control, P.O. Box 692, 33101 Tampere Tel. +358 3 3115 3557, Fax. +358 3 3115 2340, sami.lakka@tut.fi Seppo Kuikka Tampere University of Technology, Institute of Automation and Control, P.O. Box 692, 33101 Tampere Tel. +358 3 3115 2335, Fax. +358 3 3115 2340, seppo.kuikka@tut.fi KEYWORDS systems integration, XML, web services, automation design ABSTRACT This paper presents results obtained when applying XML and web service technologies in systems integration in order to improve information management during an automation project. The paper is based on research made in Novel Information Integration Technologies and Models (NIITM) project by the Institute of Automation and Control (ACI) at Tampere University of Technology (TUT). Due to the large number of parties participating in the design phase of an automation project, various design, engineering, and operational systems are needed. At the moment, the means to transfer information from one system to another, so that it can be further processed, are not efficient. An integration approach, in which XML technologies are utilized for implementing systems integration is introduced in this paper. Data content of the integrated systems are defined by XML Schema instances. XML messages containing automation design information are transformed using transformation stylesheets employing a generic standard vocabulary. Thus a loosely coupled, platform independent, data content-oriented integration is enabled by XML technologies. The plausibility of XML technologies above can be further enhanced by providing support for finding and describing the message transfer services. This is accomplished with web services, which utilize in addition to SOAP (for message delivery) also UDDI (for service discovery) and WSDL (for service description). 1 INTRODUCTION The aim of automation design is to design electrification, instrumentation and automation applications. Automation design project can be divided into three phases: preliminary design, basic design, and detailed design /8/. Several interest groups co-operate during an automation design project. In many cases, the design process is carried out concurrently by several parties using possibly different design tools and information systems /5/. The large amount of representatives of different interest groups means that design tools and information systems are diverse. Therefore, communication among parties should be smooth in order to the automation design project to succeed. Various methods, which in many cases are inefficient and time consuming, are currently used to integrate automation design information. More generic approaches are needed. 2 AN INTEGRATION APPROACH Currently, links between systems that are used during automation design may exist. However, these links, if any, are often case-specific. That is, a link is particularly tailored between the two systems in question. Integration

should be more data-centric and independent of the used information systems and any implementation or platform issues /9/. In the approach presented here, novel XML and web service technologies are applied to the integration problem in order to reach a higher level of efficiency of design work during an automation project. The benefits of XML are obvious. It provides rules to construct text-based, self-descriptive documents that contain structured data. When information is transferred using these kinds of documents, worries about platform and programming environment dependency can be forgot. Non-proprietary, commonly used internet protocols such as HTTP and SOAP can be used to enable transferring information. Web service standards UDDI and WSDL facilitate message discovery and description. Particularly, XML Schema and XSLT provide more generic means to implement integration. 2.1 Importance of vocabularies An XML vocabulary is a description of XML data that is used as a medium for information exchange, often within a specific domain such as business, math, or law /2/. All vocabularies use the same basic syntax. Thus, different vocabularies can be parsed by the same parsers and other tools. This leads to a situation, in which sharing of vocabularies is possible. Shared XML vocabularies provide a way to exchange information between different organizations and computer applications. Vocabularies are implemented as XML Schema instances that describe the structure of related XML documents and constrain what they can contain. An XML Schema instance acts as an enforceable contract between senders and receivers. In addition, they save each application from the need to check whether this contract is enforced. In our approach, data contents of automation and information systems that are integrated are modeled as XML Schema instances using the W3C XML Schema language. The most important aspect is that not only system wise vocabularies are created, but also a generic vocabulary, known by various automation communities, is developed. 2.2 Transformations Conventionally, every system or application has its own vocabulary. An artifact that is called X in one system might be called Y in an another system. Therefore, one vocabulary must be transformed to an another vocabulary in order to enable systems to understand each other. In our approach, transformations of XML documents are implemented using XSLT. Normally, in order to communicate with other systems a system has to know transformation rules for all other systems. In other words, at least two stylesheets must be written in order to make two systems to understand each other in both directions. A better solution for the problem of different vocabularies of systems is to specify a vocabulary that is understood by everyone. In our approach, a generic vocabulary is created. Therefore, a system that is to be integrated must only know how information is transformed from the system s own vocabulary to the generic vocabulary and vice versa, as described in figure 1 /9/. Generic, domain specific vocabularies have been developed in various application domains. In automation domain, IEC 61499 standard, which is discussed later, provides models and terms for purposes of automation design /6/.

Figure 1. Transformation process trough the generic vocabulary. 2.3 Web service implementation Different methods of implementations and architectures to accomplish functionalities such as sending and transforming messages exist. In the next chapter, a case study, in which messages are sent directly from a sender to receivers, is described. The case is expanded on an another kind of architecture and implementation, in which messages are sent through a service that acts as a mediator between a sender and receivers. In our approach the service, that mediates and possibly modifies messages, is implemented using a modern software component model and web services. According to W3C definition, a web service is a software system identified by URI, whose interfaces are defined and described by XML. Service s definition can be discovered by other systems and these systems may then interact with the web service using XML based messages conveyed by internet protocols /3/. Figure 2 describes a general web service architecture that is conformant with the definition. A service provider defines a service description using the WSDL and a concrete service is created from the service description. The service description is published to a registry such as UDDI. A service requestor uses a registry to locate a service description and from that service description selects and uses a concrete implementation of the service /4/. Figure 2. Web service architecture.

3 A CASE STUDY ALMA System, provided by ALMA Software /1/, is used for plant information management in plant design projects as well as in operating plants. metsodna is an automation system provided by Metso Automation /7/. From the perspective of the case study, the ALMA system is used to perform preliminary and basic design of an automation project in which the metsodna automation system is employed as an automation platform. 3.1 A prototype developed for integration A Software prototype was developed during the case study. The prototype enables information and automation systems to communicate, so that design information can be transferred. Messages processed by the prototype are XML documents that contain configuration data for an automation system. It was specified that the prototype should be as generic as possible, that is, the data content should be generic and several platforms should be supported. The developed prototype was named NIITM-Explorer. With the prototype, it is possible to send and receive messages from one system to another i.e. to transfer data in both directions. Send and receive operations include validation of messages and transformation of messages from each system specific vocabulary to the generic vocabulary or vice versa. In figure 3, the high level architecture of the prototype, as well as responsibilities of each part of it, are described. The prototype software is installed with every system that is integrated. The nature of communication between peers is synchronous. Messages are sent with a point-to-point approach without any centralized data storage between peers. The prototype does not perform database operations, that is, the actual writing to and reading from a system is performed by an extension that must be implemented for the system in question. Systems can be dynamically removed from and added to the scope of integration, because peers are independent from each other. Three XML Schema instances were designed and written: the company wise schemas and the generic schema /9/. UML was used as a modeling language during the schema design process. Therefore, an XML Schema instance was modeled as a class diagram. The generic vocabulary, derived from the IEC 61499 standard, consists of function block networks that may be either sub applications or function blocks. Function blocks may further be either basic function blocks or composite function blocks. A function block network has connections, an interface list, and an identification structure. The generic vocabulary was written by applying the application part of the standard. /9/ Figure 3. High level architecture of the prototype.

3.2 A web service solution The case study continued with developing a generic web service solution by applying the approach that is described in this paper. The web service solution acts as a centralized mediator for messages. Implementation of business logic is based on EJB component model. The web service solution is a software framework that can be configured to perform various operations, such as transformations and validations, for the transferred messages. Services provided by the framework are found from UDDI and described by WSDL documents. After receiving a message from a message sender, the service modifies the message, depending on service s handling logic. Normally a message is transformed to generic format so that it can be easily further processed. A message belongs to a project, that is, messages are sent to a project not directly to the final recipients. Project members belong to a project. In order to get the newest messages from a service, project members can query messages that are sent to a project. A thin client was implemented by using JSP. It can be used to send and query messages from a service and to configure services and its projects. The service was tested with ALMA and metsodna: automation design information was successfully transferred between these systems. /4/ 4 FINDINGS A small extract from a message, conformant with the metsodna vocabulary is given below. <AutoInfoFunction> <Attributes> <Attribute name="identifier" value="c:d1"/> <Attribute name="description" value="pid"/> <Attribute name="sp1op" value="1"/> The structure of Attribute-elements and their name and value attributes is generic: In the XML Schema instance used to validate this extract, there is a declaration in which elements called Attribute are allowed and they have to have attributes named name and value. As to integration, a better option would be to name an element or attribute according to the value of the nameattribute. In that case, the value of the new element or attribute would be the value of the value-attribute. However, the number of Attribute-elements is large. Therefore, it is tedious to write a transformation stylesheet that would take all possible name-value pairs into account. Furthermore, new attributes of autoinfo functions are created all the time and the old ones may be modified. Therefore, defining data content of a system is a compromise between two issues: 1. How generic the schema should be? 2. How descriptive the schema should be? An extensive transformation is hardly possible by using only one static transformation stylesheet to transform a message from one vocabulary to another. As a result, a message having a structure that is somehow generic is acceptable when only validation of messages is needed. However, as soon as transformations from one vocabulary to other vocabularies are needed, the generic structure of a message is not acceptable. When applying transformation rules to a message, the content of that message should be known and completely described by an XML Schema instance. Another challenge related to transformations is the fact that the mapping between subsets of data contents usually is not a bijection. That is, a source vocabulary may contain elements that do not have analogous elements in a target vocabulary or an element from source vocabulary may have many analogous elements in a target vocabulary. In NIITM-Explorer, information is stored directly in the databases of the integrated systems. That is, maintenance of a heavy data bank server containing all information is avoided. Furthermore, performance issues can be better handled. Clearly, advantages are gained when information is de-centralized. Designed decentralized software architecture answers better questions related to reliability, robustness and data security. On the other hand, centralized architecture of the web service solution raises questions such as who administers and owns the service and data that it contains.

The biggest benefit of XML and web services is that by using these technologies, integration can be accomplished independently of platform, programming language, and component model. Thus, heterogeneous systems and environments can be integrated in order to make communication between systems more automated and less onerous. A major challenge related to use of web services was security. Implementing secure web services was not possible at the time when the study was made. Issues such as concurrency or versioning were not considered. A user has the responsibility for checking whether the received message contains the newest data so that it can be updated into the database of a system. Furthermore, version management of XML schema instances and transformation stylesheets were not considered in this study. A fundamental characteristic for transformations was that they were not performed directly from one system to another system within the integration. Moreover, there will not become a situation in which all systems would use the same designations for the same artifacts. Therefore, it is most reasonable to develop application domain specific or branch wise vocabularies that are generic. 5 SUMMARY XML and web services based approach to systems integration in automation domain was presented. A case study that proceeded according to the approach was also described. It is found that XML technologies seem to be a part of the right solution. However, some issues related to schema design and transformations are problematic. If complex systems are integrated, XML technologies are not considered sufficient alone. Web service technologies facilitate a wider usage potential for message transfer services on heterogeneous platforms (.NET, J2EE). Service oriented architectures will also improve service usability. The closer relationship with web services and semantic web (with RDF and automation domain specific ontologies) will further increase possibilities for intelligent message transfer in the future. REFERENCES 1. ALMA Software: ALMA Manual, versions 7.3 and 7.4, ALMA Software, www.almasoftware.com (9.10.2002) 2. Birbeck M. et al.: Professional XML, Wrox Press Ltd. Birmingham, UK, 2 nd edition, 2001. 3. Booth D. et al.: Web Services Architecture, W3C Working Draft, http://www.w3.org/tr/ws-arch/, 2003. 4. Hakala M.: Integration of automation and information systems using web service, Master of Science Thesis. Tampere university of Technology, Institute of Automation and Control, Tampere, Finland, 2002. (in Finnish) 5. Halmetoja J.: 2000. Using structured document models in automation engineering, Master of Science Thesis. Tampere University of Technology, Automation Department, Tampere, Finland, 2000. (in Finnish) 6. IEC 61499: Function blocks for industrial-process measurement and control systems - Voting draft, Part 1 Architecture, IEC, Technical Committee No. 65, Working group 6, 2000. 7. Metso Automation: metsodna Manuals, collection 2000 En V.2, Metso Automation, http://www.metso. com/automation/home.nsf/fr?readform (9.10.2002). 8. SAS (Suomen Automaatioseura Ry): Laatu Automaatiossa Parhaat Käytännöt, Saarijärven Offset Oy, Saarijärvi, Finland, 2001. (in Finnish) 9. Viinikkala M.: Integration of automation design information using XML technologies, Master of Science Thesis. Tampere University of Technology, Institute of Automation and Control, Tampere, Finland, 2002.