Glenn Schulz: The IIoT ecosystem designation comes because the FDT 3.0 architecture now incorporates a highly scalable FDT Server. This solution fits all the classic IIoT requirements and capabilities, and our ecosystem continues to expand in response to market growth. End users are looking to companies supporting the FDT standard as part of the ecosystem, including vendors that write DTMs to support their field devices or include the FDT Server in DCSs, PLCs, asset management applications and other system solutions, so they can take advantage of all the different devices on all the different networks.
In one sense, FDT is protocol agnostic, but what our ecosystem means to the end user in a larger context is they can remain essentially oblivious to the network that a particular device is on. Moreover, it doesn't matter how many layers deep the architecture is. They are able to directly access their devices. Another part of the FDT 3.0 ecosystem is all the toolkits and capabilities we make available for developers, so they can go to market much faster with their FDT-enabled products.
In terms of the optimization of next generation automation solutions, the fact that end users can access all the data from FDT, wherever they are via mobility solutions, is a particularly important aspect of the technology. For instance, a senior engineer or technician can remotely access information to help a junior person troubleshoot a problem or commission a line without having to physically travel into the facility. In the context of COVID-19, this is a very important capability.
FDT Group is a standards organization, and as such, we produce technical specifications for use by automation developers. What we do is provide the underlying capabilities for smart manufacturing and mobility.
For example, in the era of smart manufacturing, the world is pretty much standardized on the OPC Unified Architecture (OPC UA) in terms of how we access data from different systems and leverage that data throughout the enterprise. The new FDT Server architecture includes an OPC UA server. This approach makes data available across the enterprise since the FDT standard is now freely accessible for other uses through OPC UA technology. You might have a situation where a production manager requests a dashboard to monitor a new production line. This is an easy task if you can immediately get all the necessary information through OPC UA without having to reprogram the PLC or intervene with the DCS. FDT sits side-by-side at a peer level with the host system so it can offer up the required information to the enterprise without disrupting the control environment. The same is true for mobility: the FDT Server, or the user interface, can now be accessed through any browser.
First of all, I have to commend ODVA for showing the industry what is necessary to develop and enhance a secure communications protocol. We do not currently have any parallels in the industry. CIP Security is so important for our industry in general, and for us as a standards organization in particular. The latest enhancements mean that when we are connecting systems and devices, we can be assured of a more complete and secure solution. Otherwise, you could have a network that is unsecured talking to a highly secured environment like the FDT Server—and that is not optimal from a security perspective.
As the ODVA organization continues to enhance the security capabilities they make available through CIP Security, it is only going to benefit the automation industry and FDT-enabled solutions even more.
The new FDT Server features an internal web browser, so that any web browser can attach to it. We have also enhanced the user interface (UI) so that it is aware of the dimensions of the user’s screen and whether there is a physical keyboard or touchscreen. Additionally, we have made the UI responsive.
While a remote solution is great with a standard like FDT, if you do not wrap it tightly with advanced security, it is not really a workable feature. That is why we have spent a great deal of time looking at the underlying architecture related to security, so that when people do work remotely utilizing our new standard they can connect securely to the remote server.
A good analogy would be online banking; we are all conditioned to look at the URL bar to make sure we are really talking to the server at our bank and not somebody fishing or trying to obtain our credentials on some other site. The FDT standard has a comparable capability built in.
There are also cases where the IT or OT department may not want remote workers to use just any device to access a remote server, and thus they require an authorized device from the company. This enables them to turn on an additional feature in the FDT Server that will ensure only authorized clients can connect to the server. So, a person using their personal device would not even get to the point of entering their log-in credentials. It would be like the server is not even there and is not going to talk with you at all, because you do not have an authorized client device.
If we layer these kinds of features into our standard—depending on the security level the company wishes to maintain—they can turn on enhanced features to strengthen their security posture.
Once you are in a confident, secure environment, you can log into the server. And you can do virtually anything you could do if you were standing physically in the same facility. You can look at the health of your network and devices, get real-time data from them, browse manuals for the devices and even set parameters for them.
An advanced technology such as 5G, at its core, helps realize more of the promise of IIoT, which is not just smart devices connected to physical networks that are wired to a controller, but also devices that have no wire at all connected to a Wi-Fi type network like Bluetooth. You can see these examples when you start thinking about AI or DCS applications, or even a classic industrial control environment where you want to add more sensing and monitoring capabilities to the process without having to include more hardware. Field devices can now have a 5G connection and take advantage of the extra bandwidth and security this technology brings. The other benefit of 5G is that, architecturally speaking, you can go up to the cloud with a device instead of having to go directly to a PLC or DCS.
From an FDT perspective, we immediately saw the advantages of 5G because it is largely transparent to our standard. All the 5G capabilities can be leveraged through the FDT standard. It does not matter what underlying protocol is employed by the remote device. That’s because we support all protocols. As such, 5G technology will just be a natural extension of the FDT standard.
It is apparent that one of the highest levels of interest in FDT 3.0, beyond its mobility features, centers on the standard’s built-in OPC UA capabilities. Since we already have direct lines of communications to all devices and can see the health of the various underlying networks, it really is a powerful addition when you bring the FDT Server into a control environment. Suddenly, the work that was once required to get information routed through the PLC and up to the ERP or some other application becomes almost a trivial exercise. You can attach to the FDT Server if you have the right credentials and browse the data structure of the facility. You do not necessarily even have to know a particular device’s name. You can use the OPC UA capabilities to browse and find the right device, obtain the information you need and integrated it into your application.
These and other key capabilities have driven a lot of conversation about the FDT 3.0 standard. I think most industry stakeholders are very comfortable with all the new things we continue to do because of our legacy in the areas of integration, configuration, and diagnostics.