OPC基金会参加EDDL项目

推进可互操作性和数据集成

Fieldbus Report recently talked to Stephen Mitschke, manager of

products for the Fieldbus Foundation, and Tom Burke, president and executive director of the OPC Foundation, about the Electronic Device Description Language (EDDL) cooperation project. This groundbreaking effort will have a major impact on the future of the industrial automation industry.

FR: Stephen, we have read that the OPC Foundation has joined the EDDL cooperation team. Before we get to why and what is taking place, can you me us what exactly is EDDL? Why is it important to fieldbus users; what is the value proposition?

SM: EDDL is an acronym for Electronic Device Description Language. EDDL is a descriptive technology defined in the International Standard, IEC 61804-2. Today, three organizations — the Fieldbus Foundation(FF), HART Communication Foundation (HCF) and Profibus Nutzerorganisation e.V. (PNO)—use EDDL technology. EDDL provides the semantics, or description of data parameters in a device to a host application. The technology provides all the necessary information to the host application for device setup and maintenance,such as parameterization, as well as helpful procedures(methods) for calibrating the device. EDDL has been around forover 10 years and has several benefits for manufacturers and users of smart devices. First, the technology is operating system independent. Being textbased, an Electronic Device Description (EDD) will interface to any host operating system.

What that means is that it is not tied to a specific automation system or operating system.This gives users the freedom to choose any operating system for their host, such as Windows or Linux. A second key benefit to users is that EDDL has a robust revision control mechanism built in. This assures users they are installing the correct support files for the correspondingversion of the device installed, even when multiple versions of the same device are present.

A third benefit is that EDDL is an international standard. Today, there are over 15 million devices in the field built on EDDL.

FR: We understand that a cooperative team comprised of the FF, HCF and PNO organizations has enhanced EDDL. What brought all of you together?

SM: FF, PNO and HCF all share a common descriptive language. There is approximately 95% overlap among the respective organization's use of EDDL. Some differences exist because of the different device features. For example, FF devices contain function blocks and, therefore, need specific language elements to support these objects. But basically, EDDL is EDDL regardless of the communication protocol being used. By cooperating, FF, PNO and HCF realized that they could standardize on a superset specification that would be used by all three organizations. Without this standardization the three organizations would have separately enhanced EDDL-leading to three divergent descriptive languages. FF, PNO and HCF recognized that they could make life simpler for manufacturers and users by collaborating. About a year ago, FF, PNO

and HCF formed a cooperative team to extend EDDL in the areas of graphic visualization and persistent data storage.

FR: You mentioned that the cooperative team began working together about a year ago. Did you view this as a single objective effort, or did you see the team setting a series of goals?

SM: This working group was the first of its kind among the three organizations. The scope of this project was focused specifically on visualization and persistent data storage, but the team also identified future areas of collaboration. The Fieldbus Foundation's End User Advisor Council validated the requirements and organizations like NAMUR played an important role in identifying areas where the three consortiums could work together to utilize the untapped capability of EDDL. The team recognized that with 15 million devices already using EDDL, manufacturers and end users had to be assured that their investments were secure for the long term. From the start, they identified critical constraints to their work, such as maintaining operating system and platform independence, insuring backward compatibility and forwarding results to the IEC for inclusion in IEC 61804-2, the EDDL Standard.

FR: To date, what results have been achieved by the team?

Stephen Mitschke Tom Burke

SM: As I mentioned, the original goals were graphic visualization and persistent data storage. Visualization improvements come in two main areas. First, the EDD developer can now better organize parameters and include helpful images in the EDD file. Instead of seeing a flat list of parameters, users will see parameters organized into windows, pages and groups. And, as with the current EDDL technology, the actual rendering of these enhanced parametric displays is done by the host application to maintain a consistent look and feel. This is important for usability and training of operator and maintenance personnel.

The second visualization enhancement comes with the addition of charts and graphs. These charts and graphs will enable enhanced device setup and maintenance for complex devices such as radar level gauges or valve positioners. The device developer does not need to be burdened with developing the entire graphing system. Instead, the EDD developer uses EDDL constructs (keywords) to define the characteristics of the graphs, and the host application renders it in a consistent look and feel.

Persistent data storage is another feature that will significantly improve and simplify device setup and maintenance. The persistent data storage feature allows the EDD to instruct the host system to safely store data for later retrieval. The EDD itself does not access the underlying file system, but rather instructs the host system on which items to store. This decoupled approach preserves

the integrity of the underlying host system. Persistent data storage is ideal for advanced diagnostic applications where a previous state of a device can be compared to the current state of a device. For example, the EDD can instruct the host application to store a reference valve signature and later load and compare it to the current signature to diagnose changes in valve performance or characteristics.

FR: We know that OPC has now joined the cooperation project. How do you see the team's efforts going forward?

SM: The team will continue its standards-based work to extend the interoperability and integration of data from the device to enterprise applications without the costs and risks incurred by using custom software drivers at every layer of the system architecture. OPC’s integration with the EDDL technology will provide far richer information to OPC Client applications using standard, platform independent interfaces. These client applications will work across a wide range of systems throughout the enterprise.

