Do You Need Kepware With Ignition?
Before Ignition was on the market—and before OPC-UA was a mainstay—a very common SCADA architecture looked like:
SCADA Platform of your choice <-> Kepware <-> PLCsIf your SCADA platform of choice supported Modbus communication or it was made by the same manufacturer as your PLCs (like using FactoryTalk View and Allen Bradley PLCs) you could get rid of the Kepware piece. Otherwise, Kepware was fairly ubiquitous in the industry.
What is Kepware?
Without going into a full history lesson, before OPC-UA there was only standard OPC (now known as OPC-DA). OPC was built on top of the DCOM protocol in Windows and designed to be a standard communication protocol to use with SCADA systems and other software platforms to send process data where it needed to go.
OPC was introduced alongside Modbus, Profibus, Ethernet/IP, Profinet, FINS, and a handful of other protocols supported by various vendors. Technically, MQTT was also around at that time, but it hasn’t been very well known until recently.
Most companies didn’t support OPC directly on their hardware because they already had their own protocols. And, “open” is kind of a “four letter word” in manufacturing. There wasn’t a huge push from the hardware vendors to play nicely. (While RSLinx from Rockwell Automation supports OPC, it wasn’t always a good option back in the Wild West days.) Back then, unlocking the power of OPC was a rather cumbersome task.
To fill the void from hardware vendors, software packages like Matrikon OPC, Top Server, and Kepware KEPServerEX suite came on the market. In this context, we are using “Kepware” almost like saying Kleenex instead of tissue, but there are other options. Kepware is just a brand name, and arguably the most modern option—according to their website.
In general, all of these tools created a translation package between whatever protocol your hardware used and OPC. Now, SCADA systems from any vendor could talk to any PLC—or at least any PLC supported by Kepware, which at this point was every PLC. You could also configure protocol conversions through OPC, enabling you to integrate a Siemens PLC with an Allen Bradley PLC through OPC.
Needless to say, this was pretty powerful stuff.
Why Use Kepware?
The main reason to use Kepware was when your SCADA system didn’t have a native driver for the PLCs that you were using. For example, take Wonderware: you could talk to an Allen Bradley PLC directly, and they offered Siemens support, but if you had an Omron PLC, good luck. On a project from a lifetime ago, Corso Systems founder Alex Marcy was using the newly released Omron FINS Ethernet driver from Wonderware on a project. During commissioning, he found a bug where the fastest scan class Wonderware could achieve was 10 seconds. If you clicked a button to open a valve, it would open 10 seconds later. And likewise, you would have to wait another 10 seconds to receive feedback! Not ideal, but after he spent twenty minutes configuring Kepware, one second scan times were back on the table.
The main reason to use Kepware was because you were practically required to use it back then! Your SCADA software probably didn’t have the right drivers, and the only way to access your data was to use Kepware.
What is OPC-UA?
In the mid-2000s, the Open Platform Communications Unified Architecture (OPC-UA) standard was developed. Vendors started to adopt it in the early 2010s. Inductive Automation was one of the earliest companies to focus on OPC-UA since they—like Wonderware—were a completely hardware agnostic SCADA platform. Inductive Automation’s Ignition needed to support the biggest variety of PLCs to be a viable addition to the marketplace.
OPC-UA moved away from the DCOM limitations of OPC-DA, meaning it could also work on any computer, not just Windows machines. This opened up the manufacturing world to using Mac and Linux. While this doesn’t impact any of the industry leaders from back in the early 2010’s who all built on Windows, it opened the door for Inductive Automation to establish a foothold on all platforms.
While there are other benefits to the OPC-UA platform, it is now the standard and OPC-DA is legacy. The only reason to use or implement OPC-DA now is if you are connecting to an older device that only supports OPC-DA.
As part of the implementation of OPC-UA in the industry, platforms like Kepware integrated it into their platforms for a seamless transition to the new paradigm.
Why Use Kepware Now?
There are a few main reasons to use Kepware now…
Hardware Communication Protocols
The first reason is that your PLC hardware still isn’t supported by a native communication driver in your PLC platform. Using Ignition as an example, a good Kepware use case would be if you have Mitsubishi PLCs. Mitsubishi PLCs are as prevalent in the US as Allen Bradley, so many SCADA vendors don’t build dedicated device drivers for them.
Another example would be trying to connect FactoryTalk View systems to Siemens PLCs. Yes, while newer S7-1500 and S7-1200 firmwares include native OPC-UA servers you could use with FactoryTalk View, you will still need Kepware if you want to talk to processors without those OPC-UA servers.
Modbus Servers
Another use case for Kepware is when you need your SCADA system to act as a Modbus server for other devices in the plant. Most SCADA platforms do not include this capability and some devices or software may require a Modbus server to send data to them rather than polling them as a client.
Short of writing custom software to act as a Modbus server, Kepware is a very cost effective alternative.
Tag/Comms Standardization
One other reason manufacturing companies still use Kepware—especially in massive facilities—is to provide a standardization layer between the plant floor and the SCADA system.
Using Kepware, you can define a SCADA-side tag model and plug any and all of your PLCs into it. Then, it won’t matter which PLCs you’re using, their tag naming structure, or who programmed them. You can map the tags from each PLC to the SCADA side tag model in Kepware and integrate with any device on the plant floor relatively seamlessly.
Why You Shouldn’t Use Kepware
If your PLCs can communicate with your SCADA system’s built-in protocols, and you don’t have a need for mass standardization, Kepware is simply another moving part to worry about.
In today’s world, the most common architecture is “SCADA <-> PLCs”.
Most SCADA systems support many PLC vendors directly, and there isn’t a need for Kepware like there was 15 years ago. When you don’t need to use it, there isn’t a reason—even if you are working with some old-timers who used Kepware KEPServerEX suite “back in the day”.
Kepware is still a very viable alternative if you need to support PLCs or protocols outside of the native options in your platform.
