As an editor who’s covered the rise of Time-Sensitive Networking (TSN) over the past few years, I often receive questions about the developing standard and I do my best to connect questioners with experts who are well-suited to provide answers. Recently, I was forwarded a copy of a newsletter from system integrator Real Time Automation. In the November 2018 edition of the newsletter, a number of valid questions were raised about TSN.
The questions included:
- What percentage of devices really need the level of determinism provided by TSN?
- Couldn’t faster bandwidth solve the determinism requirements rather than developing a new standard?
- What does the term “centrally managed” meanas it relates to TSN?
A couple of years ago, I met Oliver Kleineberg of Belden at the IoT Solutions World Congress and ever since he has proven to be a reliable source of information about TSN and development surrounding the standard. I reached out to him for answers.
Determinism
The newsletter states: “… we need determinism in motion applications. It seems clear to me that, with mechanical systems, there is a physical limit to how fast things can move and it’s a lot slower than a bunch of electrons. We are never going to have applications requiring nanoseconds of jitter.” So just how many devices really need TSN levels of determinism?
Kleineberg responded to this question by first noting that TSN is a set of standards, not a single standard. "The different components of TSN can be combined to scale the performance (and also the costs) of devices up and down, depending on the application requirements," he added. "The full level of performance will only be required in the area of synchronized drives and motion control. In this case, where we are at the borderline of what physics allow, we are talking about cycle times in the low 10s of microseconds and jitter—approximately one order of magnitude lower. Anything lower than that can currently not be considered a ‘normal’ application/use case. You will find those rare requirements in applications like the control network for the large hadron collider particle accelerator.”
Kleineberg further added it's conceivable that one day harder requirements will be more common. To ensure TSN can cover all of the different requirements in device costs and performance, TSN can scale—device vendors can choose to implement only some of the TSN standards; that is, those that are needed [now] to support the application.
Bandwidth
In the Real Time Automation newsletter, the point is made that “1Ghz Ethernet is now common. Does anyone believe it will stop there? Does anybody believe that in three years we won’t have 10Ghz and within five years, 100Ghz or even 200Ghz? We may need fiber or some other kind of media, but it’s clear that our networks are going to get faster. And when they do, we can use something called probabilistic determinism—big words that mean at high speeds there is so much available bandwidth that packets will arrive consistently with almost non-existent jitter. Combine that with a clock synchronization protocol like IEEE 1588 and the problem is solved for the vast majority, if not all, of our applications requiring some level of determinism. And without having to purchase and maintain some very highly complex, critical piece of software infrastructure.”
According to Kleineberg, a major caveat to this approach is safety. “Whenever safety or critical applications are discussed, probabilistic determinism is not good enough—even if the statistical chance is minuscule.”
If the maximum size of an Ethernet frame is not changed in the foreseeable future, said Kleineberg, the transmission time of a frame and the queueing time in the switches (e.g., a single 1522 octets frame) may be so low that they can be tolerated by even the most demanding applications. “But this requires your control traffic to exclusively occupy the highest priority/queue—and such guarantees then can only be given for a single, highest, priority," he said. "A very important value proposition of TSN is that it enables the use of different levels of determinism in one network—each with its individual latency jitter requirements guaranteed. This becomes more and more important as the bandwidth in automation network increases.”
Kleineberg added that there are also the aspects of costs and power consumption in devices on the field layer to consider. “For the foreseeable future, these devices will not scale up to 100Gbit/s or beyond,” he said.
Central management
Another question revolved around Cisco’s definition of TSN, which reads as follows: “TSN is the IEEE 802.1Q defined standard technology to provide deterministic messaging on standard Ethernet. TSN technology is centrally managed and delivers guarantees of delivery and minimized jitter using time scheduling for those real-time applications that require determinism.”
In the newsletter, the concern about this definition focused on the words “centrally managed.” The newsletter article notes that this reference indicates "there is some central piece of software that is going to receive and process requests from all the devices needing deterministic delivery. Once it has that list, it must determine the timing and the path through the network for those messages. Then it must ensure that every router and switch in the network reserves the bandwidth for those messages. And it’s going to do that for some of these sizeable networks that we find in large manufacturing facilities. That is a very difficult software problem, far beyond the computational resources typically available on the factory floor.”
The newsletter also noted that companies who are heavily investing in TSN have been asked to identify who is going to provide the centrally managed software, and the answer always received is “not us.”
Kleienberg responded, “We anticipate that the CNC (Centralized Network Configuration) software will have to come from the network vendors, such as Hirschmann, Cisco or others. We are currently developing our CNC and are working in standardization to ensure we have all the interfaces in place for the end device vendors.”
He added that the CUC (Centralized User Configuration) is expected to be delivered by the device vendor, as this software is the management interface from their device to the network. "The CUC from the vendor then interacts with the CNC," said Kleienberg. "The relationship is a logical N:1—one CNC (redundant setup, of course) and multiple CUCs from different vendors, communicating with the CNC (requirements, stream reservations, etc.). The CNC, in turn, manages the network."
