Understanding Interoperability

Interoperability has one important meaning: "Capability of devices of different manufacturers to communicate and work together". This meaning has great appeal and benefits, but it can never be used against improved and more elaborate designs of transmitters and hosts.

To achieve interoperability several issues must be analysed. The first issue is to use Fieldbus Foundation (FF) approved devices. A FF approved device will guarantee you a compliant data communication implementation and a complaint set of standard Functions Blocks. This means that using approved FF devices you will have a good chance to have a working interoperable system. We say "good chance" because a system is not made only with field devices.

The second issue is the host system. FF is not approving or even testing the hosts. Therefore be careful with the host you are using, since it is the part not tested so far by FF. Using Foundation Fieldbus we know that the control functions are performed in the field, with the field device exchanging information directly, but the host is also very important. The host usually organises the communication distributing the token (permission), and exchanges data with all devices, therefore if not well implemented it can disturb and disrupt all your system and your desire for an interoperable system. It may be time to change your host.

Manufacturers that envisage the benefits of Fieldbus will guarantee interoperability, but will not allow this to stop or slow down their developments of new features. Function blocks are a good example of this. FF has a policy of only testing function blocks which were implemented by two or more manufacturers. Does that mean that a manufacturer can only release a block after another manufacturer has done the same or is ready to do the same? The answer is no. A manufacturer can release all blocks it wants. But how can he guarantee interoperability with these new blocks?

This question is very tricky and important, and we will answer it in parts.

First: FF specified through its standards how to develop a function block. A manufacturer must follow these guidelines to design the blocks.

Second: The device with these blocks must have a correct Device Description and Resource files. The Device Description and Resource files are used by the host to correctly identify all the resources in a device and configure them. Many hosts are not ready to use these files, therefore not being able to handle an interoperable system. In this case those hosts blame the device for the failure, which is not correct.

Third: Foundation Fieldbus is a very powerful protocol, with several options for configuration. Although easy to learn and design, lack of expertise can ruin a project. Expertise is one of the key factors required to put together a complete FF interoperable system.

Smar, as the leader and first company ever to release Fieldbus Devices, has played a major role in the development of the standard and would never go against it with proprietary solutions. We believe in Fieldbus as it is, an open interoperable standard.

We are now at our third generation of Fieldbus devices, and clearly ahead of the competition, with features like data link layer optimisation, function blocks instantiation and others. Most of these features are not understood by the competition, they prefer to refer these improvements as "implementation deviations". Their hosts are just not ready for a fully developed Fieldbus system.

But our commitment to the end user goes far beyond that. The device is delivered with some pre-configured function blocks which can be accessed by any host. Alternately using our host you can not only use the pre-configured blocks, but you can also define how many and what type of blocks you want your device to have, including repeating the same type of function block as many times as you want in a single device. Our field devices are capable of executing up to 20 function blocks. One may select 18 types of function blocks from an internal library (this is instantiation feature).

Who can do this?

Only Smar, with the expertise to guarantee you an interoperable system with any FF approved hardware and any working host.