66954df23cde7e4270a21b58 2402ct Podcastcover Logo

Where are we with Ethernet-APL?

Sept. 11, 2024
A Control Amplified podcast with editor in chief Len Vermillion, with help from contributing editor Jonas Berge

In this episode of Control Amplified, editor in chief Len Vermillion discusses the realities and future of Ethernet-APL.

Transcript

Today, I want to talk about something that’s been on the tongues of many for a couple of years now, but it seems to really be heating up again now that digitalization and remote operations are in the forefront of everyone’s minds, and that is Ethernet APL, and for the uninitiated that is advanced physical layer.

In  moment I’m going to read you an article we had in the September issue –our Other Voices column—contributed by Jonas Berge, who is the senior director of applied technology for Emerson, and it will really explain where we are at with Ethernet-APL in terms of it finally becoming a reality. Are we there yet? Not entirely. We’ve clearly been going through a period where people are wrapping their heads around it, and of course, their investment dollars. Obviously, there’s been some realization that it will take a bit of time to completely roll out. In fact, even greenfield projects are still adding a mix of APL and 4-20 instrumentation. So, we aren’t there yet.

But there is optimism around it. We got into that discussion during a recent webinar I hosted with a pair of experts from Beckhoff when we discussed how smarter I/O can help optimize operations. And, if you are a regular reader of Control, you will have read about Ethernet-APL and I/O in several place, most recently in a column by Ian Verhappen.

So it’s a reality and we’re at the doorstep.

With that, I want to ready this column from Jonas titled, “Ethernet-APL becomes a reality” and the future is one Ethernet-APL cable supporting all kinds of field devices, not just instrumentation.

Jonas writes:

There are several bus technologies such as Profibus, DeviceNet, HART and Modbus/RTU using different cables, interface hardware and data formats. They can be frustrating for 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 one fieldbus for all vendors to implement and deploy, but since the technologies are good at different things, it didn’t happen. It must be stressed that, within their niches, each bus successfully enables interoperability.

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 them. Similarly, each user tends to prefer one bus technology over the other for technologies with comparable capability.

Multiple bus technologies are frustrating for users, who must deploy multiple, parallel infrastructures across their plants to support a mix of field instruments, motor controls and miscellaneous devices. They must also add coaxial-cables for process video. Multiple bus technologies are also frustrating for vendors, who must support multiple product lines because bus technologies use different interface hardware.

Both users and vendors want a solution. Users want one infrastructure that can support multiple protocols for connecting field instruments, motor controls and other devices. Vendors want one instrument model that can support multiple protocols and satisfy all users.

The solution is the same as in the office and at home—Internet protocol (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’s well established in automation.

However, regular Ethernet isn’t suitable for field instruments due to limited cable length, separate power requirements and hazardous-area restrictions. IEEE recently created single-pair Ethernet (SPE), providing power and communication over just two wires and reaching up to 1 km. The four leading, industrial-protocol, standards-development organizations (FieldComm Group, ODVA, OPC Foundation and PI), which previously had different bus technologies, recently 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’s suitable, not only for field instruments such as transmitters and valves, but also for other kinds of field devices. APL simultaneously supports IP application protocols from all four organizations, namely HART-IP, EtherNet/IP, OPC-UA, Profinet and others like Modbus/TCP. APL also supports information and communication technology (ICT) protocols, such as FTP, HTTP and SMTP. Users’ longtime desire for one network infrastructure using a mix of protocols is becoming a reality.

The vision for the future is a single Ethernet-APL cable infrastructure that supports all kinds of field devices, not just instrumentation. Ethernet-APL instruments will not be lower-cost than 4-20 mA instruments, but one infrastructure will cost less than multiple infrastructures. APL is fast at 10 Mbit/s, which is 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.

One 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 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) about 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.

A key success factor for IP, Ethernet, Wi-Fi and the Internet is they’re all designed to carry multiple application protocols. No single application protocol attempts to perform all functions. There's 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, and Modbus/TCP for miscellaneous things. Automation systems will have to make the protocol transparent to users.

But don’t take multiple protocols too far because some flowmeters use HART-IP, while other flowmeters use Profinet, and some use Modbus/TCP. Using all of these protocols would be difficult to support. Try to stick to one protocol for instrumentation, one for motor controls, one for cameras, and so on.

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 show up 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 will all have one thing in common—the HART application protocol. They’re 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. Because HART-IP is an instrument protocol, not a PLC protocol, it makes APL less complex, so the learning curve to adopt APL is 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. In fact, it’s 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.

Automation designers will have to think less about cable selection for various buses. Instead, see what new field devices are available with APL, and select a control system that supports multiple application protocols to meet the needs of instrumentation, electricals and beyond.

So, what’s your thoughts on all of this? I’d love to hear it. You can always email me at [email protected] and if we get enough comments, we’ll revisit them on next week’s podcast.

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.