INTEGRATING AUTOMATION DESIGN INFORMATION WITH XML
Mika Viinikkala, Seppo Kuikka Institute of Automation and Control, Tampere University of Technology, P.O. Box 692, 33101 Tampere, Finland Email:
[email protected],
[email protected]
Keywords:
Systems integration, XML, automation design
Abstract:
This paper presents results obtained 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 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 system, so that it can be further processed or reused, are not efficient. An integration approach in which XML technologies are utilized for implementing systems integration is introduced. Data content of systems are defined by XML Schema instances. XML messages containing automation design information are transformed using transformation stylesheets employing a generic standard vocabulary. Loosely coupled, platform independent, data content-oriented integration is enabled by XML technologies. A case study that proceeds according to the approach is 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 alone are not sufficient.
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. (SAS, 2001) 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. 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. (Viinikkala, 2002)
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. In the approach presented here, novel XML 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. 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. (Birbeck et al., 2001) 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. Generic, domain specific vocabularies have been developed in various application domains. In automation domain, IEC 61499 standard (IEC 61499, 2000), which is discussed later, provides models and terms for purposes of automation design.
Figure 1: Transformation process trough the generic vocabulary.
3
A CASE STUDY
ALMA System, provided by ALMA Software (ALMA Software, 2000), 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 (Metso Automation, 2000). 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. 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. (Viinikkala, 2002) The developed prototype was named as 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 2, 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 (Viinikkala, 2002). Three XML Schema instances were designed and written: the company wise schemas and the generic schema (Viinikkala, 2002). 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 (Viinikkala, 2002). The generic vocabulary was written by applying the application part of the standard.
4
FINDINGS
A small extract from a message conformant with the metsoDNA vocabulary is given below.
Figure 2: High level architecture of the prototype.
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 name-attribute. In that case, the value of the new element or attribute would be the value of the value-attribute. However, the number of Attributeelements 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. Yet another source of complexity is obtained if databases of systems are very different. That is, one system may use a relational database and the other system may use an object database. Structures of vocabularies derived from data bases may differ significantly from each other so that writing transformation stylesheets becomes complex. 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. 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. 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 branchwise vocabularies that are generic.
REFERENCES ALMA Software, 2000. ALMA Manual, versions 7.3 and 7.4. ALMA Software, www.almasoftware.com (9.10.2002) Birbeck, M. et al. 2001. Professional XML. Wrox Press Ltd. Birmingham, UK, 2nd edition. Halmetoja, J., 2000. Using structured document models in automation engineering, Master of Science Thesis. Tampere University of Technology, Automation Department. Tampere, Finland. (Finnish) IEC 61499. 2000. Function blocks for industrial-process measurement and control systems - Voting draft, Part 1 – Architecture. IEC, Technical Committee No. 65, Working group 6. Metso Automation, 2000. metsoDNA Manuals, collection 2000 En V.2. MetsoAutomation, http://www.metso. com/automation/home.nsf/FR?ReadForm (9.10.2002). SAS (Suomen Automaatioseura Ry), 2001. Laatu Automaatiossa – Parhaat Käytännöt. Saarijärven Offset Oy. Saarijärvi, Finland. (Finnish) Viinikkala, M., 2002. Integration of automation design information using XML technologies, Master of Science Thesis. Tampere University of Technology, Institute of Automation and Control. Tampere, Finland.
