Erik: Hello, I'm Erik Walenza, founder of IoT ONE. And this is the Industrial IoT Spotlight. Every episode, I interview one expert about a project that is impacting businesses today. Visit us at IoTone.com to learn more, or email me to start a discussion.

Welcome back to the Industrial IoT Spotlight podcast. I'm joined today by Todd Walther, Chief Marketing Manager at National Instruments, and by Todd Didier Internet of Things Solutions Architect at Cisco. In addition to working with National Instruments and Cisco, Paul, and Todd are taking lead on one of the testbeds of the Industrial Internet Consortium. And for those of you who are unaware, the Industrial Internet Consortium or IIC is a global member supported organization that promotes cooperation among companies to accelerate growth and adoption of Industrial Internet technologies.

And one of the most interesting initiatives that the IIC is leading is the testbed initiatives where groups of companies will collaborate to test a new solution, a new technology and accelerate its entry into the market. And today, we're talking about one testbed in particular, which is time sensitive networks. But before we run into the details of the Time Sensitive Network or TSN testbed, Todd and Paul, is there anything I missed in in my very quick introduction of yourselves or the IIC that you think we should put on the table before we get more into the details of the testbed?

Paul: Doing this work at the IIC has been a really wonderful opportunity for a number of companies at IIC that think this technology is interesting, a really good opportunity to drive technology readiness as well as market and ecosystem readiness. We're an organization that could quickly put together test beds, and we've executed a number of pug fests. But most importantly, all the results of our work go up and down.

We give a lot of feedback and input into the various standards organizations that are helping shape this technology, as well as a lot of information out to the marketplace on how well we're doing with the technology, helping spread word or news about this new technology. And so really fulfilling what I think is the overall objective of the IIC is to accelerate adoption of these IoT technologies. And so this testbed really does do a good job of fulfilling some of those objectives in particular, on one technology time sensitive networks.

Todd: The other thing that I'll build on what Paul said here is that we really have a number of different organizations, both the standards organizations like IEEE conformance with groups like Avenue, groups that kind of build higher level protocols like OPC. The IIC that's hosting the testbed where then companies that are investing in bring all those different pieces together in order to see how they're going to work. It's a kind of drawn analogy, it's like a soccer team. And we're really getting very well-tuned at playing our positions in these different organizations. And these testbed is really critical player on that overall team.

Erik: So before we get into the specifics of the TSN, Paul or Todd, can you give a quick overview of how is a testbed structured and how does testbed differ from a pilot project or from a research project? What really differentiates a testbed?

Todd: Really what we are doing in this testbed is twofold. First, we are building on new technology. And fundamentally what we're working on what TSN promises to do is in our smart systems, our factories, our automation systems. Today, we use disparate set of different communication technologies to build the control systems and then to try to integrate that data up into our data management and enterprise management systems.

TSN is a technology coming out of the IEEE 802. So the body that maintains the Ethernet standard, and this will allow us to use one common technology all the way from sensor to cloud. Now the technology is new, some of the standards are extra still in work. And so this gives us a place where multiple different companies can get together to create very pragmatic proof that these investments that we're doing, that they work, and perhaps more importantly, that it's common, that it's not something that's a vendor proprietary implementation, but that you can get products from multiple different companies, mix them together and be able to use them.

So the first foundational piece, really what we're doing right now is assuring the technology is going to function and be interoperable. The next phase, as we get to, will be showing how to build this together to create reference architectures for these flexible manufacturing and smart robotic applications.

Paul: From my side, which one of the really important aspects is the technology requires that end device makers build it in, that network infrastructure vendors build it in, that chip vendors produce the right technology that we both incorporate into our infrastructure and end devices. And so it takes a number of companies to kind of come together. And that's where I think this IIC and this testbed has really enabled us to do that, pull all the key players, not just company-wide, but types of companies together to really try to drive the adoption of this technology.

Erik: I think that's really what's unique. And what the IIC has been able to accomplish, is to get companies that are even you would say competitors in many markets, but to collaborate on moving the technology forward because they know that it's going to be better for the market as a whole. TSN testbed won the Q1 testbed competition at the last meeting. Because reviewing the other testbeds in the market, I think there's a lot of very interesting projects that are being done, but they are generally developed around a particular use case.

The use case driven testbeds are conceptually easier. I'm coming more from a business background, whereas TSN is very much developing a fundamental technology that's going to simplify or enable a lot of other hypothetical use cases that maybe not in the market right now because the barriers to implementation.

