Welcome to today's InnoTalks session, which is about Time Sensitive Networking, or TSN. Like many of our InnoTalks topics, it's been getting a lot of press coverage recently as one of the emerging technologies with the potential to have a transformative effect on both the automation industries and on the convergence of OT and IT systems. But why is this? 

In this webcast, we'll be discussing the problems TSN solves and how it does it. We'll be giving you some feeling for where it should, and just as importantly, shouldn't be applied. And we'll be looking at what a practical implementation strategy would look like given the Brownfield nature of most industrial deployments. We'll also do a bit of crystal ball gazing into the future of both the core technology and of the industries that adopt it. 

Hopefully, by the end of today's session, you'll have a better understanding of the benefits TSN can give you and where it will bring you the most benefit, essentially, what adopting TSN will enable you to do that you can't do today. We'll also look at how it achieves this, what it can and can't do, and how to start implementing TSN in your applications. Of course, we'll also let you know what we're doing at Advantech and how we can help you along this journey. 

To help me, I'm joined by two gentlemen with a wealth of relevant experience. Brendan Mullooly is Advantech Europe's Business Development Manager for Connectivity Solutions. With a strong background in network communications, he'll help to explain how the underlying technology works and why it represents an evolutionary step rather than a revolutionary one. 

Peter Lutz is the Director of Field Level Communications at the OPC Foundation. He'll be helping us understand how a TSN infrastructure can be leveraged by the application and communication layers that sit on top of it to provide real end user benefits. Gentlemen, welcome. 

Problem TSN Addresses

[Host]- I'd like to start by identifying the problems that TSN addresses. Peter, perhaps you'd like to pitch in here? 

[Peter Lutz, OPC Foundation]- Yeah, actually, when we look at today's situation, we recognize we have very different real-time ethernet solutions that have been developed and that are used in the industry. And although they are all part of international standards, at least most of them, they are all incompatible with each other. 

Typically, as soon as they want to achieve a certain performance, they need specific hardware, not the standard ethernet controllers. And in addition, most of them even cannot coexist in a common network infrastructure. So this has led to the situation that we have different ecosystems built around some of the major automation suppliers. 

But this has now raised an extreme complexity and also significant costs for users and suppliers that deliver and need to support these different ecosystems. And this is where TSN comes into play, because this is technology that is able to harmonize, so to say, this situation. 

How Does TSN Solve Problem?

[Host]- So we're talking about a common communications infrastructure for an entire system. That covers not only the time-sensitive or the time-insensitive IT and soft real-time monitoring needs, but crucially can also provide for the hard real-time elements in the production process. That's obviously paving the way for greater digitalization across an entire business, which in turn is going to produce economic benefits. So if TSN is emerging as a solution for this, what exactly is it? And how does it work? Brendan, perhaps you can help us with this. 

[Brendan Mullooly, Advantech]- I sure can, Tim. And thank you for the invite. And thank you, Peter, for the great introduction there. Ethernet, as we all know, is the dominant communication technology. We're used to it in the world of enterprise, MIS, in the world of OT automation. Obviously, it has superseded the older field bus standards based on RS whatever. 

Ethernet is great. As Peter mentioned right at the beginning, ethernet is a standard. And the key thing about being behind or using a protocol or a system that is a standard is you have total interoperability. And of course, for the users, the benefit there is because it's a standard, everything gets a little bit cheaper because we have many competitors out there. 

And ethernet is great. Ethernet works brilliantly. But the problem with ethernet is it's not what you might describe as deterministic. Ethernet is what we call a best effort delivery system. We have QoS standards, which obviously helped. But in the world of industrial automation, QoS may not cut it. 

[Host]- So what do you mean by best effort? 

[Brendan Mullooly, Advantech]- Best effort essentially means ethernet from its early days was essentially a shared media system. Then we moved on to ethernet switches. Then we developed quality of service standards. But still, at this day, I cannot with ethernet guarantee the data from point A will be delivered to point B within a certain time frame. 

[Host]- And TSN addresses this. But how does it do it? 

[Brendan Mullooly, Advantech]- Well, TSN, the way TSN is being developed is to essentially allow ethernet to become deterministic. Deterministic essentially means that, as I said earlier, delivery from point A to point B can be done within a certain time frame. The TSN standards allow this to happen based, as I said earlier, on the triple-- the typical IEEE standards. 

