- The industrial valve industry is in the middle of a decades-long communication standards transition — from standalone pneumatic positioners with no digital intelligence, through 4-20mA with HART overlay, to fully digital fieldbus protocols and now Ethernet-based architectures — and understanding where each technology sits in this evolution is essential for making sensible capital investment decisions.
- HART, Foundation Fieldbus, and Profibus PA each offer genuine advantages over conventional 4-20mA for valve asset management, but they are not interchangeable: HART is the dominant installed base and retrofit choice, Foundation Fieldbus is the established high-end option for new process plant, and Profibus PA has a strong presence in European industry and batch processing applications.
- OPC UA is not a fieldbus protocol in the conventional sense but a data modelling and transport standard that is increasingly used to lift valve diagnostic data from instrument-level fieldbus networks into plant-level asset management and analytics systems — understanding the architectural distinction prevents expensive misspecification.
The Communication Stack for Valve Diagnostics
To understand valve communication standards properly, it helps to think in layers. At the bottom layer is the physical signal — the electrons flowing along the cable between the valve positioner and the control system. Above that is the protocol — the rules governing how data is encoded, transmitted, and interpreted. Above that is the data model — the standardised description of what the data means (this is where OPC UA comes in). And at the top is the application — the asset management software, DCS, or analytics platform that actually uses the data to make decisions.
Most of the debate about valve communication standards is really about the protocol layer, but the most important recent developments are happening at the data model layer. Plant operators who have a mix of HART, Foundation Fieldbus, and Profibus PA instruments in the same plant face a genuine challenge: each protocol provides rich diagnostic data in different formats, with different parameter naming conventions, and through different software interfaces. OPC UA with its information modelling capability offers a path to standardised data extraction from all of these protocols through a common interface — but only if the software tools at each level implement the standard correctly, which is an ongoing challenge.
HART Protocol: The Dominant Standard
HART (Highway Addressable Remote Transducer) is by far the most widely deployed digital communication protocol for industrial instruments and valves worldwide. It operates by superimposing a frequency-shift keyed digital signal at 1200 baud onto the standard 4-20mA current loop, allowing digital communication with the device while the analogue signal continues to control the valve position in real time. The physical layer is compatible with all existing 4-20mA wiring infrastructure, which is the fundamental reason for HART’s dominant installed base — it can be adopted without rewiring, making it the natural choice for upgrading existing plants.
HART devices communicate using a standard set of commands divided into universal commands (which every HART device must support), common practice commands (which most devices support), and device-specific commands (which expose features unique to a particular device type or manufacturer). For a valve positioner, the universal and common practice commands cover position setpoint, position feedback, and basic device status. Device-specific commands are where the rich diagnostic data lives: valve signature data, friction force calculations, partial stroke test results, and actuator pressure histories are all accessed through device-specific commands whose syntax is defined by the individual manufacturer.
HART 7, the current version of the protocol, introduced a wireless variant (WirelessHART or IEC 62591) that uses IEEE 802.15.4 radio technology in a self-healing mesh network topology. WirelessHART allows the diagnostic data from valve positioners to be monitored without physical cable connections, which is particularly valuable for monitoring remote or hard-to-access valves and for retrofit installations where running new cables is prohibitively expensive. The wireless network has a fixed update rate (typically one reading per four seconds for battery-powered devices) which is adequate for monitoring slowly changing diagnostic parameters but is not suitable for real-time control applications.
FOUNDATION Fieldbus H1
FOUNDATION Fieldbus H1 (FF-H1) is a fully digital, two-wire bus protocol that differs fundamentally from HART in its architecture. Where HART coexists with a 4-20mA signal, Foundation Fieldbus H1 replaces the analogue signal entirely — the bus carries power to the field devices and digital communication simultaneously, and the control loop is executed by function blocks running in the field devices themselves, not in the DCS. This architecture, called control in the field, reduces scan time, eliminates D/A and A/D conversion latency, and allows the valve positioner to execute the PID control calculation locally at the valve, independent of communication latency to the DCS.
FF-H1 operates at 31.25 kbit/s on a bus that can support up to 32 devices (in practice, 12 to 16 is more typical to maintain adequate communication cycle time for each device). The protocol uses a deterministic, scheduled communication model where each device is allocated a specific time slot for its data transmission — this determinism is a key advantage over protocols using collision-based access, as it guarantees that each device gets its scheduled communication turn regardless of overall bus loading. The function blocks defined by the Foundation Fieldbus standard include the AI (analogue input), AO (analogue output), PID, and DO (discrete output) blocks that implement standard control functions, as well as transducer blocks that interface to the physical device hardware.
The diagnostic data available from a Foundation Fieldbus positioner is at least as rich as from a HART positioner, and the standardised transducer block structure means that much of the diagnostic data is accessible through standard parameter names defined in the Foundation Fieldbus specification, rather than through proprietary device-specific commands. This standardisation simplifies the integration of Foundation Fieldbus devices into asset management software compared to HART, where device-specific command interpretation requires manufacturer-supplied device description (DD) or field device tool (FDT) driver software.
Profibus PA
Profibus PA (Process Automation) is the process plant variant of the Profibus DP protocol family and uses the same IEC 61158-2 physical layer as Foundation Fieldbus H1 — indeed, the physical layer is identical, and Profibus PA and Foundation Fieldbus H1 devices can share the same field wiring infrastructure through appropriate segment couplers. The communication protocol above the physical layer is different: Profibus PA uses a master-slave communication model where the Profibus DP master (typically a DCS IO card or field controller) polls each slave device in sequence, rather than the scheduled token-passing model of Foundation Fieldbus.
Profibus PA is particularly strong in the European process industry and in batch processing applications where the Profibus DP architecture extends from factory automation (using the RS-485 physical layer at higher speeds) seamlessly into the process field level through Profibus PA segments. For a pharmaceutical batch process where the automation system already uses Profibus DP for motors and drives, extending into the process field instruments using Profibus PA is architecturally natural and avoids the need for an entirely separate fieldbus infrastructure.
The profile for valve positioners in Profibus PA is defined by the Profibus Profile for Process Control Devices, which standardises the data objects for position setpoint, position feedback, and basic diagnostics. More detailed diagnostic data from Profibus PA positioners is typically accessed through manufacturer-specific parameters using the General Station Description (GSD) file mechanism, analogous to the HART device description file approach. The richness of the diagnostic data available over Profibus PA from modern smart positioners is comparable to HART and Foundation Fieldbus equivalents — the limiting factor is typically the asset management software’s ability to interpret and display manufacturer-specific parameters.
OPC UA and the Data Aggregation Layer
OPC UA (OPC Unified Architecture) is a platform-independent data exchange standard developed by the OPC Foundation that operates above the fieldbus and DCS layers to provide standardised access to process data, historical data, and device diagnostic information from any OPC UA-compliant software application. Where HART, Foundation Fieldbus, and Profibus PA are instrument-level communication protocols, OPC UA is a server-client framework for aggregating and exposing data from multiple sources through a unified interface.
In a modern plant information architecture, OPC UA servers are installed at the DCS or asset management software layer. These servers read data from the field instruments through HART, Foundation Fieldbus, or Profibus PA (using the appropriate protocol-level software drivers) and expose this data through a standardised OPC UA interface to any OPC UA client application — plant information systems, enterprise asset management platforms, analytics dashboards, or cloud-based monitoring services. The OPC UA information model allows the server to expose not just the raw data values but also their semantic meaning — the server can tell a client that a particular data value is the friction coefficient of valve SV-1234, not just an anonymous floating-point number.
The NAMUR Open Architecture (NOA) initiative, developed by the process industry organisation NAMUR, defines a specific architecture for how OPC UA should be used to access field device diagnostic data alongside the primary process control path. The NOA architecture separates the control loop (which continues to use the established fieldbus protocols for reliability and determinism) from the monitoring and optimisation path (which uses OPC UA to transmit diagnostic data to plant-level asset management and analytics systems). This separation ensures that diagnostic data collection cannot interfere with the control loop — a critical safety consideration for process plant automation.
Ethernet APL: The Next Generation
Ethernet Advanced Physical Layer (Ethernet APL) is the emerging technology that is beginning to displace the established fieldbus protocols for new installations. Ethernet APL extends standard industrial Ethernet down to the field instrument level using a two-wire cable infrastructure that provides both communication and power to field devices, similar to the existing fieldbus physical layer standards. The communication speed is 10 Mbit/s — approximately 320 times faster than Foundation Fieldbus H1 — which removes the bandwidth constraints that limited fieldbus-level data exchange and opens the door to transmitting high-resolution valve signature data, waveforms, and video from field devices in real time.
The protocols that run over Ethernet APL in the process field include PROFINET (the Ethernet version of Profibus), EtherNet/IP, and HART-IP, as well as OPC UA running directly on the physical layer. For valve positioners connected via Ethernet APL, the full depth of diagnostic information — position traces, acoustic emission data, vibration spectra — can be transmitted at native rate without the compression or sampling limitations imposed by the narrow bandwidth of HART or Foundation Fieldbus H1. Early adopters are installing Ethernet APL in new projects with positive results, and the fieldbus transition toward Ethernet APL is widely expected to accelerate through the late 2020s.
Practical Interoperability Challenges
Despite the existence of international standards for all these protocols, genuine interoperability between devices from different manufacturers remains a practical challenge. The core issue is that standards define a minimum set of required features but cannot anticipate every application requirement, so manufacturers extend the standard with proprietary features. The richest diagnostic data — partial stroke test results, detailed friction analysis, valve signature waveforms — is almost always in the proprietary extension zone, accessible only through the manufacturer’s own asset management software or through a carefully written device-specific driver.
Field Device Tool (FDT) technology addresses this through a standardised software framework where manufacturers provide a Device Type Manager (DTM) component that encapsulates all device-specific functionality behind a standard software interface. An FDT frame application — such as a DCS configuration tool or an asset management system — can host DTMs from any manufacturer that provides them, giving access to device-specific features through a consistent software interface without the frame application needing to know anything about the specific device. FDT is mature and widely deployed, but it depends on manufacturers maintaining and updating their DTM software, and the technology is being partly superseded by web-service-based device integration approaches in Ethernet APL environments.
Specifying Communication Requirements for Valve Positioners
When specifying communication requirements for new valve positioners, the engineer must align the positioner protocol selection with the installed DCS and asset management infrastructure. Specifying Foundation Fieldbus positioners for a plant where the DCS uses HART multiplexers and a HART-based asset management system is a specification error that will create integration headaches without delivering any additional value. Conversely, specifying basic 4-20mA positioners for a plant with a full asset management system that is waiting to receive HART diagnostic data wastes the capability of the infrastructure.
The functional safety requirements also affect protocol selection. For safety instrumented system valves, the communication protocol must not interfere with the safety function. HART communication over the same wires as the SIS output is generally acceptable for monitoring purposes because the HART signal does not affect the 4-20mA current level that drives the safety function. Foundation Fieldbus in control-in-the-field mode requires careful SIL assessment of the function block architecture, and the IEC 61511 standard’s requirements for separation between safety and non-safety functions must be addressed in the fieldbus segment design.