The Benefits of a Standardized Communications Layer: Your Questions Answered

Webcast presenters Sam Elsner and Philip Bard answered questions about topics such as data acquisition reliability, communication layers and cybersecurity, and more.

“The Benefits of a Standardized Communications Layer” webcast was presented live on Jan. 16, 2019, by Sam Elsner and Philip Bard, from PTC. The webcast can be found here. They supplied written answers to some of those questions that weren’t addressed from the webcast attendees:

Question: How do you leverage data acquisition reliability (redundancy) and data acquisition quality (scan rate) in the communication layer standardization?

Answer: Kepware has solutions for redundancy for both southbound and northbound data streams. Much about providing redundancy to applications like Kepware will depend on the protocols used as well as the available network paths. We recommend that you consider both application features that provide redundancy, protocol features that provide or restrict redundancy, and infrastructure like hypervisors that provide additional high availability benefits. For scan rate Kepware provides tools and guides to benchmarking performance to ensure data quality.

Q: Could that communication layer be integrated with the controller as one unit? And does this still ensure the device’s cybersecurity? 

A: Absolutely. For example, some devices are embedding OPC UA servers with SSL support, HTTPS servers and publishers with SSL support, and MQTT publishers with TLS support directly on controllers. In this case, you may need to transform the data before sharing with other systems  That said, oftentimes embedded data providers and controllers are lacking context and so it may still be necessary to transform the data to add additional context before the data becomes completely usable by other systems.

Q: Interested in any discussion of tag-based protocols or other protocols that support more complex and contextually rich data structures.

A: In this session, we briefly discussed differences between OPC UA, messaging queuing transport telemetry (MQTT), and HTTP protocols.

Q: How does one recover deliberately hidden data? As a consultant, my attempts to extract data from various company sources are almost always frustrated because individual employees hide data that only they know their whereabouts. We’ve not even touched on “feared” folks who refuse to upgrade to needed, primary technological skills.

A: This is largely a political concern rather than technological. It can be very hard to solve these concerns. A way to overcome this would be to discuss the cost and benefit to providing access to currently restricted data. Showing potential value from existing reference-able customers is a good way to overcome these objections.

Q: How is this integrated with Microsoft Azure?

A: For Kepserver, we integrate with Azure via our IoT Gateway Plugin using MQTT.  More information can be found here, and here.

Q: Is this solution compatible with CPwE architecture?

A: PwE is an attempt to provide a standardized topology and messaging infrastructure that itself functions as a communications layer. Kepware products can participate in specific ways as a component of the communications layers. 

Q: What if we are using OPC server to translate protocols and connect the data from the OPC server to the internet gateway. Is Kepware redundant to OPC server? In essence, the plant data sources would be narrowed down to OPC server and MES system (SQL database), a historian would be potentially another source but that is also standardized and can be connected as a direct gateway.

A: Kepware has always acted as an OPC Server and can work with OPC DA, UA, AE, .NET, and HDA applications for use with HMI, SCADA, and Historians. We also offer a plug-in, DataLogger, that can perform inserts on ODBC databases. In your application, I would send my process data to my MES via DataLogger, to the HIstorian via HDA, and to an HMI via UA. This simplifies your communication as you’ll only need to connect to your source devices once to send data to these different destinations.

Q: What about the need of a manufacturing execution system (MES) to realtime initiate a tool, like a torque wrench, and get results of the operation back in a sync style?

A: This is a common procedure for Kepware customers. As an example here is an application I saw recently while visiting an aviation parts manufacturer in Colorado. An MES is used to manage orders and contains work instructions for each job. The MES communicating with Kepserver sends down the torque value needed for the current job to the controller at the operator workstation. The correct tool program is selected in sequence as the operator builds the assembly. As each operation is performed, the actual torque value is recorded and sent back to the MES to be associated with the part. This is key for validation and production history.

Q: What if we need to update the technology stack?

A: You can expect that the applications and standards that make up your communications layer will need to be updated regularly. Therefore, it is expected you will have accommodations for system upgrades that are as low impact to the business as possible. For example, with KEPServerEX, upgrades can be done in place over the course of 30 seconds to 1 minute. We have made special efforts to enhance the upgradability of the product. As an example, projects built in previous versions are compatible with the latest builds.

Q: This might not be applicable here, but given that the data is converted into different protocols what happens when a plant is compromised, then there is an investigation or an incident response vendor to come onsite to understand the breach. Does this mean they audit the converted data or before it is converted?

A: The data would be audited at its destination as Kepserver does not hold on to the data beyond some buffering applications.

Q: Are there any recommendations for capturing data from programmable logic controllers (PLCs) where the state may change faster than the allowable scan rate to retrieve data from the PLC?

A: In cases like this, a protocol specific gateway would be necessary to provide an integration point for these high speed transactions. This gateway would consume the high speed data and bundle it for transmission in a protocol that the higher level system could work with.

Q: As I work with MES and data in this layer I am often posed with the “am I a good candidate?” question from non-integrated production lines. What, in your experience, is the best way to start this evaluation? 

A: In our roles as applications engineers we generally ask three questions. 

1. What devices do you have? 
2. What data points are you looking to interact with? 
3. What is the desired outcome?

Q: Do you have OSI PI historian drivers?

A: Normally, our interaction with OSI PI is as a northbound data destination. OSI PI supports OPC DA, HDA and UA Client connections for the purpose of consuming data from Kepware. OSI PI offers OPC server interfaces for retrieving data from the PI historian datastore. Our OPC DA Client driver can be used to attach to the OPC DA server interface.

Q: How does Kepware speak to the security posture of the Kepware server in the single point of failure?

A: We provide off the shelf and DIY tools for high availability. We also recommend that hypervisors or clustering technologies be employed, or that purpose built high availability appliances be used.

Q: How about Modbus support these days?

A: Not at this time as we haven’t had sufficient market interest. We would recommend that you explore using a converter to something like Modbus. 

Q: How is Kepware install/config managed at scale? Could it be managed centrally like Azure IoT Edge?

A: Our installation can be automated using batch scripts and command line switches; for example, we support an argument for silent installation.  For configuration, included in KEPServerEX is a RESTful API that supports Create, Modify, and Delete operations. For IoT Edge, we are not managed as a native Azure IoT Device Twin, but we can pass driver data to the IoT Edge via MQTT, and a custom module could be written for IoT Edge that manages Kepserver through the RESTful Configuration API.     

Q: What protocol we will be using from OSI layer?

A: Many; it will depend on which application layer protocol is used and its end use.

Q: Do you have a document that outlines a common sequenced approach to developing and deploying OT/MES project that you can share. Similar to the approach of developing a robotic cell, etc.

A: No, there isnt a single document available.  We do have a webinar recording on our YouTube channel that discusses PLC to database interactions as part of MES. That said, Kepserver’s role in MES varies by application around business requirements and existing systems.