[Host]- And actually, on the network, what's happening? There's doing something with slicing packets up differently or something, isn't it? 

[Brendan Mullooly, Advantech]- Yeah, absolutely correct. What we're essentially doing with the ethernet frame or the ethernet bandwidth-- and as we know, ethernet started off at 10 megabits per second. And now, we're moving up to 100 gigabits per second, which obviously in the automation world, we won't see yet, maybe in the future. But essentially, what we're doing with TSN, as you said, Tim, is we're taking the ethernet data flow and slicing it into, yeah, portions. Time slicing would be a typical way of describing it. But we call them, essentially, streams within the world of TSN. 

[Host]- Ah, OK. And they get synchronized across all the units that are in the TSN network by some central clock. What about redundancy? Because it's all right having deterministic data. But it's still actually got to get through if it's mission critical. 

[Brendan Mullooly, Advantech]- Yeah, absolutely correct. You hit the time slicing or the time synchronization. Obviously, if you have a series of example switches in a line, when you have the stream coming through, obviously, each switch needs to know what time segment the string needs to be in. So you're absolutely correct with the time synchronization. When it comes down to the actual slicing itself and the delivery, yeah, it exists. And it's happening now. 

[Host]- And as you said, it's covered by a suite of standards. It's not just a single one. There's actually a whole load of different standards that go to form the TSN network. You've spoken about hard real-time. What levels of latency are actually achievable? 

[Brendan Mullooly, Advantech]- Well, again, it depends literally on the hardware you're using. But we're looking at, roughly, latency on a high-priority stream of between one to two milliseconds. The key thing, though, is on the actual ethernet data stream. With a high-priority stream, we're offering 125 microseconds for each time segment that can come through. Latencies, obviously, one of those great things which can be difficult to measure. 

If you go in port A, out port B, that's easy to measure latency. But if you have several devices in the connection, obviously, latency is more difficult to measure. But at the end of the day, we're aiming for one to two millisecond delivery, which is aimed essentially for the challenges we have in a lot of automation style applications, motion, safety, synchronization between machines on the factory floor, or, and as Peter will talk about later, synchronization across the IT level between factories as well. 

[Host]- And what's the impact on the remaining traffic? If we're reserving time slices for the high-priority stuff, there's got to be some tradeoff. Presumably, everything else runs more slowly. 

[Brendan Mullooly, Advantech]- Yes and no on that one. Essentially, what we do when we create a TSN connection or a TSN link, there is something we call a guard frame available. Into that, we can put the non-TSN traffic. That will be transmitted. So that's one of the great things about TSN. We can bring a TSN installation into a factory, into an automation system. 

And still, yet, the standard ethernet traffic will be delivered within acceptable ethernet parameters. It's just, the key thing with TSN is the ability we have with the standards to be able to deliver time-critical important information within specific windows or specific latencies. 

[Host]- So if it's an extension of the current ethernet standards, can it coexist with an existing ethernet deployment? Or does the entire network need to be TSN-aware for a system to work? 

[Brendan Mullooly, Advantech]- No, it will happily co-exist, Tim, as I mentioned earlier on. We can put existing ethernet frames through a TSN infrastructure, be it switches, be it, for example, IPCs or whatever. We can do that. This is not like you have to rip everything out of your factory, everything out of your machine, and building new devices. They will happily co-exist. And one of the key things behind TSN as well is we do communicate or we do work with the higher level industrial management protocols, for example, Peter with the OPC UA Foundation with their work with TSN and the IEEE. 

TSN as a Solution

[Host]- So presumably, all of this doesn't just happen. There has to be some level of user configuration involved. How's that done? And what are the pitfalls to be aware of when you're configuring a system? 

[Brendan Mullooly, Advantech]- Yeah, obviously, you need to configure something. It's not like you plug it in and it suddenly works. Similarly, I often draw when I'm talking with people about TSN is IEEE VLANs, the 802.1Q, for example. You need to configure VLANs on the switches for VLANs to work. It's a similar approach with TSN. The TSN traffic has to be identified. It could be port-based, layer two, layer three-based, and then prioritized within the TSN system. 

