Generalized Fieldbus Interfaces

Generalized interfaces enable clients to retrieve fieldbus data from a service without in-depth knowledge of underlying fieldbus technologies. A SOAP Web Service on the Internet/fieldbus gateway provides data structures that represent data in fieldbus nodes. Read and write operations on these structures may then be used to access and modify fieldbus data.

Generalized fieldbus interfaces alone are not enough to guarantee interoperability. The key is a detailed specification of abstraction layers and broadly accepted standardization. This task is not easy to accomplish as there are many different fieldbus systems with varying functionality and numerous vendors with different interests that have to agree on one interface specification.

Standards have to deal with the level of abstraction and the coverage of fieldbus specific details. Figure 25 shows how three different fieldbus systems can be represented by a generalized interface.

Figure 25: Influence of detail/generalization level on standards

It can be observed that certain features of the different fieldbus systems overlap, while others are fieldbus specific. For instance, all three technologies will have similar read/write operations, while asynchronous notifications are handled differently. There are two possibilities of implementing such a generalized interface:

Limited feature coverage:

The right figure shows an interface that only covers overlapping functionality of different fieldbus technologies. The huge advantage of such a standard is simplicity: only simple functionality, such as read/write, browsing etc. will be covered. Therefore such interfaces will be easy to implement and will lead to a high level of compatibility. The disadvantage of this concept is that advanced fieldbus specific operations cannot be used.

Maximum feature coverage:

The figure on the left shows an interface which covers functionality of all three fieldbus systems. Such an interface would cover overlapping features and furthermore specify fieldbus specific extensions to the standard, which deal with different fieldbus specific aspects.

At first glance the ideal solution seems to be the second, covering numerous fieldbus specific features while maintaining a high level of generalization. The problem is that the basic functionality has to be modeled in a way so that it can be extended to cover fieldbus specifics, which may lead to complicated specifications. Moreover, fieldbus specific extensions have to be provided, which make the specification even longer and more complex. Standards that are difficult to read and to understand often lead to misinterpretations and incompatible applications. Moreover, the extensibility may lead to situations where fieldbus vendors implement functionality which is already covered in the standard in their own way, resulting in incompatible solutions⁵⁷. Another issue is that the implementation of a complex standard is expensive and time consuming and may therefore lead to incomplete or unstable implementations that once again raise interoperability problems.

Therefore working groups who design standards for Internet/fieldbus interfaces have to carefully balance between simplicity and coverage of fieldbus specifics. Many of today's successful standards focus on a very limited set of fieldbus functionality, such as a limited set of data types and basic fieldbus operations like reading/writing and browsing.