For a person like myself, somebody coming from more of a business background who doesn't have much insight into the technical challenges that are delaying a lot of implementations in the IoT space, give an overview of the before and after? How is this impacting the manufacturing environment?

Paul: Well, I'll give you some examples, some stories from NI customers. So today, when our customers build a system where they're building a machine, where they're building a test rig, what they end up doing is they design and validate that entire machine. So all of the sensors, the actuators, the total machine operation, the UI, they'll build that and again, they'll validate that everything works properly. Their control loops work. The data flows work. And then they lock that system down. And by lock it down, I mean, there's no changes to other sensors or actuators which may be obvious.

The other thing that locking it down generally means though, is that there isn't normal communication into that system. There's usually one port somewhere on that system that allows them to get data out. So when they built the system, the engineer or the system designer thought through what sets of data would I like to have out of this and that's exposed, but other information generally wouldn't be available.

And that's a challenge when they get into flexible manufacturing, where the expectations the designer had when they did the initial design of the machine. And the realities of the manufacturing floor, maybe a week after put in production or maybe a year after when production, those are radically different. And today, it's very risky to go through and add different data communication in because the network itself is fairly brittle. Or the other thing they do is they'll use special dedicated field buses to basically I can't have an Ethernet communication because it's not full standard Ethernet.

What TSN allows is convergence. So, both that control data and the business information can run on the same network. And importantly, it provides composability. And what I mean by that is the additional requests to get different operational efficiency data or information about motor current signatures, information about machine health. So I know if it's going to need repair or diagnostic work: that data can't interfere with data that's critical for the control or measurement application. It's scheduled and prioritized and it's composable. So I can add more of those elements in without any danger of changing what's there. So it gives me flexibility without risk.

Erik: I think a lot of the marketing material, the communication material around the TSN testbed, you have three benefits or three aspects that are often highlighted, which are time synchronization, traffic scheduling and system configuration. And the way that I interpret those is time scheduling, making sure that machines are aligned across different vendors, different machines, traffic scheduling, that data can be data transfer between equipment can be done in a controlled manner. And system configuration that you can update equipment it's not locked in. Can you provide some more detail into what do these three mean in practical terms for a manufacturer?

Paul: These are kind of like the key elements of TSN, the Time Sensitive Networking models. First, what's really critical in this whole concept, this whole idea it is critical for a number of applications as well as is that all the devices have a very precise aligned sense of time, not just phase or other aspects, but really a good sense of time.

And over the last decade or so, there's been a lot of work in a technology called precision time protocol, it's an IEEE standard again. But what that does is enable in a network of devices that time is distributed to all those end devices in a very precise manner. If you want to think about it, it's NTP is the IP version of time. And that's usually reliable into second, maybe a little less than a second, but the clocks are, for human purposes reasonably well aligned. But for a lot of these machines, that's nowhere near good enough. And they require a much more precise sense of time. And that's what precision protocol time synchronization gives.

And once all the infrastructure and the devices have this good sense of time, what we're doing here is making an enhancement in basic Ethernet so that you can schedule traffic. And what that basically means is the end devices as well as the network all know a schedule for the critical data flows, expect the data to come in and send the data out on time basically.

If you could take an analogy driving along a city streets, the analogy would be your car is driving along and just you come to the intersection, the light turns green, you don't have to slow down, you just simply continue on a very deterministic path so you get from point A to point B in a very precise amount of time. And that's what's really critical in many of these applications is that they deliver this information on time.

What's important for this whole concept to work right is the system configuration aspect. You may have heard over the last 5-10 years been a lot of work in networking area called Software Defined Networking. And what we're basically doing is applying those kinds of concepts and ideas here so that this is a technology that for end customers relatively easy to use. They use the applications that to configure automation and control systems as they would. But those systems now talk to the network and say, here are my requirements, they present the requirements and the network says, hey, yes, I can fulfill those requirements.

And then the network can then distribute the schedules back to the end devices in the network infrastructure, and everything's ready to go. It's not kind of configuration that’s based on software defined networking. I think that's going to make this technology easy to adopt for customers as well as for the ecosystem.

So those are what those three key elements are for TSN. There's a lot of other standards being built into TSN, Time Sensor Networks, which help a lot of the core concepts on how to deliver information more precisely, how to secure that information. But these are what we think are the key foundational components or elements of time sensitive networks that allows that as all those benefits Todd was going through earlier.

Todd: It's really bringing these common network services that then as a vendor of end equipment, we can just take advantage of these network services. And that unlocks, as Paul was saying, a whole world of value to our joint end customers.

