OPC maximizes object-oriented systems

THE OPC COMPLEX Data specification, released in December 2003, describes a new way to pass data from one OPC DA server to another, making it easier for vendors, OEMs, machine builders and end users to connect new, smarter devices together. The current DA specification requires data items to be simple types or arrays of simple types, so OPC DA servers represent data as a sequence of bytes. Under the current specs, there is no way describe the structure of these bytes. Clients receiving structured  data are unable to interpret it unless the OPC server provides the data as items or arrays of simple data types.

As OPC field devices get more complex, they are creating much more information, and it is becoming much more complicated and harder to deal with them. Some PLCs, for example, are now using structured variables. Field devices are getting much smarter, and have more data to transmit than just process variables. The Complex Data specification will solve the problem.

“OPC Complex Data is all about providing a way to pass data that doesn’t fit into the 'word, bit, integer, float’ tag format of OPC DA,” explains John Weber, president of Software Toolbox. “For example, a variable named 'My Structure’ might contain five floating-point variables, two Boolean values, and three integers. A common example is a PID loop in a PLC. With classic OPC DA, the only way to read that data is to make one tag for each element of the structure.”

Weber says that works when you only need a few variables from the structure. If you need the entire structure, and your system has many such structures, this is not the most efficient way for an OPC client and server to pass data. “The OPC Complex Data initiative is all about providing a more efficient means for passing large numbers of Complex Data structures between an OPC client and server,” he says. 

TIGHTLY INTEGRATED CONTROL LOOPS

Across sophisticated processes, the ability to seamlessly commujnicate among devices and integrate disparate business and control systems is a growing priority. With its ability to address any object-oriented device, OPC Comples Data will help companies make it happen.

Steve Redcay, product specialist at Phoenix Contact's Automation Systems Group. Middletown, Pa., provides an example, using Complex Data with variable-frequency drives (VFDs). “A structure is a collection of different-type variables under a single name,” he explains. “Some simple parameters of a VFD could be 'RampUpTime,’ 'RampDownTime,’ 'MaxSpeed’ and 'MinSpeed.’” As John Weber said, current OPC data would require an independent tag for each parameter. This means there would be four tags for each VFD in the system. As the number of VFDs increases, the program becomes less efficient and there is more likelihood of programming mistakes."“One structure can contain all the parameters for the VFD, so to 'parameterize' the VFD we need only call one variable. Also each parameter can be addressed separately using an identifier, such as 'VFD_1.RampUpTime.’ This is a more efficient way of passing large or complex groups of data.”Phoenix Contact is already using the Complex Data in its products. “We recently added Complex Data to our Ethernet infrastructure,” says David Skelton, Director of Automation at Phoenix Contact. “For example, all of the conditions and set up of a managed Ethernet switch are shared and can be maintained through traditional control and HMI platforms. This alternative allows the maintenance department to continue to provide first response while the IT department provides second-level support. The support of Complex Data just makes it easier to implement this type of system with fewer errors.”Not Just For the New and SmartOnce again, as in the case of OPC XML it’s not just new, smart devices that will benefit from this new spec. Scott Saunders, director of strategic marketing at Moore Industries, says Complex Data can be used on all OPC-based equipment. “This will allow applications to not only read process variable data from sensors, but also complex binary arrays and patterns that can be used for preventive maintenance,” he predicts. “Since most of the 'smarts’ reside at the sensor level, the data can be analyzed locally and sent up the IT food chain where it can be viewed in a useful format, instead of waiting for the data mining programs to interpret the confounding patterns and anomalies.”Complex Data can be used for many predictive maintenance and CMMS applications, such as oil analysis, vibration, power spectrums, or thermal images generated by infrared thermography. Today, OPC DA clients might be able to read vibration waveform data from an OPC server, but probably have difficulty interpreting and using the data. Complex Data will allow OPC client applications to read and decode any type of data being generated by OPC-based measurement and control systems on the plant floor.Randy Kondor, OPC Product Manager at Matrikon, Edmonton, Alberta, Canada, says that Complex Data will make it much easier to communicate with DCSs. “While OPC DA is a good match for the simple data structure of most PLCs, Complex Data is an excellent match for the 'Object’ or 'Tag’ concept of a DCS,” he explains. “Control loops can be treated as a single entity, and equipment will follow suit. This will enable much tighter integration between the DCS and data-consuming applications such as HMIs, Process Historians and advanced process control applications.”Eager OPC Vendors AwaitThere have been many attempts at developing “Object Oriented” environments for industrial automation, most of which have met with differing degrees of success. Most of these attempts were driven by individual companies, so the development of standards for defining the structure of objects and data was, in many cases, slanted to the developer. Several standards bodies are developing conventions for data representation, such as ISA and MIMOSA, but these organizations by themselves do not have the strong market traction required to move a large number of vendors to their standards. Enter the OPC Foundation and Complex Data. The Complex Data specification provides a standardized method for defining the format of a Complex Data element using either XML or binary system IDs. As noted above, data can now be defined to carry all of the information regarding the complete operation of a particular object. In PID objects, for example, developers using OPC Complex Data will be able to provide complete templates for the PID object, including HMI elements for display, alarm elements for alarm management, and historical elements for data collection. “An object-oriented environment that is OPC Complex Data enabled will be able to address any device for which a Complex Data server exists,” says Mark Hensley, president of Kepware Technologies. Yarmouth, Maine. “As has been seen with OPC DA, AE, and HDA, the wide range of vendors supporting these technologies ensures that Complex Data OPC servers will be available for many of the popular control systems and devices in use today.”“We see the need for Complex Data with many of the new device drivers we are writing,” continues Hensley. “Having developed many OPC DA servers, we have had to play games in some cases to get structured data in and out of these devices due to the limitation of current data functions available to a DA server and client. Once Complex Data takes root, we will be able to go back to these drivers and rework them to take advantage of Complex Data, giving our user better control of their systems while simplifying their application design. I believe that as we have seen an explosion of OPC products over the last few years, Complex Data may very well rekindle an explosion of object oriented products.”

