RESOURCES

Index:

Smar SYSTEM302 successfully completes FF HIST
Smar SYSTEM302 servers pass OPC compliance test
Open Systems Require Host Interoperability
Articles featuring Smar on the Internet

Smar SYSTEM302 successfully completes FF HIST

Jonas Berge

Smar Singapore Pte Ltd

E-mail: jberge@smar.com.sg

SYSTEM302 has successfully completed the FOUNDATION™ Fieldbus Host Interoperability Support Test (HIST) performed by the Fieldbus Foundation.

This independent interoperability test has demonstrated that SYSTEM302 incorporates the features required to configure and monitor FOUNDATION™ Fieldbus devices from a wide range of other manufacturers making a plethora of instruments available to SYSTEM302 users. A rapidly expanding range of registered third-party devices can be tightly integrated to SYSTEM302 with ease. End-users and system integrators can rest assured that a mix of equipment from different suppliers will work together, and that all functions in these devices can be fully utilized and configured with the same single tool.

HIST is the host-device equivalent of the field instrument interoperability registration. The HIST checks for what Fieldbus features are available in the host, therefore there is no "passed" for this test, only a "completed" accompanied by a checklist of available functions.

HIST is of great significance to users because it obsoletes the proprietary certification of instruments done by some system suppliers in the past to imply that only some devices are compliant with the host. HIST is a non-affiliated test that assesses if the host has the framework to be compliant to any registered device. It is a modular concept. By using a HIST host and registered devices an interoperable system is achieved. In conjunction with the OPC server compliance test passed by the SYSTEM302

H1 and HSE Fieldbus interfaces SYSTEM302 has been demonstrated as a completely open system, interoperable with both devices and software from other manufacturers enabling powerful solutions for the users.

Fieldbus Foundation announcement:

http://www.fieldbus.org/neprd0301.htm#anchorhist

Systems that have completed HIST so far:

http://www.fieldbus.org/histpg.htm#anchortop

Smar SYSTEM302 servers pass OPC compliance test

Jonas Berge

Smar Singapore Pte Ltd

E-mail: jberge@smar.com.sg

The OPC servers for the SYSTEM302 Fieldbus interface card PCI302 for H1 and the DFI302 linking device for HSE have passed the rigorous OPC Foundation interoperability test for version 2.0 of the OPC specification. This interoperability test has demonstrated that SYSTEM302 data related to the process as well as the devices and control strategy can be disseminated throughout the enterprise making a plethora of software from a wide range of manufacturers available to SYSTEM302 users. Users can select the process visualization software of their choice and additionally select from a rapidly expanding range of software for advanced control, historization, statistical process control, batch management, links to the office and business environment etc. These applications can be tightly integrated to SYSTEM302 with ease. End-users and system integrators can rest assured that a mix of software from different suppliers will work together, and that all data from the process and in the devices can be fully utilized from any software, with the same tag name.

In conjunction with the FOUNDATION™ HIST test completed SYSTEM302 has been demonstrated as a completely open system, interoperable with both devices and software from other manufacturers enabling powerful solutions for the users.

OPC:

http://www.opcfoundation.org/05_products/SMARpg.htm

Open Systems Require Host Interoperability

Jonas Berge

Smar Singapore Pte Ltd

E-mail: jberge@smar.com.sg

KEYWORDS

Host, interoperability, Fieldbus

ABSTRACT

A control system based on Foundation™ Fieldbus consists of field instruments such as transmitters and positioners, host, linking devices and other network components. After patiently waiting for some 20 years for Fieldbus interoperability users may be surprised that not all system hosts are interoperable with field instruments. The host is the most important device in the system because the workstations run powerful software for operation, engineering and maintenance. The level of sophistication of the host software determines how powerful the system will be. However, if the host is not able to support all the standard functions in field devices from all suppliers it is not possible to fully benefit from Fieldbus. Interoperable field devices are ineffective unless the system host is also interoperable. A main purpose of the Fieldbus standard is to protect system end-user from being cornered into using only a single brand or limited set of field instruments that used to be the case with many DCS in the past. The interoperability of Foundation™ Fieldbus gives users freedom of choice to pick any brand and type of device.

Introduction
Need for host interoperability
Device support
Benefits
Proprietary vs. independent host testing
Host capabilities
Architecture difference
CONCLUSION

1. Introduction