Now one thing Peter will talk about later is the IEEE is working on standards, whereby we will have a template, you could say, specifically designed, for example, since automation is the main target for TSN at the moment, template-designed for automation TSN time-sensitive delivery. 

[Host]- Peter, what Brendan's been talking about has all really been network layer two stuff. What happens when we start looking at the higher levels in the communication architecture? For example, how do you leverage TSN in OPC UA? 

[Peter Lutz, OPC Foundation]- Yeah, for us, for the OPC foundation, TSN is really a key enabler in order to extend the use cases and the areas of application that OPC UA is already covering today. So OPC UA with TSN allows us, really, to bring our technology into applications that need deterministic behaviors that need real-time, so motion control, distributed real-time I/Os, also process control. 

And we have a dedicated initiative that we started a few years ago, the FLC initiative, which is working on the extensions of what we call the framework, the OPC UA framework, to extend OPC UA for all these field-level-related applications. And this includes functional safety motion control and highly leverages, certainly, tiers. 

And even OPC UA itself is transport agnostic, and certainly can still run without TSN, and will run with other technologies in future as well. And what I think is also important to mention, that this is really supported by all the major automation suppliers. So this is not bringing up just another ecosystem. But it really drives harmonization. And the approach is to have one solution that is supporting factory as well as process automation. 

[Host]- And you've spoken about a lot of stuff that's happening down at plant-level and at the actual process level. How did it help with IT/OT convergence and digitalization? 

[Peter Lutz, OPC Foundation]- This is an excellent point because, as I said, it's not just about creating another ecosystem now using TSN. In the past, you were using real-time ethernet. Really, it's the vision of the OPC foundation, but actually of all the initiatives that are main industry 4.0 or the industrial internet of things, to really drive a complete, let's say, consistent interoperable solution that fully scales from the plant, from the field-level up to the cloud. And for this, you suddenly need technologies like TSN, because this is the basis. This is the foundation. 

But we need, certainly, a standardization on all the different levels. That means we need a harmonized application layer. We need common semantics because, finally, it's about, what is the meaning of the data? How do we come to vendor-independent information? And this is where OPC UA has, let's say, an ideal solution, including security, including the information modeling. And then, it helps to solve these challenges with the industrial interoperability. 

TSN for Brownfield in Automation Industry

[Host]- That all sounds great in theory. But what does this look like in real life? Could the two of you walk through a typical Brownfield installation, like we see in the automation industries? What has to be upgraded? What can be left? How is the migration managed? 

[Brendan Mullooly, Advantech]- Well, the migration is pretty straightforward, Tim. At the end of the day, TSN is ethernet. So the physical layer, layer one, what our installers and users are used to, it's the same, absolutely the same. The TSN switches, for example, which Advantech are getting heavily involved with, again, it's a switch. Everybody is used to that. Obviously, as I talked about earlier on with you, Tim, we need to be able to create the necessary rules and regulations for the TSN streams, or the time slicing, or whatever you want to call it. 

That's where people do have to get involved. Now Peter mentioned, I think, at the end of his speech earlier on or his comments earlier on, that we are generating profiles. We are generating the ability for a user to essentially implement a TSN infrastructure and then have, essentially, what you might describe as a template, which enables them to classify and control the traffic they want over the TSN network. 

[Peter Lutz, OPC Foundation]- Maybe I'm also jumping in here, talking a little bit how a migration towards TSN could look like. We certainly can still keep existing installations, for example, machines that are using now the existing technologies with the different real-time ethernet standards I was talking about. 

So in our view, we believe that in the first step, for example, such machines could be connected with a TSN network. We could establish OPC UA to drive more what we call the horizontal connectivity, horizontal communication, including, certainly, the scaling up to the edge. But this is just a first step because in the next step, certainly, TSN will move into the machines or into that specific installations. And with this step, then we bring, really, harmonization into the machines. This is more the vertical piece. 

Also, including now the higher layers and the semantics with OPC UA and the different companion specifications. And then, we really achieve one consistent solution that is fully scaling vertically as well as horizontally. But it's a step-by-step procedure. So I think Brendan made this clear. It's not a so-called disruptive technology. So we need not throw away all the investments. But we really can do a step-by-step migration towards TSN. 

