1660316679205 Smartprocesscellatprocterandgamblescetlab

P&G gets simpler, smarter with Ethernet-APL

May 19, 2022
Procter & Gamble's Smart Process Cell demonstration tests Ethernet-Advanced Physical Layer (APL) to streamline networking, automation and process control

Many businesses and industries scaled back or shut down during COVID-19, but consumer packaged goods (CPG) didn't, and often expanded operations because so many people spent more time at home during the pandemic and needed more CPG products. As one of the world's CPG cornerstones, the Procter & Gamble Co. also needed to maintain and frequently ramp up production to meet recent increases in demand.

"We generally performed well during COVID-19. We kept our staff safe, continued serving consumers, and contributed to our communities," says
Paul Maurath, technical director, Power Control and Information systems, Corporate Engineering Technologies, P&G. "This means relying on many types of automation for operating sophisticated, high-speed machines and packaging equipment for bottles, boxes and bags."

To continue accomplishing its performance objectives, Maurath reports P&G began talking 18 months ago with its suppliers that are members of the Ethernet-Advanced Physical Layer (APL) organization about developing an Ethernet-APL demonstration project at the company's Corporate Engineering Technology Lab (CETL) in West Chester, Ohio. The demo was implemented on the lab's Smart Process Cell (SPC), which is used to research and demonstrate process automation technologies.

"We asked them to show us what they had, began installs in late 2021, and have a system that's been up and running for a few months," says Maurath. "We're planning on sharing what we learn, including how to address challenges for the global supply chain, and what other users need to implement Ethernet-APL technologies."

Maurath presented "It's Not Enough to be Smart: a User's Perspective on Smart Process Instrumentation and Networks" on the second day of the ODVA Industry Conference and 21st annual meeting on March 10 in San Diego.

Networks fall short

Maurath explains that he and his P&G colleagues were inspired to investigate Ethernet-APL to improve on the capabilities of existing process instrumentation networks in CPG applications.

These networks are typically:

  • Dominated by conventional I/O that's highly distributed on an Ethernet backbone;
  • Provide widely available HART protocol for analog devices, though it isn't used much; and
  • Employ discrete, simple, on/off devices
  • Usually run on an isolated private network.

"Ethernet is become more important, penetrating further down into network architectures, and taking over distributed I/O, all kinds of drives, and complex, multivariable, four-wire instruments," says Maurath. "We have I/O level networks today with as many as 80 devices, including flowmeters, drives, remote I/O, load cells and numerous switches.”

Maurath adds that P&G also wanted to investigate Ethernet-APL because "smarter" devices such as Coriolis flowmeters, pH transmitters, radar level gauges and pressure transmitters have more data to share, more upper-level systems such as maintenance and data analytics want that information, and they all need more effective networking to do it. Likewise, many discrete devices such as on/off valves are networking with IO-Link (io-link.com) field device protocol, and delivering even more data.

"However, these key process industry needs aren't met by mainstream, IT-based Ethernet technologies," says Maurath. "We've seen random shutdowns caused by communications failures traced to Ethernet cable problems like bending the cable too tight. We need wiring that isn't so fragile, longer distance cabling that doesn't have to be fiber-optic, and wire than can better serve loop-powered devices and in electrically classified areas."

APL to the rescue

Because it was developed as single-pair, two-wire, intrinsically safe standard, Ethernet-APL can fulfill process industry requirements for twisted-pair cabling, deployabilty in electrically classified and hazardous areas, reaching longer distances, easier-to-handle technology, connectors for harsh conditions, and loop-powered devices. Ethernet-APL is based on IEEE 802.3cg-2019 for 10BASE-T1L, IEC 60079 and IEC61158 standards, and is independent of communication protocols.

These capabilities allowed P&G and its partners to design an architecture for their Ethernet-APL demo on the smart process cell in the CETL, learn what's needed to implement and maintain Ethernet-APL, and assess its potential benefits for the company. The SPC demo's equipment includes four tanks from 375 to 500 kg, six pumps with flowmeters, and three units performing continuous and batch operations. It runs water as its process fluid, and it's completely self-contained and remotely operated, so users can check on it from their desks or even while working from home.