Defining the Data

Complex Data means an OPC DA data item that has a defined structure. OPC DA specs do not describe structures, so the Complex Data spec defines the information – represented as OPC DA item properties –so that OPC DA servers may make this information available to OPC DA clients.

TABLE: COMPLEX DATA ITEM I/O DEVICE DESCRIPTION

Data Point	Description
Device Name	A unique identifier for an instance (i.e., the name of the device).
Device Settings	A list of common strings used to initialize the device on connection.
Wait Time	The time the server waits after a connect failure before reconnecting.
Connect State	Whether or not the server should attempt to connect to the device.
Last Connect Time	The last time the server connected to the device.
Connect Fail Count	The number of times the server attempted and failed to connect to the device.
Is Connected	Whether or not the device is currently connected.

The Table above shows an example of a Complex Data item that describes a connection to a physical I/O device. The item includes read-only information, runtime status, and writeable control points. The structure could be represented in a DA server as multiple DA items, but the DA client would not be able to read a coherent snapshot of the connection status, because the status could change while each individual item is being read. OPC Complex Data solves this problem by providing a mechanism to describe Complex Data structures contained within the DA server namespace and providing a mechanism to represent complex structures as single DA items that clients may access as atomic blocks of data and still be able to access the contents of these atomics blocks by using the type descriptions. Complex Data items can include simple non-structured items, abstract elements, abstract items, structured items, strings, integers, sequences of bytes (BLOBs), XML data, OPC binary, and all other OPC data items. Complex Data encompasses them all. Each data item is accompanied by a Data Type Description that defines the structure of the item, and a Dictionary that describes each of the Data Types. The dictionary contains all the information that a DA client needs to understand the Complex Data items it is receiving. For example, if the Complex Data item includes an XML document, then the dictionary will contain the XML Schema that defines the document. All the necessary dictionaries are kept on the DA server, so the DA client can easily obtain all the definitions it needs.