Solutions Spotlight: FDT Group standards, technology evolves to support IIoT

With the number of Industrial Internet of Things (IIoT) use cases growing and multi-network automation environments adding complexity, the FDT Group has evolved its international standard to accommodate.  In this episode, Keith Larson is joined by Glenn Schulz, managing director of the FDT Group, to discuss the challenges of today's environment and how FDT 3.0 is helping users integrate and manage the complexity. 

Learn more about the FDT Group at: https://www.fdtgroup.org

Transcript

Keith Larson: Hello, this is Keith Larson, editor of Control magazine and ControlGlobal.com. Welcome to this Solutions Spotlight episode of the Control Amplified podcast. With me today is Glenn Schulz, managing director of the FDT Group. We’re here to talk today about the challenges that today’s multi-vendor, multi-network automation environments pose for industry, and how FDT Group’s open technologies are helping to integrate and manage that complexity—for both legacy systems and the latest Industrial IoT use cases.  

Welcome, Glenn, a real pleasure to have you here with me today. 

Glenn Schulz: Thanks, Keith. Pleasure to be with you.

Keith: Well, maybe just to start things out for those of our listeners who may be unfamiliar with the FDT Group and its namesake technology, can you briefly review for us the roots of the organization and its evolution to the current FDT 3.0, or FDT IIoT Server, offering?

Glenn: Yeah sure. It's a great please to start. So, the FDT Group can trace its history more than 20 years of operation. It got started by a group of leading process instrument manufacturers and DCS system manufacturers that, while they were encouraged by what was at that time the relatively new capabilities of the smart fieldbuses and networks and so on, they were very frustrated that it really didn't help at all with integrating these into a multi-vendor solution. And so, this group of companies got together and started the notion of putting together an international standard that would address not only how to be able to manage a multi-vendor environment in the process industry, but how to configure the devices, how to diagnose devices, how to maintain devices, how to describe devices, and so on. So, it was really a pretty ambitious hope for the days that they were working on that, and obviously, they were very successful in their efforts, because today the FDT Standard is the most recognized standard in the industry for device configuration, device management, access to plant floor data and so on.

So, it's interesting that from those somewhat humble beginnings that it's moved out of the process industry going into the factory automation industry as well, and hybrid industries of course, brewing and packaging and so on make extensive use of the FDT standard as well. 

In terms of evolution, to the second part of your question, the standard is regularly maintained. And so, we're always keeping an ear to the ground for what the industry is looking to do next, and that's both from a vendor perspective and an end-user perspective, revving that standard and when the standard first came out 20-some years ago, it was squarely based as a desktop, Microsoft platform, which was really the only required use case in those days, so it fit the market perfectly. As the versions of the standard moved on, it became obvious that staying on the desktop didn't have the scalability that people were looking for when you took this to an enterprise-level solution, and so we moved to the capability for a client server architecture, and the most recent version of the FDT standard, which is FDT 3.0, is fully platform-independent, so the server can run on any major operating system, Linux, Microsoft, Apple  and so on. And the end-user interaction with the application is through standard web browsers, whether they're on your phone, your tablet, your desktop, your notebook, whatever, you can fully access it using regular web browsers. 

So, it's come a long way from those days. We still support more than 18 different networks out there in the industry through the standard, and now it's fully Internet enabled. 

Keith: Gotcha. So, it's both really a standard and a technology when you think about how it works. 

Glenn: Yeah, I think that's a fair assessment. I mean, we're clearly a standards organization. You know, our goal is to produce standards that are of value to the industry, and we take those and we get those standards accepted by large international standard bodies like IEC or in China it's a GBT standard, or in the U.S. is the NCIS standard, and so on. So, it's truly a standard, but you're right, there's a huge amount of technology that goes into building these standards and making them successful. 

Keith: Yeah, that makes sense. 

How has the device landscape changed since the early days of smart transmitters and HART protocol and Profibus and things like that. Now, it's really a different landscape now, isn't it? And what new requirements has that placed upon both the users and suppliers of automation devices and systems?

