Everything? Well, not exactly. Unfortunately, in automation we have the same problem that physicists have: there are lots of protocols and different systems that use them. Most plants have more than one control system, and often more than one protocol. No network can meet all the needs of all the different types of process automation communications. As we’ve talked about before, most systems use OPC to convert data from one protocol to another. This way, OPC functions as the ‘glue’ that holds the network together.
The big problem with this is that control systems don’t all support OPC the same way, or to the same degree, and in many cases, there is no way, or no consistent way, of capturing and transmitting even simple items like the status bit of a transmitter. There are at least seven versions of OPC, depending on the vendor of the control system, and the vendor of any interconnecting software. You may get a good connection, or you may not. It’s a bit of a gamble.
OPC was originally “OLE (Object Linking and Embedding) for Process Control,” signifying its heritage from Windows COM and DCOM legacy connections. Recently renamed “Open Process Connectivity,” OPC and its foundation have released OPC UA (Unified Architecture), which is platform independent, and much more robust than OPC’s original implementations.
Unfortunately, OPC and even OPC UA still have their limitations, despite becoming the de facto standard for protocol conversion and interoperability. You still have to “map” parameters in the same way that mapping Modbus registers is done. Until a common language is created, it will still be necessary to create pointers between pieces of information being connected on each system. This isn’t as easy as it sounds because OPC has only limited mapping tools, and many control systems have none. Interoperability testing by the OPC Foundation is poor and minimal, leading to unexpected surprise events when integrating systems.
In addition, OPC itself is a victim of the lack of security in COM/DCOM—another legacy from Windows. There are many workarounds necessary to improve security in OPC, but many of them are proprietary and supplier specific. This, of course, restricts users to one vendor’s OPC software, and defeats the purpose of using the technology as a bridge between systems. UA is expected to improve the situation regarding OPC security.
The joint effort to update EDDL, the “common language” referred to above, is now taking shape in ISA’s newly formed SP104 standards committee. ISA is working with IEC’s leadership to develop this standard. It’s important that this committee harmonize its work with IEC SC65C WG7. The committee will create a standard that adopts the generic language specified by IEC 61804 to describe the properties of automation system components. The specified language is capable of describing device parameters and their dependencies, device functions, graphical representations, and interactions with control devices.
The language, Electronic Device Description Language (EDDL), is used to create an Electronic Device Descriptions (EDD) file. These files may be used with appropriate tools to support parameter handling, operation, and monitoring of automation system components. Applications of EDDL may include devices such as generic digital and analog input/output modules, motion controllers, human-machine interfaces, transmitters, on-off and regulating valves, closed-loop controllers, encoders, hydraulic valves, and programmable controllers.
OPC Foundation and OPC UA are deeply involved in updating EDDL, and we can expect the final version of OPC UA later this year, perhaps at ISA Expo 2006, to address many of the mapping and language concerns we’ve discussed here.
EDDL is a result of cooperation among the consortia of Fieldbus Foundation, HART Communication Foundation, Profibus Nutzerorganisation e.V., and the OPC Foundation. Enhancements recently added and officially approved as part of the IEC 61804 maintenance cycle extend EDDL’s capabilities to provide an industry-standard solution for advanced visualization of intelligent device information. Through this cooperative effort, the proven integrity of existing EDD technology is maintained across all three communication technologies (Profibus, FF, and HART). There are more than 20 million installed devices that use the existing EDDL. Its enhancements include an improved user interface with support for menus, windows, tabs and groups, as well as added graphic support for graphs, trends, charts and dial indicators.
|About the Author|