Rockwell Automation’s Data Highway Plus and Modbus were two of the original hardware and software solutions for networking multiple devices. Limitations were many, and speed and distance were also an albatross to the controls engineer.
They had to keep packet sizes small and messaging infrequent; plus, too many devices would load up the network with chatter. The other issue was, when an interface failed and communication was interrupted, the process sometimes took seconds to identify that there was an issue due to the long messaging timeouts from to the round trip communication timeframes.
When Industrial Ethernet came on the scene using ARCNet and coaxial cable, we were ecstatic. Finally, there was a deterministic fast network that came from the commercial marketplace, but one we needed to harden for our environment. And we did.
Then came 10BASE-T Ethernet—wow, 10 MBaud. Vendors took the easy way out and took their serial protocols and wrapped them up in an Ethernet packet and frames, so they could use this new technology. One problem was that some protocols were time-based due to firmware in the devices. Certain commands had to show within a certain amount of time, and if they came too fast the communication conversation failed and had to be retried.
Ethernet uses code division multiple access with collision detection (CDMA/CD), which allows any device to talk at any one time. Whoever gets the token first speaks, then goes off-line for a predetermined time, which is random, so that no one can hog the network.
And there is the rub. Someone can own the network due to interface chatter, messaging retries, cabling issues—connections and distance with possible external interference—and bad code.
One common messaging parameter is a timeout value, which suggests that the message should complete after x milliseconds. If it doesn’t, then the message is deemed to fail, and retries occur based on code.
One application that I was involved in used a Unix communication application that downloaded database information to a Rockwell Automation PLC. The timeout was set at 3 seconds, which was OK for the application.
However, when the port on the switch that the PLC was connected to started to chatter, the PLC was unable to transmit reliably. The Unix app interpreted that as, “You didn’t get my command,” and thus rejected the product, creating much extra work for the operators. They would have to observe that too many rejects were happening and thus an investigation would occur.
That application was time-sensitive, based on code, not on the network parameters. Some argue that Ethernet cannot be used for time-sensitive applications due to process lag and dynamics. Imagine a control valve getting a position command from a closed-loop process and then getting another one 3 seconds later due to communication delay from the positioner. You will have an unstable loop.
Ethernet has provided us with a platform for ease of use, speeds and the use of fiberoptics to take care of distance limitations of Cat. 5/6 Ethernet. Even wireless networking has been used in certain applications, but they better not be time-sensitive. We know from our home wireless routers that packets get dropped in a regular fashion, and interference can play a big part.
So enter the IEEE 802.1 TSN task group. TSN stands for time-sensitive networking, which is a subset of Ethernet standards. The essence of TSN involves a convergence of IT and OT technology. We are not in Kansas anymore.
Data is everywhere. IT systems need and want data from the processes and the edge and the IIoT devices that are out there making things happen. And the MES and inventory systems want that information right now.
The process-monitoring software (SCADA) needs it now, and high-value HMIs need it.
And when do they need it? Now.
TSN will make processes predictable and reliable and will have control over the latency of real-time critical data that the process needs to deliver to the infrastructure. And they want to do it with vendor independence. We have that now to some extent with standard Ethernet, but with the new protocols that will be developed, running a variation of devices over the same pipe and the same protocol has its advantages.
ALSO READ: The accumulating case for deterministic control
Having a time-based protocol may change the way we design systems and use devices in our processes. If we knew that information would be there in x milliseconds, then could the next command be time-based and not transition-based?
TSN is in development. We have come a long way since serial comms and ARCNet. We are entering a new world where OT will need IT skills and vice versa.
