Dec 20, 2012

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

Posted by Tony Paine

Last time, we looked at how data was traditionally moved from plant floor devices to various applications, as well as how that data is turned into information. This time, we will examine how some standards groups have tackled issues with interoperability and turning raw data into information.

Integrating business applications into a manufacturing environment is still an ad-hoc process. Applications have been developed as one-size-fits-all solutions. Typically, Service Oriented Architecture (SOA) integration points are provided for professional service firms to customize as needed. Fortunately, industrial automation hardware and software product providers have worked together to simplify the integration between these applications and the plant floor.

OPC Classic 

This simplification process has been incremental over the past several years. The first part was the abstraction layer between the communications interface and the disparate systems. This was accomplished through a technology known as OPC Classic, whose goal when first introduced was to tie software applications running on Windows-based personal computers with equipment on the plant floor. The communications interfaces for this equipment targeted RS232-based serial communications, TCP/IP sockets, and sometimes even proprietary card-based solutions. Most of the older equipment is what we now refer to as dumb devices: in order for one device to leverage the capabilities of another, an automation professional had to wire and configure the systems accordingly. This is far from the plug-and-play world we have come to expect today. Furthermore, these systems provided very raw data. Without innate knowledge of the systems, it was meaningless to anyone or anything else in the environment.

With its focus on generic connectivity in the initial releases, OPC Classic did not recognize a need to transform the raw data into something that could be provided to a multitude of users and systems. This came to be seen as a hole in OPC technology.

OPC Objects

Establishing Standards

Over the years, different domain-specific groups formed to determine how to define and represent data to meet specific domain needs. For example, the Organization of Machine Automation and Control (OMAC) developed PackML, which is a naming convention for common data items used throughout the packaging industry. In some cases, industry groups did not just limit themselves to specifying how the data was defined, but also included how the data would be discovered and exchanged between different parties. An example of this is the Building Automation and Control Network (BACnet) standard developed by the American Society of Heating, Refrigerating, and Air-Conditioning Engineers (ASHRAE). This standard defines how the objects that are common to building automation will be represented, in addition to the wire protocols that will be utilized to exchange this information.

With each new way to exchange information comes the challenge of interoperability. Clearly, the building automation infrastructure found in a manufacturing environment is just as critical as the industrial control system that produces products. So why would we want to monitor them any differently?

OPC Unified Architecture (OPC UA)

Specific OPC Classic data sets (such as real-time data, alarm and event data, and historical data) are exchanged using unique service sets. Introducing new service sets for each different type of data is not feasible, however. Data is data: users want to discover it, understand it, set it, and monitor it. Unified Architecture (UA), the latest generation of OPC technology, defines a generic set of services that provide access to any type of data conforming to basic guidelines as defined by the standard. The focus is then on modeling data based on the UA guidelines, which is a practice that has been used within OPC to model real-time, alarm, and historical data. This enables the OPC Foundation to map to information models from other standards organizations through OPC UA, thus enabling vendors to focus on domain-specific data modeling instead of how to connect and gather data from others.

Many to many

As more companies implement OPC UA technology, end users will begin to realize its benefits. They will be able to enjoy the simplicity of connecting disparate systems, allowing them to coexist securely and to leverage the capabilities of almost anything within that manufacturing ecosystem. As plant floor devices become richer and provide data with context, there will be less time spent on making sense of all the bits and pieces and more time spent on solving business problems.

Next Time…

In the last installment of this three part series, we will examine how Kepware is solving the complex issues of moving data and transforming information. We will take a look at KEPServerEX and how it has grown from an OPC DA Server to a robust communications platform. We will discuss how its modular design meets both the simplest and the most difficult requirements, and will also review a few of its advanced communication options.