12

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 3, NO. 1, FEBRUARY 2007

Adaptive Internet Integration of Field Bus Systems

Stephan Eberle
AbstractField buses are used to network sensors, actuators, and control devices inside automation systems. The Internet integration of eld bus systems enables information from these devices to be exchanged across enterprises and businesses. An essential prerequisite to this aim is the interoperability of eld bus systems with external systems and applications. Therefore, many efforts are made to establish a common information exchange standard which all eld bus systems are supposed to support. However, the longer these efforts are ongoing the less it seems that they will ever yield the expected breakthrough. The present paper introduces an substantially different approach to interoperability. Field bus systems may keep their individual application interfaces and data exchange formats. All the same, external infrastructures do not have to be redesigned to match the specic needs of certain eld bus systems. Rather, eld bus systems become capable of adapting the information exchange exibly according to the needs of the outside environment. Index TermsCommunication standards, eld buses, information systems, Internet.

I. INTRODUCTION

T THE END of the last century, microelectronics has led to major advances in the eld of industrial automation. Since the beginning of this century, another technology is making inroads into industrial plants and automated devices: the Internet. This enables entirely new forms of communication and allows the world of industrial automation to get seamlessly integrated with the world of information technology. Information from plants, machines, and devices can be accessed either corporate wide or worldwide. Production lines become linked with business departments of a company, which ensures a more efcient and cost-effective production and a higher quality [1][4]. Remote diagnostics and maintenance allow customer support staff to gain important insights when equipment and machinery are in trouble or break down, and enable a faster and more effective support [5], [6]. Up until now, eld buses have been the primary means of communication in industrial automation. They have been specifically designed to network sensors, actuators, and control units. That way, they are well suited for data exchange within automation systems but they offer very limited support for integrating automation systems consistently into the environments where they are used. Nevertheless, eld buses cannot simply be replaced by the Internet, because Internet-based networks lack

some features which are crucial to industrial automation such as real-time, or safety. Consequently, only a combination of both, namely an integration of eld buses into the Internet, can yield the added value of worldwide connectivity to automation systems. Currently, a great variety of such solutions are being developed and made available. However, unlike the Internet, eld buses are mostly based on manufacturer-specic protocols. Not surprisingly, the gateways and interfaces which are offered for connecting eld buses to a corporate intranet or the public Internet also turn out to be quite different and are most of the time incompatible. In the end, it may be possible to access eld bus systems from remote departments or locations. But usually, each of them can only be operated by a tool environment designed specically for it and not with an alternative product from a competitor. The reverse is also true, as it is practically impossible to reuse a given software tool for different kinds of eld bus systems. Put simply, there is a lack of interoperability between eld bus systems and devices on the one hand, and tool infrastructures, on the other hand [1]. This complicates the global information exchange with eld bus systems considerably, and curtailsor even jeopardizesthe protability of such solutions. This paper introduces a new approach towards eliminating such kind of interoperability problems of eld bus solutions. In contrast to other attempts, the method presented here is based on a signicantly different paradigm: It shall no longer be the duty of the user to know which kind of eld bus system he is dealing with or to conform strictly to certain eld bus interfaces. Rather, the technologyi.e., the eld bus systemmust be so designed that it can adapt itself exibly and transparently to the users tool environment. The objective is to create an adaptive information exchange allowing eld bus systems and tools of any kind, or from any manufacturer, to interact appropriatelyat close range, as well as from a distance. The following section introduces a crucial prerequisite for interoperability which is the ability to exchange information. Section III explains why the interoperability of eld buses and tools has been so difcult to achieve up to now. An alternative approach, namely the adaptive information exchange, is introduced in Section IV. Sections VVII describe how this idea can be realized using eXtensible Markup Language (XML) technologies. Finally, the Section VIII summarizes the most important experiences gathered during practical proving. II. EXCHANGING INFORMATION WITH FIELD BUS SYSTEMS Field buses are primarily used to network control units, actuators, sensors and other devices in the eld area of automation systems. During normal operation, measured variables, control variables, and status information are communicated. The data exchange is repeated cyclically and is expected to be highly

Manuscript received November 4, 2005; revised May 1, 2006; accepted December 4, 2006. Paper no. TII-05-11-0062.R1. The author was with the Institute of Industrial Automation and Software Engineering, Department of Electrical Engineering and Information Technology, University of Stuttgart, Stuttgart, BW 70569, Germany. He is now with Robert Bosch GmbH, Stuttgart, BW 70469, Germany (e-mail: stephan.eberle@de.bosch.com). Digital Object Identier 10.1109/TII.2006.890525

1551-3203/$25.00 2007 IEEE

EBERLE: ADAPTIVE INTERNET INTEGRATION OF FIELD BUS SYSTEMS

13

