Field device networking: Extending interoperability beyond devices
Testing field devices may not be enough. Most interoperability problems happen when a device tries to communicate with a host system, but that can be addressed.
As a company that is responsible for developing and maintaining communication protocols that are used by a large number of equipment manufacturers and end users, interoperability is one of our greatest concerns. Interoperability in this context is the idea that equipment from a variety of manufacturers can function in the same system without having to be coaxed or forced in the form of reconfiguration or other changes. A pressure sensor from company A should function on the same fieldbus segment as another unit from company D.
To facilitate that objective, our organization, like other standards bodies, specifies how this communication takes place. We need to be specific enough to ensure devices will communicate without going so far as to eliminate flexibility for companies to make adjustments for specialized devices and applications. It’s a fine line, and we have found that it needs to move as technologies and user needs evolve.
It’s been clear for some time that one of the most persistent problems with Foundation fieldbus technology isn’t communication between devices, but communication between devices and host systems. The companies that make control systems, HMIs (human machine interfaces), and the like don’t always connect with field devices in the same way. Our members recognized this conundrum early on and asked us to consider how it would be practical to expand the standard to encompass this level of communication. The host testing protocols now in effect reflect many years of evaluation and development, and the job is not over.
Why do we test?
The Fieldbus Foundation is one of the only automation industry organizations with a registration program requiring mandatory testing of critical elements of its technology. Today, our testing and registration effort encompasses host systems and field devices, as well as physical layer components such as power supplies, cables, and device couplers.
Users can count on interoperability because products bearing the Foundation Product Registration symbol have undergone a series of common tests administered by the Fieldbus Foundation. End users can select the best device for a specific measurement or control task, regardless of the manufacturer, and know that device will provide a consistent level of functionality and interoperability regardless of the host system or other devices used. Testing and registration ensures that you can achieve the best return on your fieldbus investment.
There are three basic paths for testing and registration within the Fieldbus Foundation: H1 Testing for devices residing on H1 networks, HSE Testing for devices residing on HSE networks, and Host Profile Testing for host systems. Host testing and registration is of particular importance to end users. To understand why, we first need to understand what a host is.
What is a host?
In the most basic terms, a host is something that supports Foundation fieldbus messages. That may include configuration tools, recording devices, alarm display panels, HMIs, or systems with a combination of functionalities, all the way up to an integrated DCS. It may be a single instrument or consist of multiple components. It is not necessary for a host to have function blocks. A host may have an H1 interface, HSE interface, or both. It may support safety devices, control and monitoring devices, or both. A host system with an H1 interface should have a Foundation registered communication stack and physical layer interface. Hosts that include an HSE interface should have a registered communication stack. A field device can also be a host if it supports host features.
The host has been of particular concern in the past because it is the key element at the system level and can determine the success or failure of a fieldbus project. If your host is not registered and tested, you are taking some unnecessary chances and have no way of knowing if your host will work with a wide range of H1 and HSE devices from different suppliers.
The Fieldbus Foundation has been doing host testing since its earliest days. Over the years, this process has evolved considerably. Previously the Host Interoperability Support Test (HIST) provided a protocol with no provision for formal product registration. With HIST, all the work was done by the vendor. While this was helpful, it soon became clear that testing and registration of hosts was necessary, which prompted introduction of the Host Profile Registration Process.
Under the new Host Profile Registration Process, the Foundation conducts functional testing with a test device and specialized test device descriptions (DDs) and capabilities files (CFs). Registered devices from different vendors are also used during testing. The host profile under test must support a clear set of required features. A host will conform to some, or perhaps all, features as defined by the host feature checklist. However, because hosts can have various definitions, not all features may be applicable to a host implementation and every host will not support each feature.
Each feature contains a set of test procedures that are to be run against the host or the fieldbus system using the host. In order for a host to claim conformance to the feature, the host must be able to pass the test procedures defined by the feature. The features themselves are generic; therefore, manufacturers will derive test cases, or actual implementation steps necessary to meet the requirements of the test procedure. Fieldbus hosts successfully completing the test requirements are authorized to bear the official Foundation product registration symbol.
Classes of hosts
A host profile defines a minimum set of Foundation-specific features that must be implemented by a host to achieve compliance to a specific host class. A host may incorporate one or more hardware and software components as defined by the host manufacturer. Currently, the Fieldbus Foundation defines four profile classes. These include:
- Class 61—Integrated host: primary, on-process host that manages the communication and application configuration of all devices on a network
- Class 62—Visitor host: temporary, on-process host with limited access to device parameterization
- Class 63—Bench host: primary, off-process host for configuration and setup of a non-commissioned device
- Class 64—Bench host: primary, off-process host with limited access to device parameterization of an off-line, commissioned device, and
- Class 71—SIF integrated host: primary on-process host for safety instrumented functions (SIF).
Each of these host classes has its own set of characteristics, primary end users, and use cases. An integrated host is an essential part of a process, with online characteristics that you would normally associate with a DCS:
- Set and manage physical device tags for all devices as well as the network configuration
- Manage distributed application configurations, including the link schedule, backup link schedule, block instantiation, link objects, macrocycle, VCRs, and alerts
- Provide full access to all resource block, transducer block, and function block parameters, and
- May maintain a backup/off-line database.
The integrated host is widely used by many people throughout the plant. Process control engineers use the host system for configuration and analysis, operators have access through operator workstations, and maintenance will use the host through plant asset management applications. Even management can use it through other operations management and application workstations.
Class 62 visitor hosts are basic on-process hosts that may have read and write access to resource and transducer blocks. However, read-only access may be provided to function blocks. Visitor hosts do not manage the physical device tags, network configuration, or distributed application configuration. They typically reside in handheld devices that are used for maintenance and have a temporary connection to the network, or they can also reside in specialized device applications such as online control valve diagnostics.
Class 63 bench hosts may set the network configuration for off-process testing, but both Class 63 and 64 hosts are off process. They may also set a distributed application configuration, including link schedule, back link schedule, block instantiation, link objects, macrocycle, VCRs, and alerts. Class 63 bench hosts may also access all resource block, transducer block, and function block parameters. Primary users include maintenance and instrumentation personnel. Class 63 bench hosts are used for several applications, including skid operation testing and setting up a new device for service. You may also use a Class 63 bench host for maintenance of a previously configured and operating device that is removed from the process network, or setup of a new device for replacement service. If you have a used device that you want to reassign, you can use it to clear the device of any PD tag, H1 address, VCRs, LAS, function block schedules, link objects, and so on.
Class 64 bench hosts are primary off-process hosts for access to a prior-commissioned device. A Class 64 standard bench host has nearly identical requirement to a Class 62 standard visitor host with the exception of device address configuration. Primary users of Class 64 bench hosts are instrumentation and maintenance personnel. The Class 64 bench host usually resides in a handheld device that is connected to an off-process segment or specialized application such as off-line valve diagnostics.
The Class 71 SIF integrated host is the primary on-process SIF host for safety applications. Like the integrated host, the Class 71 SIF host is a fixed H1 address, on-process host. It sets and manages physical device tags for all devices. It also sets and manages the network configuration and manages the distributed application configuration, and provides all the other functionality of the Class 61 integrated host. The difference is the additional SIF-specific functionality, which includes full access to all profiled SIF-related resource block and function block parameters. It supports the SIF protocol and maintains the SIF configuration signature, and can lock and unlock all SIF devices.
Mandatory, optional, and prohibited
Host testing and registration includes various levels of features for different hosts. Depending on the type of host, these features can be mandatory, optional, or even prohibited. For each profile, individual features are marked according to a requirement.
Mandatory features for a particular host must be implemented in order to achieve compliance for the relevant profile.
Optional features may be implemented but are not required. If implemented, optional features will be tested and credited as part of compliance for the relevant profile.
Prohibited features are restricted in that profile in order to minimize the possibility of incurring unintended operations, such as changing critical configuration parameters that have been set up by another host. A candidate cannot achieve compliance to a HIST profile if any prohibited features are available in that profile.
When you look at host profile testing information for different classes, you will probably notice an aor b designation. For example, a host could be registered to Profile 61a or Profile 61b. These alphabetical designations indicate different versions of host testing and registration. The a profiles represent the first wave of host profile testing that occurred after the original HIST. The bspecifications represent a step forward to a new specification where more features are mandatory.
Beginning in 2010, all hosts tested had to be tested under the b profiles. Hosts tested under the aprofiles will be able to remain in the catalog of tested and registered hosts, but there will be no further testing under those profiles. When selecting a registered host, take note of the class it was registered to in order to ensure you are purchasing the implementation you are looking for.
Since implementation of the Host Profile Registration Process in 2007, the Fieldbus Foundation has issued 12 registration marks across all host classes. Most of these devices had already been tested under the old HIST process, but a growing number of systems have been added under the new protocol. User response has been very positive as devices and hosts move closer to true plug-and-play right out of the box.
Looking ahead, we anticipate making adjustments to our standards and testing procedures as devices and systems evolve. The number of diagnostics and intelligent options available in even the most basic field devices continues to grow, which pushes us more in the direction of increasing the number of mandatory features.
Larry O’Brien is global marketing manager for the Fieldbus Foundation.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.