Single Pair Ethernet Driving IP to the Edge (Part 2)

SPE

In my last article, I discussed the current trends that are driving the transformation of manufacturing. SPE is one of the factors compelling many manufacturers to move from simple systems to complex mechanisms for predictive monitoring, analytics, and enterprise-wide connectivity. In this article, I’ll discuss some of the complicated issues that are currently limiting the deployment of Single Pair Ethernet.

Connecting sensors using Ethernet sounds like a very cool and straightforward idea – but like everything else “the devil is in the details.” Let’s look at a few of the hot topics that have to be addressed to make this deployable in our factories. None of these are insurmountable – just issues for both the manufacturers of SPE devices and the users that will deploy them on their machines.

There are both issues to solve for vendors building these devices and the users using them. Let’s look at the vendor issues first.

TCP/IP Stack – SPE MACs and PHYs are useless without a TCP/IP stack to provision them. TCP/IP stacks can be large and burdensome to small devices.

PROTOCOLS – SPE is protocol-agnostic just like all other IP media. The big question for vendors is support for IT or OT and what protocol to support. Should they support IT protocols like OPC UA, OPC UA FLC, MQTT, and HTTP with JSON encoding? Or support the kinds of protocols that manufacturers need: EtherNet/IP, PROFINET IO, Modbus TCP? Or support AWS and Microsoft Azure to get cloud connectivity? It’s enough to give product managers with sensor portfolios a massive headache.

Manufacturers also have their share of issues:

SENSOR CONFIGURATION – Somehow, a provisioning data packet containing the settings for SPE sensor (or other device) operation must be received such that the sensor can operate properly in that application. What does that packet look like? There are many standard mechanisms, and most communications protocols support their own. Sensor provisioning is a mess for manufacturers.

MESSAGING – Many of the supported protocols use a specific data model. EtherNet/IP uses an object model as does OPC UA, but they are different. MQTT has no data model. Many people use JSON. How do vendors provide those data models to their users? Where is the protocol-agnostic one?

DEVICE CONFIGURATION – Devices need both an IP address and an identity. The IP address can be obtained from DHCP, but how does a user easily know which device is which? If you have ten temperature controllers on a curing oven, which temperature is which?

INFRASTRUCTURE CONSIDERATIONS – Will these devices be hooked into the control systems? This hasn’t really been considered, and most people would think that since the switches and routers are right there on the machine already, we should use that infrastructure. That would be a mistake. There should be one hard and fast rule about your control infrastructure:

NO DEVICE CAN USE THE CONTROL NETWORK UNLESS IT IS PARTICIPATING IN THE MACHINE CONTROL!

Placing other devices on the control network – devices with unknown features and capabilities that might burst out data at any time – is not a risk that you should take. Unfortunately, many will take that risk instead of spending extra on a data network.

It’s indisputable that SPE is the new media platform to meet the high availability, high bandwidth, and fast transport required to support all the new, data-intensive sensors and appliances needed for autonomous vehicles and Industry 4.0. But even though the hardware is nearly ready, it may be a while before we sort out all these deployment issues.