efcient so that the real-time requirements of the control application can be met. This kind of communication in eld bus systems is named data-oriented communication [7]. In addition, eld buses support users in conveniently commissioning, handling, and maintaining automation systems. Process variables and status information can be captured, calibration parameters queried and modied, and programs downloaded and started. Such means are essential for conguring, operating, monitoring and diagnosing the devices connected to a eld bus. Any data exchange which takes place in this context is named message-oriented communication [7]. In general, it is initiated only sporadically and doesnt need to come up to high expectations of real-time. Instead, the focus lies on the convenience and capacity of the underlying communication functions so that the eld bus system can be accessed as easily as possible. This second form of eld bus communication involves that users are provided with appropriate software tools. These tools need to be able to retrieve the information requested by a user from a eld bus system and to forward any information issued by the user right there. Most eld bus tools run on desktop computers, but they are increasingly made available on mobile platforms such as laptop computers, handheld PCs, or smart phones as well. The connection to eld bus systems is established via a simple serial link, a local or wireless network, the telephone line, or the Internet. Given a single eld bus system and a matching eld bus tool, the scenario just described works ne. However, serious problems arise as soon as a proper interaction of several different eld bus systems and tools is required. In order to get to the bottom of this kind of interoperability problem, we need to have a closer look at the basic principles behind the interplay of eld bus systems and tools.

Fig. 1. Representation, communication, and interpretation.

B. Duality of Information An important fact in this regard is the duality of information [9]. On the one hand, information is something which is neither made of matter nor of energy. It cannot be reduced to any other axiom and is not measurable [10]. Information itself is abstract and represents a non-physical phenomenon. On the other hand information can be issued, transmitted, stored and perceived. Therefore, it must be bound to some physical carrier, i.e., it must be represented with the help of some material or energy-based structure [11]. Such a representation of information is called a message. Both aspects of information follow certain schemes. Messages are composed of sequences of symbols or elements. The set of possible symbols and elements which may appear in a given message, as well as the structures they are allowed to take, are determined by its syntax [12]. In the case of eld bus systems, the syntax means the frame formats used in eld bus messages. They are dened by the underlying application layer. Information deals with objects that exist in the real world and the relationships between these objects [11]. The entire range of possible objects and relationships is called semantics. At the same time, the semantics constitutes the possible range of meanings which may be assigned to messages [12]. In the context of eld bus systems, the semantics corresponds to the communication services as well as the variables, parameters, and functions which can be accessed through these services. Again, both are subject to the eld bus application layer. The duality of information has signicant consequences to the process of information exchange. Within the full procedure of transferring information from a sender to a receiver, communication makes up only a part of it. At rst, the information on the sender side has to be mapped to a message, i.e., a sequence of signs (bytes). This is called the representation. Then, a communication takes place moving the message from the sender to the receiver. Finally, having arrived there, the information contained in the message must be retrieved. This requires an interpretation. Fig. 1 demonstrates the whole procedure, taking as an example a situation where the control variable of an actuator in a eld bus system has to be updated by a given value. The eld bus tool represents a corresponding instruction by a message which is composed of ve hexadecimal bytes. This message is communicated to the eld bus system. The eld bus system interprets the message, invokes an appropriate service implemented in its application layer, and passes the new control value as a parameter.

A. The Notion of Communication An obvious basis for describing any kind of interaction between two different systems is the notion of communication. In the context of eld bus systems, the ISO/OSI Reference Model (Open Systems Interconnection) provides a widely accepted and detailed understanding of this term [8]. It constitutes a common architecture model for communication among computational systems and denes seven distinct functional layers which communicating systems have to implement. Field bus systems normally require only the layers 1 (physical layer), 2 (data link layer), and 7 (application layer) [7]. The other layers are either not needed at all or partially only. In the last case the relevant functions are merged into the implementation of layer 7. Essentially, the ISO/OSI reference model deals with the transmission of messages carrying data and the technical details required for this process such as physical media, addressing schemes, error detection and correction methods, or communication services provided to the application. However, while covering most if not all important aspects of communication, the role of information is not clearly stated. But the interaction of eld bus systems and tools depends primarily on their ability to exchange information. Though often stated differently, this means much more than a mere transfer of messages or data.

14

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 3, NO. 1, FEBRUARY 2007

