Remember the days of RS-232-C, the serial data protocol that was used for interfacing devices to control systems? Devices such as marquee displays, HMI, SCADA systems and in fact PLC-to-PLC communications proliferated control system designs and are still in use.
However, there has been a new sheriff in town, and it is called Ethernet. I am sure that most if not all devices are implemented with Ethernet. The advent of Gigabit Ethernet allows for pseudo-real-time communications.
I call it “pseudo” since Ethernet is a nondeterministic infrastructure. It employs carrier-sense multiple access with collision detection (CSMA/CD) for half duplex networks, which still may be used in legacy systems. Older wireless systems would employ half duplex for communication stability.
Most now would use full duplex, which means that the Ethernet interface can send and receive at the same time. Gigabit Ethernet will only use full duplex.
However, like dinner-conversation protocol, only one device can talk to another device at a time, so if a second device needs to talk to the first device it has to wait until the communication packet from the talker to the listener is completed.
And therein lies the rub. How long does the second device have to wait, and in fact will it be the next in line to communicate to the first device? In a control network there may be multiple devices talking to each other so the management of the network is needed, which is done by the hardware interfaces.
Ethernet switches were introduced to manage full duplex networks. In the early days we used hubs which transmitted the data to all devices connected to the hub creating collisions. With switches, managed or unmanaged, these collisions are removed since the switch manages the traffic flow and sends the desired communication packet to the proper device using the destination TCP/IP address that identifies the device.
In operational-technology (OT) networks these IP addresses are typically static and determined by the controls engineer.
An OT network is so different than an information-technology (IT) network. A common description of importance is office email. You can be without it for some time. In the OT world if communications are lost for even a minute the process and production are impacted.
In normal applications, Gigabit Ethernet is fast enough. It may not be real time as such but in most cases the data that it is transmitting may not be time-sensitive. We also think that the data pipe is so big we can pump anything through it.
This is not true. You must always be network-aware so as to not saturate the network segment, which will lead to reduced successful communication between devices.
The use of fiberoptic cable has been employed in order to reduce transmission times across long distances that either exceed the distance requirement for Cat. 5/6 cable or the user simply wants to have the fastest transmission time possible.
For those applications that require a true deterministic network, time-sensitive networking (TSN) has been developed to allow for deterministic delivery of messages between devices that support TSN.
TSN is supported by an organization called the Avnu Alliance, as well as the Industrial Internet Consortium (IIC). TSN is the IEEE 802.1Q-defined standard technology to provide deterministic messaging on standard Ethernet cabling.
With the advent of 5G wireless specifications, time-sensitive communications over wireless networks can also be experienced. Development of the 5G ultra-reliable low-latency communications mode allows industrial applications such as automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) to better integrate with warehouse management systems.
Doing a bit of a dive into TSN, it is clear that you need the hardware to support it, as well as the production/process need for deterministic communications.
Also read: Why time-sensitive networking will change everything
There are five components of TSN solutions:
- TSN flow
- compatible end devices
- special bridges used for segmenting networks
- a central network controller that defines a schedule for data transmission
- a centralized user configuration, which is vendor-specific to schedule communication packets based on time.
In order to implement TSN, all bridges/switches and devices have to be able to be configured for TSN. It is important to note that non-TSN communication packets can still be transmitted but will take a back seat to the TSN packets.
In my experiences I have had to create network-aware applications that don’t slam the network with communication requests. Even now, with remote pumping stations over cellular networks, I have had to schedule the communications so as to not create a communications nightmare. TSN would solve this dilemma by managing the communication packets based on time and not event.
We have an exciting future in the networking world. Learn it well.