[Host]- And when we're talking about not replacing everything, presumably, there's still a place for the protocol translation devices we've spoken about in the past. 

[Brendan Mullooly, Advantech]- No, absolutely correct. And my point, and, Peter, thank you for emphasizing it, this is not like you have to throw everything away and rebuild everything from ground zero. It's a continuous upgrade capability. We can use TSN, for example, within the machine even if the endpoints are not TSN-aware. 

And as Peter mentioned earlier on, though, we're already getting into the situation where the endpoints, for example, IPC's, also now are coming out that are TSN-aware as well. It's a gradual evolution, no questions about it. And we understand, Peter probably better than I do and Tim much better than I do, since you've been working in the industrial market a lot longer than I have, change comes slowly. 

And the key thing behind TSN is it's a gradual implementation. It's not like a big bang. Everything has to go. No, we can move forward slowly but surely on the implementation and, obviously, from Peter's side of things, integrating to the higher level management protocols like OPC UA, for example. 

[Peter Lutz, OPC Foundation]- Let me maybe mention one still, let's say, existing challenge. I would call it a challenge. Now as we all move towards TSN as that network infrastructure supporting these different protocols, sharing, let's say, the network and the bandwidth with all the different types of traffic and streams, there is still, and Brent mentioned that term profile before. 

Suddenly, one important precondition that this finally works is that all the different players in the industry are somehow agreeing to a certain profile. This is, for automation, the 6802 activity, joint effort IEC and IEEE, because TSN is something like a toolkit with different mechanisms. So there has to be a common agreement how to use that TSN toolkit and these standards, because otherwise you would have different, let's say, variations of TSN. And this is not helping us. So we really have to agree on how to use TSN in a common way. 

[Host]- So if this common profile still needs to be agreed, is that a risk for early adopters? 

[Brendan Mullooly, Advantech]- Oh, absolutely not, Tim. The profiles are essentially based on the IEEE standards for TSN, of which, if I remember correctly, there's 10 of them, including the redundancy profiles. So the actual physical side of things is all defined. Everything's ready. And as Peter mentioned, what we're doing or what the IEC/IEEE are doing is essentially generating a template of how to implement TSN in, for example, a machine for motion, for safety, machine communication, into machine communication on a production line. So there's absolutely zero risk. 

What to Expect in the TSN Future

[Host]- So the standards exist. Equipment is available. And there's no real downside to being an early adopter. So if a company jumps in now and implements a TSN network, what can they expect in the future from a technology standpoint? Brendan? 

[Brendan Mullooly, Advantech]- Well, obviously, yeah, TSN was actually based upon the audio-visual broadcasting standards the IEEE developed a fair few years ago. Essentially, the best way to look at TSN is it's time-sensitive delivery. At the moment and today, obviously, we're talking about implementation of TSN and automation, OT-style environments, which is absolutely critical. 

There's a lot of time-sensitive data running around, as Peter and myself have spoken about. But there's other areas where it's important, for example, transportation, ethernet-trained backbone systems. A train is a very complicated device, as we all know. And there's lots of cabling in there that can be up to four networks sitting within one train. Wouldn't it be great to be able to just create one network? 

Other area which is of interest, and this hooks in nicely to the developments in the world of cellular communications, is 5G. 5G, we have various standards. And it's still being rolled out. But one of the things 5G promises to bring is something called URLLC, ultra-reliable low-latency communications. 

This, again, is a guaranteed latency system over the cellular network. We do know there are chip vendors working at the moment on integrating TSN and URLLC. And one of the big target markets for that, obviously, automation. But the biggest one is autonomous vehicles. 

[Host]- Yeah, we've already got a number of 5G routers in the market. So I know we're tracking those developments pretty closely. 

[Brendan Mullooly, Advantech]- Oh, absolutely. It's 3GPP version 16 which defines the URLLC standards. It's slow on the rollout. But what do you expect? This is a major technology jump that we're actually delivering here. So it's going to take time. But you can see this happening. And especially in the automotive world, TSN on the component level inside your car is already being implemented simply because of the guaranteed delivery low-latency. 

