There are several bus technologies such as Profibus, DeviceNet, HART and Modbus/RTU using different cables, interface hardware and data formats. It is frustrating for both users and automation vendors.
Each bus technology has its strengths and weaknesses. Profibus and DeviceNet are fast, and ideal for motor controls. The original HART coexists with 4-20 mA and is ideal for smart field instruments, but media is slow. Modbus/RTU is easy for device vendors to implement in products and ideal for miscellaneous devices like vibration monitors and weighing scales. Many bus technologies tried to be the single fieldbus for all vendors to implement and deploy, but since the technologies are good at different things, it did not happen. It must be stressed that within their niches, each bus successfully enabled interoperability. For instance, for field instruments, HART has provided multivendor interoperability between instruments and systems for more than 30 years.
Get your subscription to Control's tri-weekly newsletter.
Based on product type, device manufacturers implement one of these bus technologies. When two bus technologies have similar capabilities, device manufacturers tend to focus on one of the technologies. Similarly, each user tends to prefer one bus technology over the other for technologies with comparable capability.
Multiple bus technologies are frustrating for users which must deploy multiple parallel infrastructures across their plants to support a mix of field instruments, motor controls and miscellaneous devices. They also must add coaxial cable infrastructure for process video. Multiple bus technologies are also frustrating for vendors, which must support multiple product lines because bus technologies use different interface hardware.
Both users and vendors want a solution. Users want a solution where a single infrastructure can support multiple protocols to connect field instruments, motor controls and miscellaneous devices to a common single shared infrastructure. Vendors want a solution where a single instrument model can support multiple protocols to satisfy all users.
The Ethernet multi-protocol solution
The solution is the same as in the office and at home—IP and Ethernet carrying multiple application protocols. IP and Ethernet carry the HTTP protocol for web browsing, SMTP for email, FTP for file transfer, RTSP for IP cameras, and many more at the same time. In plants, control systems have been using IP and Ethernet for almost 30 years, so it is well established in automation. Regular Ethernet is used for workstations in the control room, as well as servers, controllers and I/O systems in the marshalling room.
However, regular Ethernet is not suitable for field instruments due to limited cable length, separate power and hazardous areas. IEEE recently created single-pair Ethernet, providing power and communication over just two wires reaching up to 1 km. The four leading industrial protocol standards development organizations (FieldComm Group, ODVA, OPC Foundation and PI) that previously had different bus technologies came together to create a common industrial-grade, two-wire intrinsically safe advanced physical layer (APL) based on the new IEEE standard. Referred to as Ethernet-APL, it is suitable not only for field instruments such as transmitters and valves, but also other kinds of field devices. APL supports the IP application protocols from all four organizations: HART-IP, EtherNet/IP, OPC-UA, PROFINET, and many more like Modbus/TCP at the same time. Information and communications technology (ICT) protocols such as FTP, HTTP and SMTP are also supported by APL. Users wish for a single network infrastructure supporting all kinds of devices using a mix of protocols is now becoming a reality.
Lower cost infrastructure
The vision for the future is a single Ethernet-APL cable infrastructure to support all kinds of field devices, not just instrumentation. Ethernet-APL instruments will not be lower cost than 4-20 mA instruments, but a single infrastructure will be lower cost than multiple infrastructures. APL is high speed, 10 Mbit/s, sufficient for high-bandwidth applications like streaming process video or bulk material LiDAR on the same APL network as field instruments like transmitters and valves.
Converged Ethernet everything
A single APL infrastructure can support a distributed control system (DCS) communicating with a Coriolis flowmeter using HART-IP protocol. At the same time, it can communicate with an analyzer management and data acquisition systems (AMADAS) communicating with a gas chromatograph (GC) using Modbus/TCP, or a programmable logic controller (PLC) communicating with a variable speed drive (VSD) for an electric motor using Profinet. In addition, it can enable pump condition monitoring software on a server to communicate with a vibration monitor using OPC-UA. Beyond classic instrumentation, a human machine interface (HMI) panel PC can communicate with a PTZ video camera streaming process video using ONVIF or RTSP—on the same network at the same time.
Converged IP everywhere
A key success factor for the IP, Ethernet, Wi-Fi and the Internet, is that they are all designed to carry multiple application protocols. No single application protocol attempts to perform all functions. There is a specialized protocol for each function. At home and in the office, we use multiple protocols and software makes the protocol transparent so most don’t notice which protocol is used. Similarly in a plant, HART-IP can be used for all instrumentation, Profinet for all motor controls, Modbus/TCP for all miscellaneous things. The automation systems will have to make the protocol transparent to the user.
But don’t take multiple protocols too far, as some flowmeters use HART-IP while some flowmeters use Profinet and other flowmeters use Modbus/TCP. That would be difficult to support. Try to stick to one protocol for instrumentation, one protocol for motor controls, and one protocol for cameras and so on.
A vast selection of physical media exists for the IP network protocol, both wired and wireless, to solve many use-cases.
Transition to APL
The transition to pure APL will take years. Even new plants will be built with a mix of APL and 4-20 mA instrumentation because it will be a long time before all devices are available in an APL version, and the additional cost of APL may be hard to justify for simple devices. Wireless sensors will also be there in ever increasing numbers. Sure, 4-20 mA/HART devices can be fitted with an Ethernet-APL adapter, but some 4-20 mA devices will be hardwired to small field I/O systems.
The good news is that 4-20 mA/HART, WirelessHART, and future Ethernet-APL devices with the HART-IP protocol all have one thing in common: the HART application protocol. They are all part of the same protocol ecosystem. This means instrument technicians can manage all instruments from the same software. Instrument technicians are already familiar with HART terminology, and they get consistent look and feel for all instruments regardless of instrument signal. This makes managing this inevitably mixed environment easier. Because HART-IP is an instrument protocol, not a PLC protocol, it makes APL less complex and thus the learning curve to adopt APL less steep.
HART-IP is not the old 1.2 kbit/s HART used with 4-20 mA devices for commissioning, configuration, calibration, and diagnostics. HART-IP can still do commissioning, configuration, calibration and diagnostics, but it will run at 10 Mbit/s over Ethernet-APL and even faster across regular Ethernet. It is more than 8,000 times faster. Therefore, HART-IP also supports real-time communication of process variables from transmitters and setpoint outputs to valves in monitoring, control loop and safety instrumented functions.
HART-IP is not an entirely new protocol. Many plants already use HART-IP over regular Ethernet in wireless gateways, HART multiplexers, safety logic solvers, remote-I/O, intelligent device management (IDM) software, equipment condition and performance monitoring software, vibration monitoring software, and smart instrumentation.
So, for the next project, automation designers will have to think less about cable selection for various buses. Instead, look around to see what new kinds of field devices are available with APL and make sure to select a control system that supports multiple application protocols to meet the needs of instrumentation, electricals and beyond. This will give operators new capabilities they did not have in the past.
