Emerson’s Jonas Berge posed this question, which he addressed in his Emerson Exchange presentation with the same name. His abstract:
Keeping the system up to date with new types and versions of 4-20 mA/HART, WirelessHART, FOUNDATION fieldbus, and PROFIBUS devices as they come into the plant over its operational life is a challenge in most plants. This workshop will explain the often misunderstood role of Device Description (DD) files in interoperability and compatibility, how to manage DD in projects, and how to keep the system up to date with intelligent devices. Users of Emerson devices on Emerson systems, Emerson devices on third-party systems, and third-party devices on Emerson systems benefit alike from this session.
[slideshare id=14789178&doc=device-revisions-management-best-practices-jonas-berge-121018142602-phpapp01]
Modern, microprocessor-based instrumentation has provided a wealth of flexibility and diagnostic information that was not possible before. The challenge of these devices and their associated communications is keeping the system up to date with new types and versions of protocols available including HART communications, WirelessHART, Foundation fieldbus, and Profibus.
Jonas highlights the role of DD files in compatibility and how this technology is sometimes misunderstood. To properly connect to a host system such as a control system or asset management system, intelligent devices require software integration. This software can change in many locations, such as the communications protocol (HART, Foundation fieldbus, etc.) level and at the device level as automation suppliers add additional capabilities to their intelligent devices over time.
The IEC 61804-3 EDDL standard describes EDDL (Electronic Device Description Language) files of the intelligent devices so the computer knows how to talk to these devices. These EDDL files live in the host computer and not in the intelligent devices. All host systems use the same unique EDDL file for each device and there is no need to upgrade the system software version to match the device version. This ensures backward compatibility so that new software and handhelds work with old devices. It also means forward compatibility so software and handhelds will work with future devices without software upgrade.
Jonas explained how the process works. The device manufacturer makes the EDDL file. It lets the host system know the features available for that device. These EDDL files keep the system up to date with new devices and new systems and handhelds have these EDDL files preloaded. As new devices and EDDL files are created, they can be loaded the host. This method assures interoperability of any device with any system or handheld device supporting this EDDL standard and means that all devices can be managed from the same software.
Systems are kept up to date and compatible with new devices by loading the DD file for the device onto the system. This method works the same independent of the underlying communications protocol for HART, WirelessHART, Foundation fieldbus, and Profibus.
Jonas noted that downloading and synchronizing software has become commonplace in our world of smart phones, tablets, PCs, and other smart devices. Updating EDDL files follows this same process of being downloaded from the Internet and loaded on the system.
He next covered the basics of device revision management. If a new revision of a device were received, you would obtain the EDDL file for that device revision and load on your system. For instance, if a HART revision 7 device arrives in the plant, you would get a DD file for device for revision 7. Here is a Device Install Kit website to find the files for your smart device.
A common misunderstanding is to think in terms of the DD revision for a device. This is not right because the device does not know about DD files and they are not inside the device. The way to think about it is to ask, “What is the device revision of the device?” and “What device revision is this DD file used for?”
Jonas showed some examples using a 475 handheld device and an automatic update for DeltaV and AMS Device Manager users, which automatically downloads new DD files from the Guardian server. The system is automatically kept up to date, ready for new device types and versions as they come to the plant.
In the presentation, Jonas also highlighted the process of versioning and file names, advancements in the DD technology to include wizards and enhanced menus and graphics. He also contrasted device files versus system files, plant operations & maintenance, device revision troubleshooting, solutions and results. He closed summarizing the overall benefits:
- Device revisions are the “problem”, DD is the solution
- Device revision affect all protocols
- Study revision management further
- Exercise device revision management
- Project execution
- System administration
- Automate device revision management
- Reduce project delays (commissioning)
- Greater availability (device replacement)
Update: I’ve fixed the error above incorrectly associating a revision with the HART protocol. The revision was associated with the Rosemount 3051C in Jonas’ example.