Erik: And I see on this most recent deck time synchronization has a green check, traffic scheduling, yellow; and System Configuration, none yet. So are these built upon each other? Is it that you first need to solve time synchronization in order to enable traffic scheduling and you can't enable System Configuration until traffic scheduling has been resolved? Or is that just the path of the development so far?

Todd: It's a little mix of both. Certainly, everyone have a common concept of time before you can schedule. You can't have agreed upon schedule if we don't agree on the time. So those two there is a technology link. The system configuration I think is more pragmatic one of us figuring out how to get the data plane elements working while each vendor handles their configuration their own way. It's just a pragmatic stepping stone. But I think we're quickly hitting the point where we've got the fundamental data plane elements and now the real interesting parts become on the software and configuration interface and how do we make sure that these are all interoperable one, you can pick a tool from one vendor and use it with products from another vendor and get systems that are built and they’re operable.

Paul: But generally speaking, in our testbed in our PlugFest, we come together. And this is somewhat of a stepping stones as a testbed that we're going through and individual companies go through. As Todd said, If you can't get synchronized to the clock, it's hard to even know that you're passing and receiving traffic on a schedule. So that's usually the first step. And then the traffic scheduling comes on. And to a large degree, most of the companies are achieving that. We're doing a lot of work understanding from the various standards organizations the system configuration aspects and giving a lot of feedback back into those organizations on that side. We don't have a check mark because we're still working on quite a bit of those areas. But as Todd said, we're progressing pretty quickly. Essentially, that's kind of like the objective for the IIC is really to help drive that technology as well as market readiness.

Todd: And the other thing I’ll comment, we're a bit of a victim of our own success. We now have 20 different organizations that are participating in this testbed. And so if it was just one or two companies, you could make progress much faster. But at the end of the day, the impact is much lower. And so right now the, the market interest in these technologies, and as part of that the market interest in participating by various companies to build interoperable ecosystem, so it's just really, really high. That means the end results, we're extremely optimistic about, often doesn't mean that every time a new company joins, there's another round of bringing another organization up to speed and getting those pieces integrated in as well. But that I think that's a good problem to have.

Erik: The consortium of organizations that are working on this is really impressive. And I want to talk a bit about the actual technologies and the architecture in a moment. But first, your thoughts, you have some members here, Schneider Electric, Bosch, Rexroth, that I would say they have their own protocols, to an extent they have market niches carved out because it's difficult for customers often to switch vendors or to bring on vendors because of the status quo in which it is actually quite difficult to communicate across vendor technologies.

What are the implications for this time sensitive network technology on the market? Are we looking in in five years at a market where this technology is widely available and end users or manufacturers are no longer necessarily locked into a particular vendor’s ecosystem but can choose more precisely the best equipment for a particular need and then can integrate that equipment across a wide array vendors?

Paul: I don't think TSN is going to get us to that ultimate for the customers. They're totally flexible between different vendors systems. That's what we would in the OSI model take like layer seven flexibility. But to get to those stages, you do need a network communication that can support the various flavors of applications. And so what we're doing with this TSN, at least gets us a major way up that stack of driving that convergence.

There's a number of these automation and control protocols that are looking at TSN and trying to adopt that, whether all of those protocols start to converge themselves, that's probably a next phase or a task beyond that. Whether it's OPC and some other protocols, that's up to the market to drive that kind of adoption. But one thing for sure is you do need a network infrastructure that can support the variety of requirements there. And TSN gives us one of those core deterministic capabilities that Ethernet been lacking for the last 20-25 years.

Todd: I’ll build on two things. One, I want to clarify that the testbed is intentionally scoped to map what's going to exist in these real factory systems and brownfield. And by that, I don't just mean existing installs, but existing equipment is going to be essential into those systems. So I think one thing that the testbed has been very smart and very clear about is that we're not trying to say there's just one upper layer protocol. That would make it really difficult for anyone to port or to scale. And so a TSN is much more about these common network services on top of which different protocols can exist. And you don't see battles at least in the end user space about, hey, what protocol is my web browser using to pull this information across? But as an end user, if it's just the protocol sitting on top, that's a relatively minor adjustment to make. But if I have to change my whole infrastructure in order to put one other device on, that's a big problem.

And so really, we're focusing on that first and that really critical problem of the network services are there available to everyone in a compatible way. And then, as Paul said, we think over time, the market will sort itself out on what are the right higher level protocols sitting on top of that. And that may vary by industry and by application.