Maurath adds that P&G also wanted to use the demo to learn about:

  • Basic installation and wiring of Ethernet-APL switches and instruments;
  • Instrument configuration and replacement;
  • Network and switch configuration and management;
  • Interoperability between switches and instruments from multiple vendors;
  • Instrument update rates and impact of faster communications compared to HART;
  • Access to multiple variables and diagnostic information;
  • Potential impact of higher power availability when converting from four-wire components to two-wire; and
  • Comparing Ethernet-APL to other protocols such as 4-20 mA HART and IO-Link.

"We did a similar demonstration project a few years ago to evaluate Foundation Fieldbus, and we did a hands-on build, but concluded it wasn't a good fit for our processes," says Maurath. "APL is attractive because of its speed compared to HART. Plus, though it's not possible with the present Ethernet-APL standard, we're hoping to get more power by converting to two-wire Ethernet from four-wire devices, and we're asking our vendors for help. Ethernet-APL can also interact with 4-20 mA HART and IO-Link. For example, if we're trying to get an echo curve from a radar level transmitter, it takes HART a long time to get that curve back, but it's a lot faster with APL."

While much of the SPC's automation network is the same as it was in 2019, implementing Ethernet-APL meant deploying several new components. The SPC already had a controller, HMI and server, historian, batch server, engineering station, conventional and remote I/O, and variable frequency drives. Its new items consist mainly of an APL field switch with APL level, pressure, and temperature sensors. At the same time, several additional IO-Link devices were also added to the system (Figure 1).

"The SPC already had several Coriolis flowmeters using Ethernet/IP, and the APL test added several new Ethernet/IP devices using the APL physical layer," says Maurath. "We found the biggest barrier in our initial benchtop tests of APL was assigning Internet protocol (IP) addresses. During initial testing we 'bricked' three prototype devices and could no longer communicate with them, so we sent them back to their manufacturers."

Figure 2: P&G's Smart Process Cell already had a controller, HMI and server, historian, batch server, engineering station, conventional and remote I/O, and variable-frequency drives. Its new items consist mainly of an Ethernet-APL field switch and many more IO-Link devices, which can bring in added radar level, pressure and temperature modules. Source: ODVA and  P&G.

Smart cell demo results

Maurath reports that field tests on the SPC included straightforward wiring, replacing 4-20 mA HART instruments, and parallel testing of multiple IO-Link devices. "We found that Ethernet-APL was completely 'invisible' to the controller, and that devices on the network looked like any other EtherNet/IP devices," says Maurath. "We learned that wiring was easy robust. And, overall, we're satisfied with our Ethernet-APL results so far. It works and does what it advertises."

Maurath adds that P&G was pleased with what it learned about installation and wiring between Ethernet-APL switches and instruments, and interoperability between components from different vendors. It was also happy with its access to multiple variables and diagnostic information. The prototype devices it's been using aren't really full Ethernet/IP devices yet, but Maurath is confident their problems will be ironed out, and P&G will see the speed and benefits it's seeking, especially with radar level instruments. The jury is still out on its other learning objectives

"We couldn't always get the access we needed when we put EtherNet/IP on top of the network, so sometimes we had to use a laptop PC to connect to the local subnet, and use specific HART IP connections. However, many of these devices are prototypes, so their issues will likely get straightened out later," explains Maurath. "My greatest request as a result of our demo project is 'help us manage complexity.' "

Help wanted with complexity

The SPC demo of Ethernet-APL at P&G also revealed some added challenges and tasks for the protocol and its developers.

For example, when replacing a 4-20 mA HART pressure transmitter in the field, the old one is removed, the new one is connected, and its range is configured. Meanwhile, the application/controller loses its connection to the old transmitter, gets a valid connection to the new one, checks scaling and begins to get a valid signal from it. "Once the controller sees the new device and check scaling, variables can be set in the new transmitter, and the process can be back up in a short time," adds Maurath. "Most importantly, the E&I tech can do all this with existing tools, and know the new device probably works."

Ethernet-APL: The supply-side update

It’s been almost a year since the final specifications for the Ethernet Advanced Physical Layer (Ethernet-APL) standard were announced, and the supplier community—which is represented by the 12 instrumentation and control system supplier and four standards development organization (SDO) members of the Ethernet-APL Project—have made substantial progress towards their ultimate goal of creating an ecosystem of commercially available instrumentation, infrastructure and host devices, which can work together to make the promised benefits of the new field network a reality.