Glenn: Yeah, it's definitely changed. I'd say in one aspect, it's broadened out. So, we certainly have a lot more industrial networks that we support than we did in those early days. In the early days, it's was primarily focused on a handful of process automation based networks, but with its transition to factory automation, that's multiplied many times over in terms of the networks that we support. The great thing, though, about that is the way the original standard was written, they anticipated that there were going to be other networks that needed to be supported, so the standard is written such that when a new network comes along, we don't have to rerelease a new standard, you don't have to reinstall everything in the field. We just create what's called an "annex," and everything out there can immediately take on that annex and communicate on the new protocol. So, it's quite powerful that way from a network perspective in our industry. 

But I think the newest requirement for us, clearly with COVID that's basically underscored the issue of being able to work remotely from your facility, and the new architecture directly supports that. You can access it from anywhere in the world if you have the right security credentials to do that. So, that's fantastic to today's environment. But I think that other thing that really has changed dramatically is the need and the desire to get access to real-time information on the plant floor, and do it in such a way that you don't have to go through gatekeepers like the DCS environment or the PLC environment to get to that data. Basically, immediate access to plant floor data for at-hoc projects or for long-term integration into higher-level systems.

Keith: That really is in line with the NAMUR model, where you have a parallel path for non-control type of information, so this really facilitates that along the way. 

Glenn: Absolutely, we clearly participate in the old automation pyramid, but on the other hand, when you look at the new FDT architecture, you can see we also sit adjacent to it. And so, the IT side of customers' organizations love that because they can now get direct access to data without a lot of roadblocks. 

Keith: Maybe you can dig a little more into the details of just how this works. Just really, I mean when I think about trying to manage communications integration among all these different types of devices, but also meet expectations with respect to mobility, security, cloud connectivity. Can you give a little look under the hood as to how that all comes together for an end users facility?

Glenn: So, the main change with the newest version of the standard is we've gone to a full server-based model. Now, you could still operate it on a single user desktop environment if you have that kind of application, but that's no longer the typical use case. So, we've gone to a full blown server, that we call the FDT Server. It's an Internet of Things server, so it's architected so that you could deploy an instance of it in your facility, you could have an instance on the edge of your corporate environment, or you could have an instance up in the cloud. So, the entire architecture has been server based and completely redone so it can run in any of those types of environments and on any operating system. So, that provides great access to the capabilities that FDT has always offered, but then we add to that that all of the user interface now with that new FDT server is carried out with HTML5 and Javascript. So, that means all of the user interaction is now through just a standard web browser. So, not only can you put this up in the cloud, but then you can access it from anywhere that you've got access to the server, and you've got the right credentials to do that. Now, the nice thing is, the server itself still does what the FDT standard is so well known for, and that's taking all of these different industrial networks, all the different industrial protocols, and basically putting a layer of abstraction between those and the end user, so that they don't have to worry, "is this device on HART?" or "is this device on devicenet?" or those type of things. They just see the device and they can directly interact with the device, no matter how many layers deep in the network it is, no matter where it's located in the architecture. To them, it's as if they've got a direct channel to the device, and that's all done through this server environment, whether that's in the cloud, edge or somewhere in a server environment in a factory. So, very powerful. 

Then, the other thing we did that really addresses what both the IT and OT side of the organizations were asking for. We build into that FDT server an OPC-UA server, and we've taken care of all the data model issues, so nobody even has to worry about that. So, you literally now, when you put that server in place, you put the device drivers, the DTM in place, for that server, without any additional activity you can hit that server through an OPC-UA client, and you can see all of those devices, you can click on a device and see all of the data it exposes in real time. No extra work in terms of configuration at all. 

Keith: That's very powerful, very powerful. 

There's also the component of the FDThub. I think that's more for managing the latest updates to all these device descriptors and all that stuff that nobody wants to worry about. 

