Application Specific Interfaces

Fieldbus applications typically reside in the fieldbus itself. For instance, the LON technology enables programmers to put logic into one or more fieldbus nodes which may together form one application. An example would be an electrical garage door that is controlled by several fieldbus nodes connected to switches, motor control and sensors. Every node implements a certain part of the application; the node connected to the switch, for instance, starts and stops the motor. This common approach, as depicted in figure 30, has many strengths, such as that the fieldbus operates autonomously and applications may therefore still work even when nodes are disconnected. Moreover, there exist a number of well-tested tools for creating such fieldbus applications.

Figure 30: Application in a LON fieldbus

Nevertheless, there may be situations, where it is more appropriate to install a certain application in a ``special'' fieldbus node which offers capabilities that a normal fieldbus node cannot provide, such as improved computing power, increased storage, certain technologies or improved connectivity. An Internet/Fieldbus gateway will often provide this extended functionality and may therefore be appropriate for certain fieldbus applications. Figure 31 depicts a scenario where an application resides in the fieldbus gateway.

Figure 31: Application on an Internet/Fieldbus Gateway

Such ``gateway applications'' may range from simple views of fieldbus data to complex applications. Such views may be accompanied by detailed information about this fieldbus data and may ease the access of certain information for clients. For instance, retrieving the average temperature in a building or the number of active lights may be done with such views, which are nothing more than very simple gateway applications. As denoted above, abstract fieldbus interfaces often lack information about fieldbus data. Gateway applications could wrap certain fieldbus data into views and provide accompanied information about this data.

Applications on an Internet/Fieldbus gateway may also provide an interface to the Internet which may be implemented in various common protocols, such as HTTP, SMTP or SNMP. Another approach would be SOAP Web Services, which seem to fit perfectly as they provide the following key advantages:

Improved accessibility:

Accessing SOAP Web Services is an easy task and is supported by various frameworks which exist for many platforms. As denoted in chapter 2.4, programmers may easily access Web Services by using the WSDL document of a Web Service. WSDL not only eases the access, it also provides a technical documentation of the Web Service. Listing 17 shows the client code in the Python programming language for accessing a simple Web Service that returns the temperature from a fieldbus sensor⁷⁰. The example depicts that it takes only some simple code lines for accessing the service, which makes it very easy to integrate fieldbus applications in existing applications.

language=Python

Self-documentation:

By providing WSDL documents together with a Web Service, it is possible to document not only the technical details of the service but also to outline what exactly the service does. In case of public gateway applications, UDDI may be used to offer the service on the Internet.

Easy deployment:

An Internet/fieldbus gateway may provide a special interface that allows programmers to easily deploy applications on the gateway. [ENG02] describes some common deployment techniques that may also be implemented on an Internet/fieldbus gateway.

Fine grained access rights:

[VEN05] states that ``Application-specific interfaces allow a more flexible authorization scheme.'' Gateway applications expose only specific fieldbus data needed by the client. Other - maybe critical - data is not made accessible. Moreover, it is possible to implement advanced access rights, such as client authorization, or limiting access for specific networks. This way, there may be specific access limitations for certain gateway applications, while others could be publicly accessible.

Better error handling:

When an error in the fieldbus occurs, such as a defective sensor, an error message has to be returned by the Internet/fieldbus gateway. Gateway applications may map this general sensor error to an application-specific error, which may be more descriptive and understandable than the native fieldbus error. Moreover, the gateway application may react to certain errors in specific ways, such as by disabling parts of the application or by replacing missing functionality by other means⁷¹.

Despite various advantages, gateway applications have certain weaknesses, such as the following:

Configuration:

Gateway applications have to be adapted to the underlying fieldbus. For instance, a gateway application that calculates the average temperature in a building needs a list of all temperature sensors. Therefore this application has to be configured according to the underlying fieldbus. Moreover, if temperature sensors are added or removed from the fieldbus, the application has to be reconfigured.

Fieldbus dependent:

A gateway application is developed for a specific fieldbus only. If the underlying fieldbus technology of an Internet/fieldbus gateway is different, the application has to be adapted as the fieldbus interface may differ.

This problem may be solved by introducing an additional abstraction layer in the fieldbus that unifies fieldbus access for gateway applications⁷².

Hardware dependent:

Gateway applications, which are developed in common programming languages, such as C, will be in a binary and hardware dependent format. Therefore such gateway applications cannot be installed on gateways with different underlying hardware.

This problem can be overcome by using programming languages, such as Java or Python, which generate hardware independent byte-code. However, byte code will be interpreted by a virtual machine, requiring extra processing power and memory which may not be available on simple Internet/fieldbus gateways.