Erik: So let's get a bit more into the technology. I think so far, we've been talking about the value and how this might impact the manufacturing environment. What technology goes into this testbed?

Todd: You've got pretty much every level along that value chain is represented. So certainly, the TSN features in order to have very precise scheduling with nanosecond level precision in order to schedule flows through the network in a reliable way software to configure all that, that starts at hardware. And so there are a number of the silicon vendors from Intel to analog devices, the Hilscher. But those vendors are making investments into their core offering. And we're seeing that really across the board of vendors who build silicone service in the industrial market. They're making investments to add TSN into the silicone.

The next level as we build on top of that, that silicon goes either into bridges, so switches like what Cisco switches, like what Hirshman Belden make and are part of the testbed as well as then end devices. So what National Instruments, what Schneider Electric, what Bosch Rexroth, we're all building on top of that, and then finally the software to configure and to make setup by the end user possible and scalable. So you're seeing investments by vendors everywhere along that value chain and bringing the system together.

Paul: Typically, the end devices the listeners and talkers are configured using some form of the user configuration tool in National Instruments perspective that might be LabVIEW. And then each of the ecosystems have their own user configuration tools. And that's what we were referring to earlier. Those user configuration tools need to talk to a system or a service within the network that understands the requirements, what are the flows? And then based on those flows, can determine, hey, can I accommodate this into my schedules and my traffic? Do I have enough bandwidth? Do I have enough capability to schedule all these flows? And then basically, say yes, or no to the user configuration tool.

But when he says yes, then go about taking that schedule, creating for every bridge along the way, here's your list of trains or traffic that's going to come across your bridge and I want you to support this. Make sure that all of those bridges then have that information, and then pass some parameters back to the user configuration tools to say here's when your listeners and talkers need to be starting a conversation or expecting to receive information so that everything performs in a very orchestrated manner.

I think this fulfills a lot of the concepts around software defined networks where the routing, the switching of traffic is done based on the requirements given by the application. And the applications can really like help determine what the priorities are and when things need to be communicated, so on and so forth. So this is really that that system view of things and what we're really working towards.

When a vendor approaches us from the testbed side, we usually put this up and say, what parts of this picture do you intend to bring into this testbed? It's important that typically they're bringing some form of technology that either listener or talk or bridge or a network configuration tool or user configuration tool. Because this is really the way we're operating and performing. There’s the timing and the traffic passing, all get built into this this model. But this is that system view that we're all working towards building towards.

Erik: Where are we today? Are we at a working model level? Do we have particular cases where this is already functioning in an operating environment? Or is it still more of a testing environment and there's still core technologies that are being developed?

Todd: It’s a mix of both. So there's both still technology pieces that are being built on the standard conformance and interoperability testing so that end customers can buy with confidence from multiple vendors knowing they're going to work together. That work is being done in Avenue and it's still work in progress.

And there's on the testbed, a mix of products that are released products, products that are prototype products on that testbed. We do have joint customers that are using our products in their applications for areas of machining applications for areas of microgrid research and for areas of semiconductor production equipment. But those are really lead customers that we have worked with closely to get them this early technology. So I think we're still on the early edge of this technology rolling out into the marketplace. But we're seeing great interest from the marketplace in general.

Paul: Typically, this industry is it's not like the consumer world. It moves a little bit slower. Therefore, it's usually building for higher levels of availability, resiliency. These are real world applications. And most of us would expect these to be working at very high levels of availability and very deterministic nature. So it takes a little bit longer to build new technology like this into product cycles into system and solution cycles. As Todd said, we're on the early phases of that; we have a few customers leading the way in that. But over time, we think this will be a really critical important technology for the Industrial Internet of Things and industry for all applications. To really get to the rich at data, you need these kinds of edge technologies that are open standard and can support that type of data flow.

Erik: And for somebody who might be listening to this podcast from the technology development standpoint and thinking, well, when is this going to be available for me to build solutions around, I know, projecting is a risky business, but can you give me maybe a high level rough estimate for when you think this is going to move from niche adoption by early movers to a bit more of a mass market adoption? I mean, are we talking one to two years? Are we looking more out into three, four years?

Paul: We're looking at this testbed, and as Todd said, you've already got some folks with existing products, some with products and development. I would imagine, most of the players here are looking to build the technology into a product that usually takes a year or two years, but they're clearly thinking about it and building. And so, we would hope to see adoption ramping up from now where it's a small group of companies that are offering the technology to a larger group.