Traditionally the system has been a part that is separate from the field devices. The field devices used to be connected to the control system. The tight digital integration achieved with Fieldbus has now instead made the field devices integral parts of the system. The workstation and the software are in Fieldbus and other network terminology referred to as the host (figure 1).

Figure 1. In the traditional architecture (left) the field instruments were isolated whereas in a modern architecture (right) the field devices are an integral part of the system.

contents

2. Need for host interoperability

One of the major challenges for a plant is that no vendor has a range of products wide enough to provide all the required parts for a site. Any plant will always have a mix of products from different suppliers. A multiple vendor environment cannot be avoided and must therefore instead be simplified. Moreover, one supplier never has the best product in every category, thus it is desirable to buy different device types from various manufacturers that are specialists in the particular area. Because the equipment from different suppliers in the past had incompatible proprietary protocols a site had two undesirable options: compromise by either settle for the preferred device with poor integration to the rest, or for the less then best device in favor of better integration. Because of past protocol differences third party field instruments could not be digitally integrated with the DCS to fully benefit from their intelligence. Plants usually had to buy the field instruments from the DCS supplier. Once a traditional proprietary system had been purchased the plant was essentially "locked-in" by the manufacturer. To maintain system integration replacement transmitters had to be bought from the same supplier as the original device. Because the system at this point no longer had any competition, replacement parts and extras where much costlier than for the original system.

Since users need to mix and match a plethora of devices from a wide range of suppliers and must be able to find urgent replacement from other parties than the original supplier, host interoperability to support such devices is essential. The purpose of a standard is to make this interoperability possible. As long as field device and host device suppliers are following the standards and implement them correctly the devices can work together in spite of their different origins. Independent tests are the only way to ensure compliance.

Control systems once installed normally operate for decades, often with many years in between shutdowns for maintenance or upgrade. New Fieldbus devices are coming into the market at a rapid pace and new versions of existing devices are loaded with more features. In the future a plant may be required to install field devices that are not even available today, the host must be able to support those essentially "as-is" as a system shutdown would otherwise be required. The Foundation™ Fieldbus technology was purpose built to make the addition of devices from different suppliers possible online. In an open host standard device support files can be loaded without shutting the system down to install drivers or write custom code.

Technology does not stand still. Since its introduction in the mid nineteen nineties Fieldbus has seen several improvements to enhance capabilities, performance and interoperability. Apart from building the basic host on standards and implementing those standards correctly, it is also essential that the host supports as many of the newer advanced features introduced into Fieldbus the past few years as possible.

contents

3. Device support

One of the main purposes of Fieldbus is to ensure that host devices are interoperable with the field devices that make up the system. Not just devices that are available now, but also devices that are available in the future. This is achieved by loading information about the device into the host. Using this information the host is able to make the configuration for the device and communicate with it etc. For example, Corning, NC, USA, is using a Smar SYSTEM302 consisting of host and many field devices from Smar, but also instruments from Accord-Flowserve, Yamatake, Rosemount and Micromotion in the optical fiber plant.

3.1. Standard support files

To be interoperable with devices from different manufacturers the host only has to be loaded with device support files for the device. Providing these device support files for the device is compulsory in order for the field device to be registered. Loading the files is an extremely simple drag and drop operation (figure 2). Typically hosts come with support files for most devices already installed and only files for new devices that come to the market have to be loaded. I.e. no custom configuration or programming is required to achieve interoperability. This makes it easy to benefit from Fieldbus interoperability.

An open host requires only the three files defined in the Foundation™ Fieldbus standard to be supplied by the instrument manufacturer for their field device in order to communicate with it. There are two Device Description (DD) files, and one Capabilities file. Because the device supplier provides these files, the standard files are always compatible even with the latest version of the device. A unique feature among buses is that these file format definitions are all an integral part of the Fieldbus specification and device registration so that all host device manufacturers can use the same file.

Figure 2. Device Description and Capabilities files enable interoperability for every version of the device.

3.2. Proprietary support files

In addition to the three standard device support files some hosts require a few proprietary files for each device type in order to work with a field device. These files have to be developed by the host manufacturer, not the device manufacturer, which pose a number of disadvantages to the proprietary host:

1. The system is not open even though it is based on Fieldbus. The user has no freedom of choice as the host supplier's willingness and ability to provide the additional proprietary files for third party devices dictate the options.