FR: You mentioned the cost and risk of custom software drivers. Please explain what you mean.

SM: I am sure that Tom will do a better job of explaining it than I can, but let me try from the Fieldbus Foundation's perspective.

Process plants are kept in operation for a significant period of time, often for more than 15 years. Software lifecycles are significantly shorter, with an abundance of revisions and changes. These version changes at the operating system level can create significant risk for the user. Device integration must not reduce the availability of the system as a whole. Custom software drivers introduce several variables that inevitably lead to integration issues. New customer software may not operate with the old system software and the new system may not operate with the older customer software. The operating system may also affect interoperability. Furthermore, revision control may be an issue if not properly managed and documented, and/or if revisions are not backward compatible.

That is the beauty of EDDL: it is operating system independent and backward compatible. If the operating system is versioned up, the existing EDD files will continue to work. No lost time, productivity or cost is incurred versioning up the EDD. No new driver is necessary,which eliminates the need for testing and verifying compatibility.

FR: Tom, could you briefly describe the technology specified

by the OPC Foundation and the new features introduced with the Unified Architecture (UA)?

TB: The initial objective of the OPC Foundation was to essentially specify a standard set of Microsoft-based software interfaces to support the exchange of runtime control data. With UA, we want to integrate those interface specifications and extend the use of OPC beyond the runtime data. The main objective of UA is to create a richer data model, to provide for platform independence and to enhance integration support between the plant floor and the enterprise system.

FR: But don’t you provide for the exchange of control data today across the interfaces?

TB: The existing OPC specifications essentially provide for the exchange of control data across multiple independent interfaces. Each interface is specified to support a particular type of data, such as runtime parameter values, alarm notification and historical data. UA is intended to not only consolidate these various OPC interface specifications, but also provide additional information to the client so that it can understand and process the data received. Today, the client receiving the data from the server can only display the information received without human intervention. There is not enough descriptive information available to allow the client to automatically process the data in any way. For example, when a client browses through a server’s parameters, it may see one labeled “PV.” The label is a free-format text field that the client can only display. The label names the value, but names are serverspecific and require human interpretation. In other words, the client software will not know it is the Process Variable parameter; it will take a user to make that determination. Consequently, identifying the appropriate data from a server requires a significant amount of human interaction with the client application.

FR: So, how will working with the EDD cooperative team help this situation? What is the value proposition for end users by combining EDDL with UA?

TB: EDDL is a technology used to describe control data. The synergism achieved by combining these two technologies will enable the team to meet the objectives of richer OPC Client applications and platform independence. By combining EDDL and OPC, the client cannot only access the data, but also the data descriptions. This allows for the development of more sophisticated, platform independent client applications, such as complex diagnostics.

Let me explain a little further. A significant part of UA is the support for type models.

Type models are technologies used to describe data commonly referred to as type descriptions. These descriptions are used by the client to automatically recognize and process the data, minimizing the required human intervention. UA allows type descriptions to be integrated into a server, but does not define the type description technology. That’s where EDDL comes in—it’s a perfect fit. The net effect is a reduction in the configuration of the OPC interface, richer information and platform independence.

FR: What motivated the OPC Foundation to join this cooperative effort?

TB: As I mentioned earlier, the goal for UA is to essentially develop a specification that is platform independent and built upon open standards. As you know, our existing specifications are built around Microsoft Windows. As we move forward with UA, we are following the W3C standards that are supported in Microsoft .Net strategy. This will insure platform independence and full compatibility with Microsoft platforms. EDDL is not only platform independent, but also communication protocol independent; plus it is an International

Standard. Considering that OPC servers support access to data from millions of devices already using FF, HCF and PNO communication technologies, and that these devices use EDDL to describe data, it is natural for OPC to use EDDL as its type description. This will provide

access not only to the data, but also to the EDD descriptions that already exist.

FR: Tom, how do you think UA will be enhanced through your involvement with the EDDL cooperative team?

TB: The same vision that drove the technology development of these organizations is essentially what drives the OPC Foundation. Users want to see open systems providing connectivity and interoperability. UA extends what these groups have done at the device level to the enterprise level. When we are done there will be open, vertical and horizontal connectivity and interoperability of applications built on standards such as EDDL and OPC UA that users can depend on. Without this standardization, industry would have to create a community of software developers to support all the different systems, each with a unique set of software drivers. With this effort between OPC and the cooperative team, the vision of delivering information from the plant floor to the top floor will be realized.

FR: You have described the benefits to instrumentation users, but how will this effort affect device suppliers? Are there benefits for them as well?

TB: The main benefit to suppliers is the ease of integratingtheir system with components of other systems. Via EDDL, the client application can automatically discover what kind of data another system has and use it accordingly. Imagine the benefit of writing a complex diagnostic package and having it transported across various hosts. The diagnostics can cover the devices and/or the process. The results can be integrated with both the control and enterprise systems. A new frontier of innovation will be opened!

FR: Tom, any last comments?

TB: Essentially, our end users are going to be the real winners when this project is completed. We believe the combination of OPC and EDDL really is the only logical approach to resolve the issues associated with interoperability and data integration.

FR: Thanks to both of you for sharing your insights on this important topic.