The Case Against Time-Sensitive Networking – Is It the Next Segway?

Was anything ever as hyped as much as the Segway? Dean Kamen, the innovative designer who created the Segway and founded the Segway company, was a black belt in hype. In the spirit of PT Barnum, he built the product in “Total Secrecy” while, at the same time, making sure that every news outlet around the globe knew about the product being built in “Total Secrecy.” He proclaimed it revolutionary. He said it would change lives. Prior to revealing even what it was, he proclaimed it as one of the most profound products of the 20^th Century. And then, on Good Morning America in December 2001, the product was revealed. And today, nearly 20 years later, we’re still waiting for it to change life as we know it. Do you know anyone that has a Segway in their garage that they use for shopping, visiting the neighbors or walking the dog?

Which brings me to TSN – Time Sensitive Networking – a very well-hyped technology from Cisco, National Instruments, and others. Even trade associations like the ODVA and the OPC UA Foundation are getting in on this. They should know better.

TSN is trying to solve problem of determinism on the factory floor. Determinism that we can’t get with EtherNet/IP, Profinet IO or Modbus TCP. Today, we do it a couple of different ways. But remember, there are few applications that really require real time response. In some cases, we just isolate the controller and the devices that need “near real time” operation on a sub segment of Ethernet. Without other traffic on a segment, those devices can get (good enough) deterministic behavior. Or we use a special technology like Sercos, EtherCAT or Profinet IRT that provides (good enough) deterministic behavior. I’ll say it again, good enough deterministic behavior is what most, probably 98%, of all applications need.

Now the trend is to integrate a lot of IT and OT devices on the same network. There are advantages to having your EtherNet/IP Robot and controller on the same network link as your manufacturing databases, MES systems, Cloud connections and more. If you see value in any of that, Ethernet isn’t such a good choice because Ethernet with its CSMA (Carrier-sense multiple access with collision avoidance) architecture means that you never really know how long it will take to get a message through the network. Essentially, your maximum jitter time can approach forever because your message may never get through. (Jitter is the deviation from true periodicity of a message).

TSN could solve this problem but it’s like using the handle of a screw driver to pound a nail (I tend to do that kind of thing). You can get it done like that but it’s tedious and cumbersome. With TSN you have to have special switches and routers that are all TSN enabled. Hmm, anyone think they’ll be less expensive than standard switches and routers? And you have to have a “Director” that will take all of the requests for bandwidth and figure out what to tell each router and switch about the bandwidth they need to reserve and at what time. It’s all very complicated and possibly undoable. In large networks, you’ll need a CRAY computer to do that analysis.

There’s a much simpler way – MUCH SIMPLER. Answer this question. We’ve gone from 10Meg Ethernet to 100Meg to 1Gig, right? Are we going to stop there? Is that the end? No more speed increases, right?

Of course not. We going to have 10Gig, 100Gig and maybe 200 or 400Gig. With all that speed and all that bandwidth, we’ll have probabilistic determinism. That means, that just by chance, because there’s a gazillion network slots available, devices will mostly communicate deterministically all the time. And that will be good enough for 99.9% of all applications at those speeds.

Trust me on this. TSN is the next Segway. You don’t have a Segway in your garage and you won’t have a TSN network in your factory.