2. As many new manufacturers and device types come to the market the host supplier may not be able to develop, test and verify their proprietary files against the real device in a timely fashion, thus users can only benefit much later.

3. As many devices already existing in the market are improved and revised the host supplier may not be able to develop, test and verify their proprietary files against the new device in a timely fashion, thus users may experience interoperability problems as devices are added or replaced. Because of revisions, these problems may occur even though the host supplier had originally tested their host against that type of device.

Because the proprietary device support files are not tested by the Fieldbus Foundation, the host manufacturer must also conduct their own testing to ensure that the additional files are OK in order to guarantee the communication will work. It is unrealistic for a host supplier to manage relations with device suppliers to keep up to date for thousands of devices. It is unrealistic to for device suppliers to manage relations with dozens of host suppliers for each of their device. Therefore hosts requiring proprietary files are at a disadvantage.

contents

4. Benefits

Host interoperability brings several benefits that ultimately translate into savings and convenience.

4.1. Simplifications

Host device interoperability means that one single tool can be used to configure all the field instruments from the same workstations as opposed to using different software running on different computers for some of the devices. A homogenous system is achieved. All devices appear with a common look and feel making interaction even for new devices intuitive. If the host is interoperable any field device can be used thereby simplifying the vendor and model selection process. A system built on HSE allows integration of subsystem for boilers, tank farms, compressors and turbines etc. based on HSE to the system allowing them to be operated from the same host as the basic controls.

4.2. Improvements

Interoperability is one of the main advantages of Foundation™ Fieldbus. It allows the user to freely select devices from a wide range of manufacturers for greater versatility. Open standards create an open market with freedom of choice. If the host is open it can fully access all the devices in the plant, not just some. An open host can even access devices that were not purchased by the user directly but came as an integral part of a packaged unit like a boiler. The systems becomes better integrated and network enabled asset management becomes possible. Custom programming and drivers are not required.

4.3. Savings

Once an open system with an interoperable host device is used the replacement instruments and many other parts based on standards can be bought at prices set by the open market rather than controlled by one manufacturer. Multiple variable devices and network enabled asset management software can be freely selected and bring further savings thanks to interoperability.

contents

5. Proprietary vs. independent host testing

These days many systems boast they have open hosts because they have an interface to Foundation™ Fieldbus H1 but it takes much more than a hardware interface to be interoperable. The supporting software in general, but the configuration tool in particular, plays a crucial role in achieving host interoperability and tight system integration. To ensure that the promise of Fieldbus interoperability is delivered end-users have demanded interoperability testing of host devices similar to the field device testing.

To realize the interoperability benefits it is essential that the host have the underlying features and capabilities required in order to be interoperable. One of the purposes of the host test is to make sure that the host device has the features required for the system to support existing and future field devices conforming to the same specification without the host supplier having to test against each and every version of every device type. Host testing will encourage manufacturers to make all parts of their systems including the host more interoperable in order to not compare unfavorably against others.

Whenever standards come into play there is always some company with a comfortable market position that see their livelihood threatened by an open market. There is a risk that they will "embrace, extend and extinguish" the standard to protect the interests of their shareholders. I.e. make proprietary "improvements" on the standard so that the standard no longer is a standard and equipment become incompatible. Field device interoperability registration and host testing protect the standards and the investments users have made in the technology.

5.1. Independent tests

To promote the interoperability of system hosts with registered field instruments the Fieldbus Foundation has launched the host test initiative. It is a voluntary test that host vendors can choose to participate in. This test will help eliminate host problems caused by different interpretations of the specification. Therefore the host test ensures the quality of communication and lets the system supplier take on a greater share of the responsibility for interoperability rather than leaving it entirely with the user. Hosts will not be registered or certified and there is no pass or fail for the tests and no specification as to which functionality must be supported. A report is made showing which functions the host supports. These independent test results give users an easy way to evaluate the level of openness of the system and system capabilities at an early stage to ensure their needs for interoperability and functionality are met. Together the field device test and host test ensures that instruments and host devices will work together as a system.

5.2. Proprietary certification