C. Subjectivity of Information Aside from the two layers of information we have seen so far, there is still a third one which is called pragmatics. In the eld of information technology, this term is usually just mentioned and shortly explained but it seems to be of no particular signicance [10], [12]. Pragmatics is rather known as a matter of linguistics. It is the study of the ability to use language effectively to fulll intentions and goals. When people want to invite, give compliments, give warnings, show their emotions, tell lies, or make commitments they never use the same language. Rather, they choose their language in a way which they nd the most appropriate to achieve the intended result. Consequently, language can never be considered as a neutral instrument. It is very much formed by the intentions and goals for which it is being used. In other words, language is a function of what speakers would like to happen. Of course, the effect of pragmatics on languages has no direct inuence on information exchange with eld bus systems. Nevertheless, there are interesting parallels between language and information. On the one hand, we could say that the kind of information users need to access in eld bus systems is basically always the same. They want to read or write variables and parameters of eld devices, download software updates, or invoke specic programs or functions. One the other hand, we have to consider that these users come from different industrial sectors such as chemicals and process industry, manufacturing industry, building automation, automotive industry, or device automation. Within these sectors, people belong to different business units and departments. This means that information exchange with eld bus systems takes place in highly varying contexts and users have different technical backgrounds. On top of that, there are different sorts of stakeholders who pursue specic strategic interests. The most common example is the permanent conict between eld bus manufacturers and users [7]. Manufacturers normally tend to include specic features in their products in order to protect themselves against the competition on the market, whereas users clearly prefer standardized products so that products from different manufacturers can be exchanged without affecting the automation system in which they are used. Ultimately, we can see that there is no common type of eld bus user but many distinct user groups. Each user group has specic expertise and experiences, proper strategic interests, and individual preferences. Altogether, these parameters can be considered as point of view from which a eld bus system is regarded and constitute the pragmatics of the respective user group. The differences between the underlying points of view entail that eld bus related variables, parameters, and functions are perceived, abstracted, structured, and named in quite different ways. The kinds of information which user groups intend to exchange with eld bus systems are the direct result of this process and therefore may vary considerably from case to case. Just like language, information is no neutral value. Rather, it is always the product of the point of view of a certain user group and consequently represents a subjective asset. Not surprisingly, the subjectivity of information plays a notable role in the process of information exchange. At least two information-processing parties are involved. These parties may

Fig. 2. Communication and information models.

