KEPServerEX, commonly known as Kepware, is a powerful software platform that provides connectivity to industrial automation systems, devices, and data sources. It enables users to extract data from a wide range of industrial machines and devices, including those that do not support common protocols like OPC-UA, S7, or Modbus. With 142 drivers available, KEPServerEX's library is significantly larger than that of Node-RED, which is included with the United Manufacturing Hub (UMH).
In the context of a "Unified Namespace" architecture Kepware may face some technical limitations when dealing with certain types of data, such as high-frequency data or high-volume data. We do also see limitations in regards to reliability, scalability and maintainability (see also our MQTT broker comparison article for more information on these requirements). The United Manufacturing Hub can help with these challenges by using a message broker architecture based on MQTT and Apache Kafka ("Unified Namespace"), technologies that are designed to handle high-frequency and high-volume data with ease.
In this article, we will discuss the advantages and limitations of using Kepware, and how it can be leveraged together with the UMH to overcome these challenges. We will also link to a tutorial on how to use Kepware with the UMH to extract data.
Advantages and Limitations of using Kepware
When it comes to using Kepware, there are both advantages and disadvantages to consider.
| Pros | Cons |
|---|---|
| Large library of machine drivers and comprehensive protocol support | Certain types of data not supported (high-frequency or high-volume) |
| Well-established product | Runs on Windows only, no Docker support |
| Cost-effective (especially compared to IIoT solutions) | No clustering or failover |
| No automated configuration, versioning and disaster recovery | |
| No integration with alerting systems |
On one hand, Kepware has a large library of machine drivers, which makes it a valuable tool for connecting legacy equipment and production lines that do not support common standard protocols such as OPC-UA, S7 or Modbus. This allows users to extract data from a wide range of industrial machines and devices, including those that do not support common protocols.
On the other hand, Kepware has some technical limitations that need to be taken into account when designing a state-of-the-art IT / OT architecture. For example, it may struggle with certain types of data, such as high-frequency data or high-volume data. It has limitations in terms of polling frequency, so it is not suited to transmit for example vibration data in a frequency required for a proper vibration analysis (FFT, etc.). Furthermore, it is only possible to transmit single "tags" (a number, a string, etc.), but not large files like CAD file or an image.
Additionally, Kepware is not suited to run on the edge, as it requires Windows. It is only deployable on a Windows VM, which prevents multiple users working on the system at the same time.
It is, similar to historians, not integratable into the modern IT landscape:
- No clustering or failover (there is a redundancy master out there, but it reached its end of life support in 2016 )
- No automated configuration, versioning and disaster recovery. Configuration must be exported and backuped manually
- No integration with alerting systems, so it can (and will sometimes!) fail without anyone noticing (except that there is some data missing)
In summary, while Kepware is an well-established product with a large library of machine drivers and can be a valuable tool for connecting older production lines that do not support standard protocols, it also has limitations with high-frequency and high-volume data, and it is not easily integratable into modern IT landscape.
Mitigate its limitations
Kepware's shortcomings can be mitigated to some degree:
- Usage may be focused on rare drivers, where machine OEMs and other vendors do not offer supports for it. For example, the integration of OPC-UA compatible production equipment may be better suited with something like Node-RED.
- Use it to only communicate with the Unified Namespace as only this allows to transmit high-frequency data points. Use cases that require high-frequency and high-volume data such as vibration or images cannot be supported when using Kepware as a central data hub.
- Increase overall security and mitigate dangers in terms of unpatched security vulnerabilities by putting it into an isolated environment, so that no other system needs to have access to it.
- Put an alerting system around it, so that you get notified when there is no data coming in for all or some of your PLCs. We are planning to this with our Management Console in the future.
The United Manufacturing Hub provides these missing pieces and allows Kepware to be used in the modern IT / OT landscape. To utilize Kepware, it is necessary to have a Windows Virtual Machine (VM) in addition to an instance of the UMH. We provide a comprehensive tutorial on how to install Kepware on a Windows VM, configure the OPC-UA connection to the simulator included in the UMH, and ultimately send the collected data to the MQTT broker.
Conclusion
In summary, Kepware is an older, but well-established, software product with limitations, but its extensive library of machine drivers makes it crucial in connecting older equipment. The UMH can help in overcoming these limitations by utilizing a message broker architecture. We encourage readers to try integrating Kepware with the UMH and share their experiences. Reach out to us for any questions or assistance or join our Discord!
