Choose your preferred language

Friday, May 24, 2013

From the Bottom Up: Data on the Move - Part III

Posted by Tony Paine

As we discussed in earlier parts of this blog series, the ability to exchange information between the various software and hardware components found inside of an organization is necessary to operate and maintain the day-to-day business. Tying all of the components together is a major challenge: they typically come from a wide variety of vendors, each providing a unique communications interface that will not interoperate with one another out of the box. Fortunately, communications platforms, such as KEPServerEX, exist to solve this problem.

The Evolution of KEPServerEX

When KEPServerEX was first introduced in the mid-90’s, it was developed to solve what the market referred to as the “driver problem”. At the time, this driver problem was centered around how to connect an off-the-shelf HMI to any PLC found on the plant floor. Users of these products were at the mercy of the HMI vendors: waiting for them to develop the necessary drivers that implemented the proprietary communication stacks needed for the devices running on their plant floors. When these drivers were developed, they were only capable of working with the HMI of the vendor that created it. Due to advances in the Microsoft operating system and the ability to share information between different processes using a technology called Dynamic Data Exchange, some HMI vendors introduced driver toolkits that enabled third parties to extend their connectivity offering. The initial release of KEPServerEX only supported Rockwell’s Advanced DDE interface, enabling Rockwell’s HMI to connect to devices that were previously not accessible. While great for Rockwell HMI users, this limited the value of KEPServerEX to a single vendor’s share of the market.

Thankfully, KEPServerEX was designed with forward thinking. We knew other vendors were working on their own driver toolkits, and therefore designed the system such that our drivers could be adapted to multiple vendor specific interfaces. Meaning, we created our own data model to represent real-time data, which included a Value, Time, and Valid State (which we now call Quality). This data model would provide the glue between the devices (or the driver layer) and the client applications—what we were previously calling the toolkit layer. Interoperability was achieved by simply mapping the specifics of the device and client to our internal data model. Overtime, we would implement Wonderware’s I/O server toolkit and Intellution’s iFIX driver interface into KEPServerEX, enabling connectivity from any one of our drivers to any three of these HMIs. This shifted the burden from creating a unique driver per protocol per client application, to supporting multiple client interfaces within a single server.

The next logical step would involve Industry working together to eliminate the client specific driver toolkits in favor of an open standard/API. The body that took on this task became the OPC Foundation, which released its flagship standard for exchanging real-time data between clients and servers in the late-90’s. Like the client specific interfaces previously discussed, OPC support was added to KEPServerEX and quickly became the de facto standard for interfacing our product with those from other vendors.

Looking Forward

Fast-forward to today and you’ll find that KEPServerEX supports client interfaces that integrate with Databases like SQL and Oracle, and IT tools that leverage the SNMP protocol and are able to monitor automation devices like any other IT device. KEPServerEX has also been extended to support alarm and event data, and to support the latest OPC Unified Architecture standard for the most secure communications between applications.

On the device side, KEPServerEX has continued investing in its connectivity to a wide range of PLCs that can be found in Manufacturing environments around the globe. As PLCs have found their way into other vertical markets—such as Oil & Gas, Power, Water and Waste Water Management, and Building Automation—KEPServerEX’s driver support has grown to support the types of devices specific to these market segments.

Lastly, the richness of the KEPServerEX platform has also increased over the years. We’ve continued to improve the platform’s reliability and security with the addition of Media Level Redundancy and the Security Policies Plug-In (the latter due for release in June 2013). KEPServerEX also offers the scalability our customers require with the ability to support a single data point over a single protocol, to hundreds of thousands of data points over multiple protocols. The platform’s functionality allows for machine-to-machine communications and the ability to perform basic analytics on raw data with the Advanced Tag Plug-In. In addition, KEPServerEX has added functionality to meet the needs of certain market segments. For example, the EFM Exporter was developed to meet the needs of custody transfer requirements in the Oil & Gas industry. These are only some of the value-added options that are available in the KEPServerEX communications platform.

Whether it is a new device protocol, a different client interface, or the functionality necessary to solve a need for a particular market, KEPServerEX will continue to evolve to meet the ever-growing need for data and the complex communications requirements of tomorrow.