You can't teach old dogs new tricks. Some suppliers of traditional control systems are new to the open concept. In spite of having a Fieldbus interface some systems do not accept field devices from many third party suppliers anyway. This could be because they have not yet developed the proprietary device support files their host requires in order to be interoperable with a device or don't want to. In these cases suppliers have a shortlist of Fieldbus devices they have prepared their host to support, i.e. devices they allow you to use. To justify the shortlist they may conduct their own proprietary certification. Although the proprietary host testing really checks if their host works with the already interoperability registered device it may be stated as the field device is interoperable with the host, e.g. a “XYZ-aware” or "XY-compatible" label for the third party device. Obviously an already registered field device is not changed rather it is the host that is adapted. The main purpose is to ensure that their own proprietary device support files are compatible with the device since those files are not tested when the Fieldbus Foundation registers the device. This kind of certification is done in the host manufacturer's own lab instead of by independent test institutes. The whole purpose of standards is that the user shall be able to select parts based on the standard, and they shall work without further adaptation or certification. Proprietary certification defeats the purpose of standards. In some cases the shortlist of devices that the host is said to support could be due to technical limitations or they could be deliberate restrictions imposed by the host supplier.

If the host is designed in such a way that it has to undergo the manufacturer's proprietary interoperability test against each type of field device for approval, many future interoperability problems can be foreseen. Because at the time of system purchase the proprietary testing of a host against field devices can only have been carried out against devices that are already in the market, perhaps for some time, users have no guarantee that new field devices conforming to the same standard released by other manufacturers in the future will be supported by the host. Although devices from one manufacturer are interoperability registered by the Fieldbus Foundation and may have passed proprietary tests by other manufacturers and even may work perfectly well with a particular system, the system supplier may refuse to develop their proprietary device support files and to conduct their proprietary testing. Thus the integration responsibility is pushed to the user. There is a risk that users end up cornered as in the past with DCS.

contents

6. Host capabilities

A system with a host that does not support all devices and functions cannot fully benefit from Fieldbus technology. For example, some systems are only able to handle a certain number of function blocks per device even though the field device itself has a higher capacity. Likewise, some hosts may not be able to instantiate new function blocks in field devices with this capability. Therefore a host should be selected with care.

Look for the following functions in a host:

H1 and HSE support
No proprietary files required for device support
Automatic detection, identification and address assignment
Support for off-line configuration using only standard capabilities files
Instantiable function blocks
Access to all parameters in transducer blocks by name also from the process visualization application

Look for the following functions in a linking device:

HSE networking to host
Redundant interface
Minimum 16 devices per H1 port
Minimum 16 blocks per device

contents

7. Architecture difference

The system architecture plays a major role in determining the benefits that will be achieved, how well the system will perform, and how easy it will be to use. If the system is based on FCS (Field Control System) architecture it will be leaner and more homogenous than a traditional DCS fitted with Fieldbus. For example, a control system with traditional architecture may use Fieldbus just for I/O, still performing control in a centralized controller using proprietary control strategy programming language and data formats. This require gateway modules to convert the transmitter data from standard Fieldbus format to proprietary before control is done and then back to Fieldbus format again prior to sending it to the positioner thus resulting in sluggish response. Moreover, the centralized controller instead of the much more efficient publisher-subscriber communication directly between Fieldbus devices may use poll-response. This in combination with the fact that three variables instead of one have to be communicated results in poor response. Additionally, it may not be possible to benefit from the advanced status information used in the Foundation™ Fieldbus programming language for failure shutdown, bumpless transfer and reset windup protection because an intermediate proprietary programming language does not support the status handshake propagation from sensor to actuator.

Figure 3. Traditional DCS architecture (left) and modern FCS architecture (right).

Perhaps the most important aspect is that the Fieldbus configuration tool is permanently connected to all of the Fieldbus networks so that diagnostics, configuration and identification can be made any time without struggling with wires.

contents

CONCLUSION

Mixing field devices from different suppliers is a necessity and subsequently host interoperability is a must. There are commercially available systems designed in such a way that the host only requires the three standard device support file and that have the features and capability to get the most out of interoperability registered devices from any manufacturer. Because only compulsory device support files are required and the standard mechanisms are in place no additional proprietary testing is required. Buying a system based on the capability it has today is the only way to ensure that the characteristics required for interoperability will be available as most manufacturers have underestimated the development effort required for a Fieldbus based system their projections for catching up may be too optimistic. Use registered devices otherwise there may be problems even with an interoperable host. Field device registration ensures quality of communication and device support file. Be wary of short lists and proprietary "certifications".