And then depending on the industry in the area that you're working on, it takes time to get it built into the machines into the systems that we've seen in a lot of these production environments. It's kind of hard to say you can probably see it in particular machines sooner, then available across broad ranges of the automation and control vendors a little bit later where you then can build full systems based on TSN. But it's hard to predict in probably not too appropriate to put some precise figures on. We all represent individual companies and this is an ecosystem. But we're pretty confident with the number of vendors that we have, the interest level in the technology seems pretty high. So, we're all pretty positive about it.

Todd: I think the question maybe behind your question for individuals or companies who are in charge of their technology roadmap, folks of companies who are looking at challenges in their production equipment where it's too rigidly set, the right time to start looking at TSN and start engaging with their preferred vendors is really now. Like I said, all of the major vendors are working on TSN roadmaps and TSN implementations now. Now, that doesn't mean you can necessarily build your machine with TSN equipment yet. But you will be able to in the next few years. And so if you have existing limitations and challenges, I'll speak as an end equipment vendor, the more we can understand what things our customers would value, help us make the right tradeoffs and those implementations.

So I think the right time, if you are a technologist in your organization, the engagement time is now. If you're someone that's looking to build your machine today, it's probably not quite ready yet.

Erik: But I see the TSN testbed has a focus on flexible manufacturing, it seems to me maybe a bit of an outsider here that the application also useful for some smart city implementations, for energy implementations. Am I right, is this a horizontal technology that's also applicable in these other environments where you have similar challenges with transferring data? Or is this technology more unique to the manufacturing environment?

Todd: No, it's absolutely horizontal. One of the things that in IIC we want to do is not just do the technology vetting, but then as I commented, build that up into an application architecture so that system designers can more easily understand and adopt. We want to make sure we're vetting not just the technology but the rest of the system design complexities to it. Today, as you've heard us, we're very much on that first part getting the technology, working and working in a reliable and compatible way. I’m hoping we will rapidly be transitioning from getting it working to doing the rest of the system architecture.

However, that first piece, the technology itself, you're absolutely right, Erik, that is applicable. As we start looking at more and more applications, we keep finding more and more places we're having reliable timely data transfer, having simplified ways to set up and manage our network, that is so universally beneficial. And so we expect these TSN capabilities are going to make their way into almost every industrial application over time. The testbed right now is doing the horizontal work, we hope others will leverage and then we'll be able to transition and to do more of the vertical work for flexible manufacturing.

Paul: I was going to add definitely, it's considered a horizontal technology for industrials. If we look at some of the organizations that have shown publicly interest in that technology, they include other automation and control protocols. They also include some of the utility protocols. I think, in terms of smart cities, there's clearly some applications as well. If we look in Avenue, there's focus groups for automobile in car network. So it's definitely got a lot of different uses.

But for a testbed to really function, you do need to kind of like focus on an ecosystem on a particular vertical, then you get people with the same kind of requirements, the same all trying to achieve similar results. And that's important to get that testbed vehicle. And if we were trying to do this with a robot maker and a smart grid maker, it feel a little bit clunky. End devices themselves, you wouldn't normally see working functioning together in a real world application. So it helps to keep it focused, but definitely the learnings of this from this testbed and technology readiness that we're driving will find itself reflected in different in different verticals as well as testbed is what we imagine so.

Erik: So Paul, Todd, I wish you and the other partners on this testbed all the success in the world. I think you're going to have a huge impact on manufacturing and on other industrial use cases in the IoT space. Tell me how can people learn more about the TSN testbed? How can they get in touch if they would like to participate?

Paul: If you go to the IIC. website, the Industrial Internet Consortium, on that website they've got really prominent links to the testbeds, including to this TSN for flexible manufacturing testbed. On there, they can read more, links off to where they can see some videos of the testbed, get more information about how pieces are working, who's participating. There's also on their link where they can follow up with IIC. So if they'd like to get more information, like to share use cases to make sure they're being covered or better yet if they want to join the 20 plus organizations that are already investing here, that would be a great way to get involved.

Erik: Great, Paul. Todd, thanks so much for a fascinating call.

Paul: Thank you, Erik.

Todd: Yeah. Thanks, Erik. Thanks, Paul.

Erik: Thanks for tuning in to another edition of the Industrial IoT Spotlight. Don't forget to follow us on Twitter at IoTONEHQ, and to check out our database of case studies on IoTone.com. We help to accelerate digital transformation by advising business leaders on how to integrate IoT technologies into their operations and products. We appreciate your thoughts, suggestions, and of course, your reviews. And if you have an interesting project, we'd love to feature you on a future edition. You can write me at erik.walenza@IoTone.com.