[Host]- Yeah, I think there's a definite trend that the chipsets are going to become more ubiquitous. And that means they're going to become cheaper, which means we're going to start finding them in much lower order switches, and routers, and everything. Peter, from the application and business viewpoint, where will TSN take us in the future? 

[Peter Lutz, OPC Foundation]- I think what Brendan already mentioned is actually, really, the key for this success of TSN, it's used in so many different application areas, industries. Even I'm more from automation. It's clear that we all benefit from having a mainstream technology that is supported by all these chip vendors and, let's say, the toolkit providers that work on drivers and software for these chips. 

So we have it in automotive audio-video transportation. This is really bringing, also, automation in that direction to get away from, I called it, all these ecosystems at the beginning. Really, work towards a common ecosystem. And really concentrate on the applications. And not everyone is developing similar solutions for solving things that are already part of standards. 

We see already existing, let's say, solution providers moving to TSN in automation. So this can give us a confidence that this is fully understood by all the major automation suppliers. So this is creating a big momentum. And I think looking at the factories and plants, TSN will really enable these more flexible, these more reliable productions, where the network is granting certain quality of service to the applications, what we typically call the plug and produce concepts for the industry. 

And then, suddenly, I don't want to forget, as mentioned before, that TSN is the network. And we need, certainly, the higher layer harmonization as well with OPC UA that is fully transport agnostic and can work on top of such standards. Brandon mentioned an important thing. We talked today more about the wild connectivity, also in automation. But wireless is another key in future making the flexibility in production. So it's not only about that 5G or, in future, 6G. It's also Wi-Fi 6, Wi-Fi 7. So we will have much more flexible options in communication. 

[Brendan Mullooly, Advantech]- Yeah, Peter, you're absolutely spot on there. At the end of the day, TSN is an absolutely fabulous development by the IEEE. There's no questions about it. The deterministic delivery is critical and key. And it's a standard. But you still need to talk with the higher layer protocols. 

And as I mentioned and as Peter just mentioned a minute ago, TSN also will become transport agnostic. It will go over cellular. It will go over some form of Wi-Fi at the end of the day. And we're just at the early-- I wouldn't say the early stages. We already have TSN implementations alive, and well, and doing things. But it's a developing standard. And the key thing at the end of the day is that word, standard. It will interoperate. 

[Host]- Well, gentlemen, thank you very much for your contributions. I think we've covered a lot of interesting ground on what I hope our audience will agree is an important technology for the future. Advantech is obviously committed to TSN and already has a number of products available for users who want to implement systems. Brendan, perhaps you can just give us a brief overview of what's available today and what's coming along in the near future. 

[Brendan Mullooly, Advantech]- Oh, sure. No problems. We've already launched a TSN edge switch. And as I think I mentioned earlier, we have this live in production arenas with machine builders. Following on from the edge switch, we're also looking at creating a TSN core switch. And core, obviously, is a wonderful word to use. 

The reason we use the word core is, obviously, we have higher speed uplinks than the typical 100 meg or even gigabit that you'd use in the machine. And then, obviously, layer three capabilities. And to ensure that we can also approach another market we haven't talked about, which is the power and energy market, we'll look at the power and energy style redundancy systems. 

From the IPC, industrial PC side of things, we already have an IPC which is TSN-compliant. So all the necessary string classification is done within the actual IPC. And there's also a version available for railroad, or will be available for railroad or transportation applications. 

And then finally, finishing off with transportation applications, I mentioned earlier the ethernet train approach, where we have a time-sensitive bus. We are also developing a TSN-compliant train switch as well. So yeah, as I said earlier on, as opposed to having three, possibly four different physical networks on your train, we can all make it into one physical network using a TSN train switch. 

[Host]- Cool. I think the IPC stuff is particularly interesting, because that's going to open the possibilities for users to start developing TSN native edge devices and gateways. So it's nice to know we're doing stuff there on top of the switch stuff and 5G stuff that you'd expect. Well, that wraps up our session for today. I hope you found something interesting in our discussion. 

And I'd like to thank Brendan and Peter for sharing their experience and insights. If you're thinking of moving towards a TSN solution and want to find out more, then you'll see links to relevant contacts and information on the screen now. I'd like to thank all of you for taking the time to listen to us and look forward to welcoming you on the next InnoTalks session. But for now, it just remains for me to say goodbye.