That said, things haven’t proceeded as quickly as one might have hoped, in no small part due to the same constrictions in silicon and printed-circuit-board supply chains that have plagued other sectors of the global economy. Further, as of press time, only the necessary protocol conformance tests for HART-IP had been finalized, and were still under development for Profinet and EtherNet/IP.

And beyond protocol testing, new Ethernet-APL products must also clear independent intrinsic safety certification for deployment in hazardous environments, another hurdle likely to add months to a new product’s formal release cycle. Switch suppliers (for whom protocol considerations are secondary) including Pepperl+Fuchs, Phoenix Contact and R. Stahl are early out of the gate with announced products. Meanwhile, progressive users such as P&G and BASF are kicking the tires primarily on prototype products; supplier members of the Ethernet Project, too, are freely swapping prototype products to verify interoperability as well.

Despite the hurdles, supporting suppliers and SDOs have planned an ambitious, coordinated display at this summer’s ACHEMA trade show, to be held Aug. 22-26 in Frankfurt, Germany. Endress+Hauser, for example, intends to display its first portfolio of commercially available products to be released yet this summer. Included are eight flow, level, temperature and pressure instruments as well as Ethernet-APL support for its FieldCare, Field Xpert and Netilion system offerings.

However, replacing a smart pressure transmitter or other device linked to and communicating via EtherNet/IP or IO-Link still means removing the old device and connecting the new one.

But, its communications must also be configured, and this means making answering several new questions:

  • How does the new device communicate?
  • Is its new configuration file available?
  • Does the controller have to be restarted or reloaded to reach the new device?
  • Is the data structure the same for the new device, or does application code have to be changed?
  • How long will it take to get these tasks done and get the process back up?

"To add or replace smart devices, users have to configure communications and do a lot of other steps, such as adding IP addresses, or finding out if they need a new configuration files or EDS, and they can't really be sure it works until they do," explains Maurath. "If a new device was in storage, can it use the same firmware, or is a revision needed? Or, what level of change is needed for it to reach the controller? Were the names of key variable been changed in the firmware revision? And, what skills do the E&I techs need to do these installations and complete these configurations, so they can get up and running?"

Likewise, if E&I technicians on the 3 a.m. Sunday shift at P&G have a problem with a regular 4-20 mA device, they can do a lot to handle it with their usual hand tools, digital voltmeter (DVM) and HART communication. However, if they're working with a smart device, they may have to deal with items they're not prepared for today, including new and more complex technologies such as Internet protocols like BootP or dynamic host configuration protocols (DHCP), I/O device descriptions for IO-Link, electric data sheets (EDS), device profiles, firmware revisions and data models.

"How long will it take to get someone with the right skills to fix the system?" asks Maurath. "If I have to call a systems integrator engineer and they are not available until Monday morning, the plant manager will be very unhappy."

Reduce configuration confusion

Maurath reports that P&G and other end users need help with communications, notably IP address assignments, which includes how to handle DHCP, BootP, local displays, dip switches and selector wheels. They also need assistance with EDSs, I/O device descriptions (IODD) and other configuration files and drivers, as well making it easier to replace "like for like" components. "Assigning IP addresses is a pain, but it's even more of a problem for E&I techs on that 3 a.m. shift," he explains. "They may have a laptop PC, but if it doesn't have the files they need for a new device, they're dead in the water. It's got to be made easier than it is today to import files and get them to live in the controller."

Maurath reports that configuring smart transmitters and other devices is also confusing because there are so many ways and places to do it, such as on local displays, field communicators, controller programming software, asset management systems or web-based interfaces. "Do they all show the same information? Not today. So who has the master copy?" asks Maurath. "There's no easy way for controllers to upload configurations for field devices. Consequently, if a technician adds a filter to a device, a master controller may come along later and wipe out those changes.

"We have a lot of fog-type computing at P&G with local, virtual-machine servers or stacks, so we're aware about the move to cloud computing and less controller-centric applications that use different protocols," adds Maurath. "Smart devices are complicating our world, so it's critical for us to have standards that allow them to work together despite their alphabet soup of protocols. The market will decide which standards succeed, but we still need simple, functional technologies that are easier to implement, maintain and migrate over time."

About the author: Jim Montague
About the Author

Jim Montague | Executive Editor

Jim Montague is executive editor of Control. 

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®.