Glenn: Yeah, that's a fair way of putting it. You know, FDT really was a victim of its own success, so we became very popular very fast as a standard, and so there were a lot of DTMs created in the marketplace. DTMs you can think of them as a device driver to support that device in the FDT server. So, all these vendors were making all these DTMs, which was great, I mean, we were certifying DTMs like crazy, everything was going well. But as I go to the user forums around the world and speak directly to the users, the number one complaint they had about the FDT standard was that it was so difficult to find the DTMs they were looking for. Everybody was producing them, but if you were doing a new installation and you needed 1,000 different DTMs, every vendor buried them somewhere else on their website, or they had a memory stick packaged with the device that had it on it. You know, everyone did their own thing, and while each of them sound good in themselves, to the user, it was a daunting task to find those DTMs. So, the thing we really wanted to correct with the new standard is to get that into a format that's much more practical for the end users. So, as you mentioned, the FDThub is our name for that solution. What happens is now is when a vendor certifies a DTM, that device driver or the standard, that copy of that DTM is automatically placed up in this FDThub. So, it's a cloud instance, a huge repository for storing these DTMs. Anytime that a server recognizes, "hey there's a new device on one of my networks that I'm supporting, and I don't have the DTM for it in my local catalogue," it can directly talk with the FDThub without user intervention, it can go up to the hub and say "hey, here's the device I need a DTM for, give it to me." And the hub will then pass along the latest version of that DTM to the server, and then the user can decide, "is this the DTM I'd like to install or use for my application?" So, very powerful, directly to what our end-user community asked for, no web browsing even on the hub to find it, the server itself speaks directly to the hub to get the DTMs.

Keith:  That's another powerful feature no doubt about it. That's really a key advantage for the end user. What's in it for the system suppliers, whether the instrument suppliers or the DCS or PLC suppliers. How does this make their life easier, too? 

Glenn: You know, the bulk of that is in the end device vendor marketplace, so let me talk about that first. What they get as a benefit out of this is they write to one standard and their devices are supported in all of these installations worldwide. They can also take that same DTM, and many vendors do this, you know, let's say they've got a fairly complicated device, a good example these days is probably an AC drive that has thousands of parameters you can configure in it, and that doesn't always go into a large system, sometimes their almost standalone in their application. But they still need a configuration tool for that drive when it's standalone. They can take that same DTM that they created and they can put a simple wrapper around it, and it'll run on a desktop environment for them. So, they get a standalone configuration tool for the same effort that they put in to develop the DTM for the big, large system integration and the capabilities. So, they love that because it's very high reuse for them in terms of a software component to support their products. And now with the new architecture, they don't even have to ship anything. They can just give their customer access to a cloud-based instance, and if they've got the right gateways set up within that customer facility, they can configure it directly through there. So, even that perspective is changing as they get used to the new FDT server and the way that it can sit up in the cloud. 

So, the other thing the device vendors get out of this is interoperability, which is one of the original goals of the standard when it was started 20-some years ago, and that was provide a way that I'm ensured that when a device shows up in a larger system that it functions properly, that people can get information about my device, and yet allow me to competitively differentiate myself with my device through that graphical user interface in the DTM. So, you can build things like pretty nice wizards into that DTM. So, in the example of the AC drive, it might start out by simply asking what kind of application are you using this drive in? Is it HVAC, is it lifting, is it pumping, and so on. And just by selecting the application they can already eliminate or preconfigure maybe a few hundred device parameters and they can keep stepping deeper into the application and maybe the user's only got to tune a dozen parameters in the end then instead of having to deal with thousands of parameters. So, they see it as a way to provide value-add baseplates to their product that the end user will value in terms of competitive differentiation when they're looking in the marketplace.

And on the other side of the equation, the system vendors, the DCS, the PLC guys, they see the other side of that. They look through the other end of the telescope and say, "hey, I can now integrate all these devices, things they don't have in their product portfolio, and offer their customers a complete solution, regardless of the network they're on, regardless of how complex or not they are to configure, and so on. And so, the system guys get the same benefit but multiply many times over because the device vendors are providing that capability.

Keith: Sure, that makes sense. It seems to me, why would you not have this capability in your facility if you're doing this kind of stuff. What do you run into as reasons why organizations might not have adopted the FDT model? 