belong to different user groups and therefore may rely upon individual points of view. Again, this is illustrated by Fig. 1. The information on the side of the eld bus tool is an instruction whose terms reveal a problem-oriented point of view, namely it originates from the conceptual domain of control engineering. However, the resulting information on the eld bus system side is based on a solution-oriented point of view, i.e., it is an executable call of a eld bus service. D. A Denition of Information Exchange After having considered the nature of information, we can clearly see that information exchange means slightly more than just communication. Communication refers to the transmission of messages from a sender to a receiver whereas information exchange implies the added capability of producing and understanding message contents. Due to the duality of information, the full procedure of information exchange also covers the transition from information to message (representation) before communication can take place, as well as the transition from message back to information (interpretation) thereafter. Because of the subjectivity of information, the interpretation on the receiver side cannot be considered as a simple reversal of the representation at the sender. Rather, both may follow their own rules depending on the underlying points of view. A complete description of information exchange requires an appropriate set of models which cover both communication-related as well as information-related aspects. As communication is a neutral process it can be dened based on a common communication model for sender and receiver. However, representation and interpretation are driven by each sides point of view and therefore require individual information models (see Fig. 2). Keeping these ideas in mind, we can now reconsider the ISO/OSI Reference Model [8] and investigate at which extent it is suitable or not for describing information exchange. The details of communication are sufciently covered by its rst presentation layer). The part of six layers (physical layer relevance to information is the seventh layer (application layer) (see Fig. 3). It denes the structure and the meaning of messages being exchanged between sender and receiver. In other words, this layer denes the syntax and the semantics to be supported by both sides. Hence the ISO/OSI Reference Model comprises both a communication model and an information model. It deals with the transmission of messages as well as the transition between messages and information and covers a major characteristic of information exchange. Nevertheless, the ISO/OSI Reference provides only a single information model which is related to sender and receiver. It imposes xed rules of representation and interpretation on both sides. Consequently,

EBERLE: ADAPTIVE INTERNET INTEGRATION OF FIELD BUS SYSTEMS

15

Fig. 3. Information exchange according to the ISO/OSI Reference Model.

Fig. 4. Information exchange in general.

the ISO/OSI Reference Model represents a special case of information exchange which is based on the implicit assumption that sender and receiver rely on the same point of view. In order to remove this restriction, the ISO/OSI Reference Model must be generalized. The result has to be an information exchange model in which communication and information models are treated as separate units (see Fig. 4). The communication model applies to sender and receiver and comprises the rst six layers of the ISO/OSI Reference Model. However, the application layer is replaced by individual information models for sender and receiver. Just as is the case with the communication model, these information models also have different layers. First comes the point of view (pragmatics) from which a system is considered. The pragmatics is the origin of the information (semantics) which a system can handle. The semantics in turn determines the messages (syntax) with which a systems information can be represented. III. STANDARDIZATION OF INFORMATION MODELS As previously stated, todays eld bus systems are based on the ISO/OSI Reference Model. The information exchange between eld bus systems and tools is therefore limited in that its application layer provides only a single information model which both sides have to use. This restriction has a deep impact on the interoperability of eld bus systems. The requirement for unlimited information exchange between different eld bus systems and tools can only be met if the same information model or application layer can be used for all eld bus systems and tools. For this reason it is not surprising that there have been and still are numerous attempts to nd a standardized eld bus application layer (MMS [13], CANopen [14], CIP [15], RACKS and NOAH [16], IEC 61158 [17], OPC [18], etc.). Sometimes, manufacturers with a dominating position on the market also

try to establish their own ideas of a common eld bus application layer as a de facto standard [19]. Although these approaches have been developed at different points in time and are based on quite different paradigms, they all have one principle in common. They endeavor to enable interoperability by imposing a standardized syntax and semantics, i.e., a common information model, to be supported by all eld bus systems and devices. Nevertheless, it is the very number of different approaches which makes it doubtful whether this objective is really reachable. Considering the approaches in some more detail, we can see that the proposals for a common information model all look quite different. Sometimes, the greatest importance is attached to the simplicity of the information model and semantics and syntax are very much generalized. Some other times, a special emphasis is placed on the convenience of the information model which requires that semantics and syntax are rather concrete and close to the problem. In yet other cases, the precision of the information model is given a top priority and the denition of semantics and syntax has to be as clear as possible. Finally, there are information models which offer similar levels of simplicity, convenience, and precision but are still not the same. The situation will become even more complicated as eld bus systems are increasingly made accessible via the Internet. It is foreseeable that this will increase the number, as well as the diversity of users dealing with eld bus information. At the same time, the differences as outlined above will increase as well and the chances of reaching a consensus on a common information model are innitely low. It becomes obvious, that even though the contrary is often claimed, there is no reason to assume that a common information model for eld bus systems will be adopted in the near future. Therefore, we can conclude that the approach of establishing a standardized eld bus application layer is by no means appropriate for achieving the interoperability of eld bus systems. Before considering alternative approaches to achieve the interoperability of eld bus solutions, it is important to explain why the numerous attempts at standardizing information models have never led to the desired result. Information models are in no way absolute. They always have their origin in the individual point of view of their inventors. This individual point of view constitutes the pragmatics of the information model and shapes its syntax and semantics. Agreements on common information models can therefore only be reached within closed user groups whose members share the same ideas or ways of thinking. But in general, the underlying expertise, experiences, strategic interests, and preferences are far too different for such an agreement. Asking for the right information model is a misleading question. It means ignoring the subjectivity of information, as well as the existence of different points of view. In order to nd a way out of these difculties, a new kind of information exchange is needed. Users must be released from the obligation to map the individual points of view to a standard information model with predened syntax and semantics. Instead, they must be entitled to create and apply custom information models whose syntax and semantics are closely related to the problem which they want to solve. Field bus systems, in

16

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 3, NO. 1, FEBRUARY 2007

Fig. 6. Conventional eld bus request message.

Fig. 5. Adaptive information exchange between a eld bus system and a eld bus tool.

it enables a comprehension between eld bus systems and tools across different information models (semantic decoupling). The outline of the idea may appear simple. Still, before proposing in which way it can be realized, we have to nd out some important details of the process of interpretation. V. INTERPRETABILITY OF FIELD BUS MESSAGES A translation dictionary is basically a rule-based reference for retrieving the information expressed by a message. It contains elements or sequences of elements which may appear in a message and indicates their meaning. However, translation dictionaries cannot be used for interpreting any kinds of messages. Their application requires that the elements in a message are clearly delimited and uniquely identiable. Up to now, messages exchanged between eld bus systems and tools mostly consist of binary encoded data. In order to see if they can be interpreted with the help of translation dictionaries or not, we have to investigate into what extent they meet the above named prerequisite. We do so by proceeding from the sample message given earlier concerning adjustments to the control variable of an actuator (see Fig. 6). Without further information, we can only say that the eld bus message consists of ve data bytes in hexadecimal notation. But it is unclear whether these bytes represent ve single message elements, or a lower number of compound message elements. Whatever the applicable composition of the message elements eventually looks like, there is still another problem. bytes constitute For example, even if we knew that the two two separate message elements we could only see that they are literally equal. But we would not be able to know whether they represent the same or different pieces of information. The rst one could be a reference to a eld device and the second the index of an operation to be executed on the same. It might also be the case that one or both of them express values to be used for adjusting some parameters of a eld device. Obviously, our sample message meets neither the condition that its elements can be clearly kept apart nor that they can be uniquely distinguished. In other words, conventional binary eld bus messages suffer from the fact that their syntax is implicit, and a dictionary-based interpretation is therefore not achievable. Things look quite different if the XML [20] is used. Even though XML originally has been designed for the Internet it has proven to be useful in industrial automation as well. Typical applications are the denition of device description languages [21], [22], and the exchange of process variables and parameters between automation systems and applications [23], [24]. Using XML for encoding eld bus messages entails that they have to be represented as text but enables their elements to be marked with user-dened tags and attributes. Fig. 7 shows in which way this affects the sample message from above. The eld bus message consists of the same data as before, but this time, we can see that it is composed of exactly four ele-

turn, must be enabled to adapt themselves to different information models so that interoperability can be maintained. IV. ADAPTIVE INFORMATION EXCHANGE Adaptive information exchange enables eld bus systems and tools based on different information models to interoperate. The information model for the eld bus tool can be selected according to the function or task to be fullled. Despite this, the eld bus system can still keep its existing information model, i.e., the application layer as dened by the eld bus manufacturer. In order to achieve this goal, the eld bus system is supposed to adapt itself exibly and transparently to the users eld bus tool. This means that the eld bus tool and its information model determine the syntax used in outgoing and incoming messages (see Fig. 5). The eld bus system must be able to understand and process incoming request messages in terms of the semantics dened by its own information model. In addition, it has to provide any resulting response messages based on the syntax of the eld bus tool rather than on its own. In adaptive information exchange, such kind of mapping between different information models is realized by using translation dictionaries. Each dictionary denes the link between the syntax of one eld bus tool and the semantics of one eld bus system. They specify which services of a given eld bus application layer are to be applied to the request messages of a certain eld bus tool as well as what the response messages are expected to look like. The creation of such translation dictionaries involves ideally only a single person who knows the information models of both sides and is able to identify their correlation. Once they are nished, translation dictionaries can be of advantage to all those persons who are acting based on the information model of a specic eld bus tool or system and do not want to or cannot take care of which one is being used on the other side. All translation dictionaries are made available at a known location on the Internet (see Fig. 5). When a request message from some eld bus tool arrives at the eld bus system, the dictionary which matches the syntax of that message and the semantics of the eld bus system is downloaded and applied. This enables the request message to be fully processed and an appropriate response message to be sent back to the eld bus tool. The Internet proves useful on two counts here. On the one hand, it helps to realize what has been the initial idea of this paper, i.e., it grants access to eld bus systems using eld bus tools at distant locations (spatial decoupling). On the other hand,

EBERLE: ADAPTIVE INTERNET INTEGRATION OF FIELD BUS SYSTEMS

17

Fig. 7. XML-based eld bus request message.

Fig. 8. XML-based eld bus response message.

ments. The rst three are delimited through the name, number, and operation attributes while the last one is encompassed by and the channel tag. We can pinpoint that the number operation attributes are not equal and therefore must have different meanings. In addition, there is a root tag named request which includes a namespace declaration. This namespace is shared by all tags and attributes in the message and thus identies the underlying syntax. Once all data of the sample message has been marked with tags and attributes as shown, the conditions that its elements must be clearly delimited and uniquely identiable are both met. Generally speaking, XML-based eld bus messages yield an explicit representation of their syntax, and thereby enable themselves to be interpreted through the use of translation dictionaries. VI. TRANSLATION DICTIONARIES FOR FIELD BUS MESSAGES In adaptive information exchange with eld bus systems, translation dictionaries are used to interpret request messages with the syntax of a given eld bus tool according to the semantics of a given eld bus system. This means that translation dictionaries must transform request message elements into applicable service invocations of the eld bus application layer. They also must convert the resulting return values back into appropriate response message elements. Translation dictionaries thus have to address the following three basic tasks: analysis of the request message, processing with eld bus system services, and synthesis of the response message. As per the reasons given in the previous section, eld bus messages used in adaptive information exchange have to be XML-based. Around XML, there are many useful complementary technologies. One of them is the eXtensible Stylesheet Language Transformations (XSLT) [25]a versatile means of transforming XML documents using pattern-matching, template-based transformation rules. It constitutes an excellent starting point for creating translation dictionaries for eld bus messages. In order to see how this works in detail and what the resulting structure of translation dictionaries looks like, we carry on with the user-dened eld bus message from the previous section (see Fig. 7). As already stated, it is a request message from a eld bus tool for updating the control variable of some actuator in the eld bus system. Fig. 8 depicts the expected response message supposing that the operation can be successfully completed. The request and the response message look very much similar. Their only differences are that they use different tags in their root elements, and that the value of the channel element in the response message has been substituted for an additional status attribute.

Fig. 9. Skeleton of XSLT-based translation dictionary.

Fig. 10. XSLT transformation rule for root element of request message.

Fig. 9 shows the skeleton of an XSLT-based translation dictionary assuming that the eld bus application layer implements the Manufacturing Message Specication (MMS) [13]. The translation dictionary is embraced by the XSLT stylesheet element which lists relevant namespaces. Aside from the namespace of the XSLT elements themselves, these are the namespaces of the eld bus message elements and the eld bus application layer. Together, they identify the combination of eld bus tool syntax and eld bus system semantics which the translation dictionary is applicable to. The transformation rules of a translation dictionary are pattern-matching templates. They are represented by XSLT template elements and are placed inside the body of the XSLT stylesheet element. Each template consists of an XPath expression and a template body. The XPath expression is used for analyzing the request message. The template body species how to process the matching parts of the request message using eld bus system services, as well as how to synthesis the corresponding parts of the response message. Fig. 10 lists the transformation rule which applies to the root element of the request message. The XPath expression for analyzing the request message can be found in the match attribute of the XSLT template element and simply queries for the name of the root element. As the meaning of the root element is merely structural rather than behavioral, the transformation rule contains no processing part. The syntheses part is realized by the XSLT element element

18

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 3, NO. 1, FEBRUARY 2007

Fig. 12. Field bus/Internet gateway supporting adative information exchange.

The return value of the get-status service is exploited in the synthesis part for building the resulting fragment of the response message. Though multiple elements and attributes have to be created here, the principle is the same as for the previous transformation rule. VII. IMPLEMENTING AN XML-BASED ADAPTIVE INFORMATION EXCHANGE We can see that XML and XSLT deliver a highly suitable technological fundament to put the idea of adaptive information exchange into practice. However, we have to consider that the fact of using XML to represent eld bus messages lets them become signicantly larger than their binary encoded counterparts. Even more important is the fact that XML messages are text-based which means that they have to be parsed prior to submitting them to any further processing. In addition, the eld bus messages are not processed directly. Rather, they are interpreted using XSLT-based translation dictionaries which are again text-based XML documents. It is very much clear that these factors entail certain limitations of the real-time behavior of the information exchange. Nevertheless, the primary purpose of information exchange with eld bus systems over the Internet in general and adaptive information exchange in particular is to support users in conveniently commissioning, handling, and maintaining eld bus systems. It therefore only affects the message-oriented communication between eld bus systems and tools whereas the time-critical data-oriented communication within eld bus systems can remain unchanged. Any limitations regarding real-time can be tolerated as long as the overall responsiveness of the information exchange lies in the same order of magnitude as the reactivity of typical eld bus users. In order to enable eld bus systems to support both efcient data-oriented communication and message-oriented adaptive information exchange over the Internet, they have to be equipped with appropriate gateways. Fig. 12 shows the architecture of such an adaptive eld bus/Internet gateway. On the eld bus side, the gateway provides an appropriate communication controller which enables it to participate in the data-oriented communication inside the eld bus system. The application layer services required for the more comfortable message-oriented communication are implemented on top of it. Together, these components form a conventional eld bus interface. The Internet or more precisely WWW interface involves a

Fig. 11. XSLT transformation rule for child element of request message.

which creates the root element of the resulting response message. It further uses the XSLT apply-templates element to continue the transformation recursively, i.e., to trigger the templates which apply to the children of the root element. Fig. 11 shows the template which realizes the transformation rule for the device- and channel-element sequence of the request message. The XPath expression in the analysis part is more complex than before. It does not only match device elements which are followed by a channel element but also specically selects the device element with the given name attribute and ensures that the channel element has the given number and operation attributes. This time, the transformation rule also encompasses a processing part. It bears on the operation attribute of the request message and involves invoking the Write service in the MMSbased application layer of the eld bus system. However, these kinds of services are highly specic to the underlying eld bus system, and are not included in the standard XSLT vocabulary. But they can be made available by leveraging the extensibility features offered by some major XSLT processor implementations [26]. These XSLT processors enable libraries with user-dened functions to be registered along with a unique namespace. Inside the translation dictionary, rst the same namespace needs to be declared again. Then it can be used to identify and invoke all user-dened functions supported by the associated library. In the present example, an appropriate MMS service library has been registered with the underlying XSLT processor using the http://www.iso.org/9506/MMS namespace (see Fig. 9). Its prex fbs is used to call the Write and get-status services. At the same time, the relevant request message elementsnamely the name attribute of the device element and the number attribute of the channel elementare translated into corresponding eldbus-system-specic identiers. Along with the value of the device element, they are passed as arguments to the Write service.

EBERLE: ADAPTIVE INTERNET INTEGRATION OF FIELD BUS SYSTEMS

19

TCP/IP stack and a HTTP server. The key part of the gateway is the adaptive eld bus interface. It consists of an XML parser which analyzes incoming request messages from eld bus tools and identies their syntax. An XSLT loader takes care of locating and downloading suitable translation dictionaries. The last component is an extended XSLT processor which has been enabled to invoke services in the eld bus application layer. It is used for processing request messages based on downloaded translation dictionaries and sending the resulting response messages back to the originating eld bus tools. VIII. EXPERIENCES A. Practical Application In order to see how the approach of adaptive information exchange works out in practice and to evaluate the achievable response times it has been realized in the form of a distributed laboratory experiment. A demonstrator consisting of a Time Triggered Protocol (TTP/A)-based eld bus system and an adaptive Internet gateway has been installed in Munich, Germany [27][29]. The demonstrators task was to enable a metallic body to hover by means of an electromagnet and a light barrier. A Web-based monitoring and calibration tool was realized in Stuttgart, Germany. It used a user-dened protocol to access the TTP/A bus demonstrator. The translation dictionary required for mapping the tool-specic messages to the TTP/A application layer was deployed to a web server located in San Diego, CA. With this system, it was possible to observe and adjust the variables and parameters of the demonstrator from remote. The average response time for both reading and writing was approx. 1.2 s. As expected, this is far away from being real time but is still quite acceptable for achieving commissioning, handling and maintenance tasks. B. Security Issues A major implication of bringing eld bus systems and Internet close together is security. Though being out of the scope of this paper, it is a critical factor for the applicability of the developed techniques. Information from eld bus systems is typically related to chemical processes, production lines, or building surveillance, and is therefore highly security-sensitive. It is obvious that an exchange of such information via the Internet requires major efforts to keep it under strict access control. This involves an authentication and authorization of eld bus users as well as an encryption of the data trafc between eld bus systems and tools. Some promising approaches in this context are currently under research and could be used to complement the work presented here [30][32]. IX. CONCLUSION This paper has been focused on nding a solution to the very limited interoperability of eld bus systems and tools. However, due to the duality and subjectivity of information it is impossible to achieve this by imposing a common standard for the syntax of eld bus messages and the semantics of eld bus application layers. The proposed approach considers that users of eld bus systems and tools have individual points of view and intuitively deduce their own information models from there. The

information exchange therefore has to be carried out adaptively, i.e., eld bus systems must be able to adapt their application layer to the message formats of different eld bus tools. This is realized through the use of translation dictionaries which are made available for download on the Internet. Adaptive information exchange involves that eld bus messages are represented in XML. This is an essential prerequisite to interpreting them with the help of translation dictionaries. Translation dictionaries, in turn, must be written in XSLT. These facts may give raise to suspicion that the old standardization problem is just revealed in a different light. It is therefore important to notice that the use of XML does in no way determine the syntax of eld bus messages itself. It just denes a common way of marking their elements with tags and attributes which makes the underlying syntax explicit. XSLT has likewise little to do with specifying the semantics of eld bus application layers. It merely provides a common means of associating XML elements with meanings. Consequently, the consensus people have to come to here doesnt affect any longer the application layer of the ISO/OSI reference model. It only reaches up to the presentation layer. This still needs to be achievedbut due to the fact that the subjective nature of information remains untouched, it seems to bee signicantly less critical. Certainly, there will also be further attempts at standardizing the information models of eld bus systems themselves in order to prevent them from diverging too radically from each other. This is a thoroughly promising approachas long as these standards bear on single user groups, where common points of view exist or can be negotiated. However, when information needs to be shared across multiple user groups, differences about points of view and mismatching information models will never be avoidable. It is precisely here that adaptive information exchange comes into play. Adaptive information exchange therefore complementsbut doesnt necessarily replaceexisting approaches of standardized information exchange. ACKNOWLEDGMENT This paper is based on the authors Ph.D. dissertation, which was published in June 2005. REFERENCES
[1] A. P. Kalogeras, J. V. Gialelis, C. E. Alexakos, M. J. Georgoudakis, and S. A. Koubias, Vertical integration of enterprise industrial systems utilizing web services, IEEE Trans. Ind. Inform., vol. 2, no. 2, pp. 120128, May 2006. [2] T. Chang, P. Jaroonsiriphan, M. Bernhardt, and P. Ludden, Web-based command shaping of cobra 600 robot with a swinging load, IEEE Trans. Ind. Inform., vol. 2, no. 1, pp. 5969, Feb. 2006. [3] A. Talevski, E. Chang, and T. S. Dillon, Recongurable web service integration in the extended logistics enterprise, IEEE Trans. Ind. Inform., vol. 1, no. 2, pp. 7484, May 2005. [4] R. S. Gaonkar and N. Viswanadham, Strategic sourcing and collaborative planning in Internet-enabled supply chain networks producing multigeneration products, IEEE Trans. Autom. Sci. Eng., vol. 2, no. 1, pp. 5466, Jan. 2005. [5] R. C. Luo and J. H. Tzou, The development of an intelligent webbased rapid prototyping manufacturing system, IEEE Trans. Autom. Sci. Eng., vol. 1, no. 3, pp. 413, Jul. 2004. [6] N. Jazdi, Universelle Fernservice-Infrastruktur fr eingebettete Systeme, Ph.D. dissertation, Dept. Elect. Eng., Stuttgart Univ., Stuttgart, Germany, 2003, IAS-Forschungsberichte, no. 3. [7] B. Reienweber, Feldbusse zur industriellen Kommunikation, 2nd ed. Munich, Germany: Oldenbourg Industrieverlag, 2002.

20

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 3, NO. 1, FEBRUARY 2007

[8] Information TechnologyOpen Systems InterconnectionBasic Reference Model, ISO/IEC Std. 7498, 1994. [9] R. J. Lauber, Was it information?, in Computer Aided Design of Dynamic Systems. Sevastopol, Ukraine: Donezk State Tech. Univ., 2001, vol. 29, pp. 1835. [10] H. Zemanek, Das geistige Umfeld der Informationstechnik. Berlin/ Heidelberg, Germany: Springer-Verlag, 1992. [11] S. Wendt, Nichtphysikalische Grundlagen der Informationstechnik, Interpretierte Formalismen. Berlin, Heidelberg, Germany: Springer-Verlag, 1989. [12] L. P. Hyvrinen, Information Theory for System Engineers. Berlin, Germany: Springer-Verlag, 1970. [13] Industrial Automation SystemsManufacturing Message Specication, ISO Std. 9506, 2003. [14] CANopen Appliction Layer and Communication Prole, Draft Standard 301, V4.01, 2000 [Online]. Available: http://www.can-cia.de, CAN in Automation e.V. (CiA). [15] DeviceNet Specication, Release 2.0, , Open DeviceNet Vendor Association, 2001 [Online]. Available: http://www.odva.org. [16] M. Patz and J. Quade, Feldbusunabhngige AnwendungsschnittstellenDie Esprit-Projekte RACKS und NOAH, in Kongreband i-Net97, Wiesbaden, Germany, 1997, pp. 175183. [17] Digital Data Communications for Measurement and ControlFieldbus for Use in Industrial Control Systems, IEC Std. 61158, 2003. [18] OPC Overview Version 1.0, 1998 [Online]. Available: http://www.opcfoundation.org, OPC Foundation, White Paper. [19] PROFInetArchitecture Description and Specication, Version 2.01, 2003 [Online]. Available: http://www.probus.com, PROFIBUS International. [20] Extensible Markup Language (XML) 1.0 (Third Edition), , 2004 [Online]. Available: http://www.w3c.org/TR/2004/REC-xml-20040204, World Wide Web Consortium, W3C Recommendation. [21] M. Wollschlger, XML-Beschreibungen als Basis fr WWW-basierte Managementlsungen von Feldbuskomponenten, in VDI-Berichte 1515. Dsseldorf, Germany: VDI Verlag, 1999, pp. 5766. [22] D. Krumsiek, FDCML, eld device conguration markup language, Systemneutrale XML-basierte Gertebeschreibung, in VDI-Berichte 1756. Dsseldorf, Germany: VDI Verlag, 2003, pp. 789794. [23] S. Eberle, XML-basierte Internetanbindung technischer Prozesse, in Informatik 2000, Neue Horizonte im neuen Jahrhundert, K. Mehlhorn and G. Snelting, Eds. Berlin, Germany: Springer-Verlag, 2000, pp. 356371. [24] OPC XMLDA 1.00 Specication V1.00, 2003 [Online]. Available: http://www.opcfoundation.org, OPC Foundation, White Paper. [25] XSL Transformations (XSLT) Version 1.0, , 1999 [Online]. Available: http://www.w3c.org/TR/1999/REC-xslt-19991116, World Wide Web Consortium, W3C Recommendation.

[26] A. Skonnard, Extending XSLT with JScript, C#, and visual basic .NET, MSDN Mag., vol. 17, no. 3, Mar. 2002 [Online]. Available: http://msdn.microsoft.com/msdnmag/issues/02/03/xml. [27] W. Elmenreich, Time-triggered smart transducer networks, IEEE Trans. Ind. Inform., vol. 2, no. 3, pp. 192199, Aug. 2006. [28] R. Huber, Konzept, Realisierung und Bewertung des Sensor/Aktorbusses TTP/A, Ph.D. Dissertation, Dept. Elect. Eng., Munich Tech. Univ., Munich, Germany, 2003. [29] Specication of the TTP/A Protocol Version 1.15, , TTA-Group, 2000 [Online]. Available: http://www.ttagroup.org. [30] M. Long and C.-H. Wu, Energy-efcient and intrusion-resilient authentication for ubiquitous access to factory oor information, IEEE Trans. Ind. Inform., vol. 2, no. 1, pp. 4047, Feb. 2006. [31] Y. Xu, R. Song, L. Korba, L. Wang, W. Shen, and S. Lang, Distributed device networks with security constraints, IEEE Trans. Ind. Inform., vol. 1, no. 4, pp. 217225, Nov. 2005. [32] F. Gutbrodt, Agentenuntersttztes IT-Sicherheits-Konzept fr Automatisierungssysteme, in VDI-Berichte 1883. Dsseldorf, Germany: VDI Verlag, 2005.

Stephan Eberle was born in Stuttgart, Germany, on February 9, 1972. He received the M.Sc. and Ph.D. degrees from Universitt Stuttgart in 1998 and 2005, respectively, both in electrical engineering. From 1994 to 1999, he worked for a subcontractor, manufacturing data acquisition devices and test systems for electronic control units in road vehicles. During 19992004, he was a Research Associate at the Institute of Industrial Automation and Software Engineering, Department of Electrical Engineering and Information Technology, Universitt Stuttgart. In 2003, he spent one month as Visiting Assistant Professor at Universidade Federal do Amazonas, Manaus, Brazil. Since June 2004, he has been a Software Architect at Robert Bosch GmbH, Stuttgart, Germany. He is the main author of seven papers in national and international journals and conferences. His professional interests include application of Internet technologies in industrial automation, embedded systems, component-oriented software development, and model-driven development of domain-specic engineering tools for embedded systems. Dr. Eberle is the recipient of the 2002 Best Presentation Award from the 36th Colloquium on Control Engineering at Boppard, Germany, and the 2002 Best Paper Award of the journal Automation Technology in Practice, Oldenbourg Industrieverlag, Germany.