Operations for Fieldbus Access

An Internet/Fieldbus gateway has to implement certain operations for clients accessing the fieldbus. The fieldbus itself provides various services that may vary from one fieldbus system to another. These services have to be abstracted by the gateway and aggregated into operations that are presented to the client.

Basically there are two perspectives from which operations may be defined:

1. Fieldbus-centric:

Fieldbus systems define various operations that may be used to access and control fieldbus devices. An Internet/fieldbus gateway may try to map these operations to SOAP Web Services and map them to the Internet as depicted in figure 26. This way, several specific fieldbus functions, like data retrieval and updates, historic data retrieval and network configuration could be represented by the gateway quite easily. Mapping internal fieldbus operations to Web Services has the huge advantage that the fieldbus may be accessed in detail - all features of the fieldbus may be utilized.

Figure 26: Mapping fieldbus specific operations to Web Services

The huge disadvantage of this approach is that the underlying protocols of Web Services may not be appropriate for certain fieldbus operations⁵⁸. Workarounds and programming tricks that partially solve protocol limitations are often used to circumvent these shortcomings but make the implementation complex⁵⁹ and difficult to understand.

2. Internet protocol-centric

: Web Service protocols such as SOAP or underlying protocols like HTTP or TCP/IP were designed with specific applications in mind. SOAP's basic goal is to implement remote procedure calls while HTTP was designed to transmit hypertext documents. Most fieldbus operations can be abstracted and aggregated into a handful of very basic Web Services that provide access to the fieldbus and also suit the underlying Web Service technologies as shown in figure 27.

Figure 27: Aggregating fieldbus specific operations to specific Web Services

An interesting approach is the ``Representational State Transfer'' (REST) Web Service architecture which is introduced in depth by [FIE00]. REST is different from SOAP and is - instead of focusing on RPC - a resource-centric<sup>60</sup> approach and defines the following four so-called ``Verbs'' that modify resources and directly map to the HTTP protocol:

1. GET:

This function requests data from a resource. Requests do not alter any data and are free from side effects.

2. POST:

The POST function adds something to a resource, such as pieces of information.

3. PUT:

PUT creates or overwrites resources.

4. DELETE:

Resources may be deleted with this function.

Although REST is a different technology from SOAP Web services, it clearly shows that numerous Internet operations may be reduced to a handful of very basic ones. Applied to fieldbus systems, this means that various specific fieldbus operations may be aggregated into some elementary functions, which can be easily represented by Internet technologies, such as:

Read:

Read data or properties from fieldbus nodes.

Write:

Write values to fieldbus nodes.

Browse:

List available fieldbus nodes.

Status:

Retrieve status information about the server or the fieldbus nodes.

The amount and the functionality of these basic functions depend very much on the underlying data structure⁶¹. Therefore the aggregation of fieldbus specific functions has to be accompanied by the modeling of the data structure.

An important aspect of this approach is that certain fieldbus specific functions cannot be abstracted and aggregated to such basic functions due to limitations in the Web Service architecture and their underlying protocols. Time critical operations in particular will be difficult, if not impossible to map to such basic SOAP Web Services. However, most vertical integration applications can be implemented by means of elementary fieldbus operations as they are most often not time critical and focus on monitoring and controlling processes on a high level.