Glenn: Well, from an end user perspective it may just be awareness or they haven't had a recent project in order to take advantage of that. You know, it can just happen that way. From a system perspective, we don't see that a lot any more. Pretty much, wherever you see automation, you're probably going to find an FDT application installed, and you may not even recognize it as such. It may be buried deep inside an asset management system, doing what it's supposed to be doing, and you just don't simply identify it as FDT unless you're already quite familiar with the standard and can recognize the common threads. So, those tend to be the only reasons in today's marketplace that there isn't somebody taking advantage of the FDT standard.

Keith: Well, we've talked quite a bit about the here and now of what FDT 3 allows. What about what's coming new, what's on the horizon? Obviously, continuous innovation is a key enabling advantage of this. What new things do you see coming down the pike that the FDT Group will need to pay attention to in the days to come?

Glenn: Well, one of the things that's kind of in our regular cadence, not necessarily new, but it does drive the release of the standards, and that's keeping up with the operating systems, with all the security standards around operating systems and the industrial environment in general. Those are always moving targets, and so we're always reaching for those, making sure that we're delivering the security and the capabilities that people are expecting broadly in our platform.

I think there's a number of other exciting things on the horizon. We've certainly heard about the new one-pair Ethernet standard for intrinsic safety and so on. I think that's going to apply to a lot of the networks that are already out there that are Ethernet based. It's a great platform for them to move on to. For us, that's a easy stepping stone from an FDT perspective, the standard is very much positioned to be able to take that on quickly as those network associations make those transitions. So, we're pretty excited about that. OPC-UA technology continues to move on nicely. They're also looking at essentially their own protocol for industrial communications, and we're following that closely since we're very closely aligned with the OPC-UA standard. I think that will be exciting as that starts to mature, probably a few years before we'll see tangible results there, but it's great conversation and great effort is being put into that. So, I think there's a lot of exciting things on the horizon, and the FDT Group always has its wish list and must-do list things for the next standard, and it's always fun to sit down with the board of directors and say, here's what we think we've got to get after, and we get the funding through our board of directors and through our membership, as a non-profit organization, and so, our income and our capability of doing this comes from our members, they donate resources to these standard activities. So, it's always fun to work with the best and the brightest in the industry as we take on these new technologies and capabilities. 

Keith: Yeah, that makes sense. So, you spoke earlier about awareness, maybe there's an instrument company or an end user out there that isn't aware of FDT or whether they even have it, if they're intrigued by the functionality that we've bene talking about. How should they go about getting started to investigate using this solution in their own facilities?

Glenn: Well the simplest way is probably to visit our website, it's FDTGroup.org. A lot of good information on there, you can look over overviews of the standard and you can also get deep into the standard if you'd like to. If you have specific questions, I'd invite you to write an email to [email protected], and we'd be happy to be sure the right resource responds to you, so you can get your question clarified. And then, if you're a vendor out there, we regularly host development seminars, and of course those are all virtual these days, so they're even easier to attend. There will be one scheduled for late spring, so keep an eye on the website, and we open that up to both members an non-members of the FDT Group.

Keith: Gotcha. Well, I certainly appreciate you taking the time, Glenn, to share with us all that's new with FDT Group. I have to confess I was surprised at some of the new developments and how central it's become in terms of interoperability, not just for legacy systems, but certainly this brave new world of the Industrial IoT and stuff as well. So, thank you for sharing that with us, really appreciate it. 

Glenn: Yeah, my pleasure. We've been very pleased, too, by how well the marketplace has accepted the new FDT 3.0 standard, and I think as more people get into it and see the benefits of it, the adoption will accelerate rapidly. So, thanks for taking the time today.

Keith: Yeah, you bet. Thank you all for listening as well, thanks for tuning in. Once again my guest today has been Glenn Schulz with the FDT Group. I’m Keith Larson, and you’ve been listening to a Control Amplified podcast. Thanks for joining us, and if you’ve enjoyed this episode, you can subscribe at the iTunes store and at Google Podcasts. Plus, you can find the full archive of past episodes at controlglobal.com. Signing off, until next time.

For more, tune into Control Amplified: The Process Automation Podcast