Thursday, October 17, 2019

Introducing ThingWorx Kepware Edge

Posted by Jeff Bates

Today, the entire PTC Kepware team achieved a major milestone by releasing ThingWorx Kepware Edge. It is the first "Version 1.0" Kepware product released in more than 12 years and represents a dedicated and coordinated effort from all departments and functions. In this post, I'll detail what the product is, why we built it, and how it is different from other Kepware products.

What is ThingWorx Kepware Edge?

As detailed on the ThingWorx Kepware Edge product page, “ThingWorx Kepware Edge allows the most valuable features of KEPServerEX to be deployed in Linux-based environments, enabling connectivity directly at the site of the machine, device, or sensor.” This enables an improved connectivity architecture when connecting automation applications (like SCADA, MES, or Historians) or IoT applications to remote PLCs, sensors, or other devices. Specifically, the product can connect to:
  • Any device using the ubiquitous Modbus Ethernet protocol, including controllers from Schneider Electric, B&R, ABB, and many others
  • ​Siemens S7 devices such as the S7-300, 400, 1200, and 1500 
  • Allen-Bradley ControlLogix devices such as ControlLogix, CompactLogix, MicroLogix, and legacy PLC 5 and SLC 500 devices using gateway/ENI modules 
The product provides data access from these devices to:
  • Traditional and next generation industrial automation clients via OPC UA
  • Cloud, industrial IoT, and big data platforms via MQTT, including Azure and AWS
  • ThingWorx, the leading Industrial IoT platform
I’ll touch on why “on-site” connectivity is so important in the next section, but ThingWorx Kepware Edge is essentially a sub-set of KEPServerEX functionality that can be deployed in a Linux environment.

Why did we build ThingWorx Kepware Edge?

Primarily to connect remote devices directly at the site of the device. There are several industries and company types that need to connect to remote devices, including:
  • Upstream and mid-stream Oil & Gas companies that need to monitor and control field sites; sometimes a production site could be in North Dakota with a SCADA system hosted in Houston, TX
  • Water/waste water technicians that need to monitor remote treatment and/or pumping sites 
  • Machine builders who are under increasing pressure to provide native connectivity to the machines they build, either to connect to local applications or to cloud-based IoT platforms 
Today, these assets either go unconnected or are connected to a centralized OPC Server via a wide-area network. Unconnected assets obviously leave value uncaptured—they cannot be monitored, controlled, or analyzed for performance improvements. Connecting to a centralized OPC Server is also less than optimal. It means that insecure protocols, such as Modbus, are going beyond the local network. It’s also inefficient, since Modbus and other similar protocols are request-response protocols, meaning they are constantly using bandwidth. In many cases, such as with machine builders, connecting remotely via these insecure industrial protocols simply isn’t an option. No machine builder customer is going to allow critical production data to leave their operations network without adequate security.

The solution is a change in architecture. If compute is added at the device or asset site, data can be translated into secure, efficient protocols before leaving the local network. This makes it much easier, more secure, and cost-effective to send that data to remote monitoring and control applications and cloud-based IoT platforms. Easier because these platfroms can natively consume protocols like OPC UA and MQTT, more secure because those protocols use modern encryption, and cost-effective because those protocols only send data when it changes, decreasing bandwidth usage. 

So why don’t organizations utilize this on-site, distributed architecture today? To date, most have balked at the idea of deploying a Windows-based machine and full OPC Server at each remote site. That can be expensive and creates IT headaches. Updating hundreds of remote Windows machines could keep an IT team busy full time.  

ThingWorx Kepware Edge is a more cost-effective and manageable solution. It’s Linux-based, so users don’t incur OS-related cost when adding additional nodes. And Linux-based OSs typically require fewer updates and patches than Windows-based systems. Additionally, the product is priced on a per-tag basis, so users don’t have to pay the typical price of a full-blown OPC Server if they are just monitoring a couple hundred tags at each site. ThingWorx Kepware Edge is also headless and remotely configurable so it can be centrally managed. ThingWorx Kepware Edge gives users a distributed, secure approach to connecting remote assets. 

Remote asset connectivity is the primary driver for building ThingWorx Kepware Edge, and most of the customers we’ve worked with to develop the product are interested in deploying the distributed connectivity architecture I’ve described here. That said, we don’t anticipate this will be the only use of the product. As the Industrial IoT market matures, we’re seeing Linux-based environments being used in a wide variety of new and innovative ways. Part of the impetus of ThingWorx Kepware Edge is to ensure that PTC Kepware can continue to provide best-in-class industrial connectivity to our traditional and new customers as the market continues to evolve. If you’re deploying innovative technology into an industrial environment, we want to help solve your interoperability challenges, regardless of the operating system you’re using.

Is this KEPServerEX on Linux?

Hopefully it’s clear that the use case for ThingWorx Kepware Edge is very different than a traditional KEPServerEX deployment. KEPServerEX generally serves as the connectivity backbone for a production facility. A single instance of KEPServerEX on a Windows Server can monitor an entire work cell, line, or site, and each server can monitor and control hundreds of thousands of tags at very low latency. We don’t anticipate that our traditional customers will switch the servers in their data centers or DMZs from Windows to Linux OSs in the near term. 

ThingWorx Kepware Edge also provides highly reliable and secure connectivity between industrial devices and critical applications, but the value of the product is in enabling a new, distributed connectivity architecture, especially to connect remote devices. We don’t intend for it to be a like-for-like replacement of KEPServerEX, and we will work primarily with customers who need to deploy a network of ThingWorx Kepware Edge nodes. The product will enable Kepware to provide value in new use cases where KEPServerEX wouldn’t be an option. 

Additionally, the product has some key differences that users should be aware of. ThingWorx Kepware Edge is headless—all configuration happens through a REST API and command line interface. While the drivers included in ThingWorx Kepware Edge are very similar to the drivers included in KEPServerEX, there are also key differences. Please review the product pages and user manuals for more details on what features are included in each of the drivers.

Learn More

On behalf of the PTC Kepware team, thank you for your interest in ThingWorx Kepware Edge. We are looking forward to working with you to deploy the solution and improve your connectivity to remote assets. To learn more, please register for the ThingWorx Kepware Edge Version 1.0 Release Webinar on November 13.