PLC & Control

Integrating field devices in process automation is an evolving story, and users are still grappling with rewriting different endings to fit their manufacturing processes. The task at hand for several years has been how to provide a common interface look and feel for all devices, finding software that allows staff to access and manage engineering, startup, and maintenance data during operation and maintenance phases. But the proof is in the pudding. Can one technology really meet all industry demands? Our test lab took one software technology to task—with promising results. Today’s market demands require manufacturers to implement multi-phase coverage of system life cycles. Two technologies are making waves in the marketplace to facilitate this: field-device tool (FDT) and electronic device description language (EDDL). (See accompanying articles on FDT and EDDL.) Although both have their advantages and disadvantages, they should meet user demands, as formulated under Normenarbeitsgemeinschaft für Mess-Und Regeltechnik (NAMUR) Recommendation 105, imposed for integrating fieldbus devices into engineering tools for field devices. The most important of these demands include: Device descriptions should be independent of the operating system involved. User interface and style guides are necessary. Device installation/uninstallation should incorporate into configuration tools. Device functionalities should see full support. The FDT technology group met with EDDL’s cooperation team (ECT) last spring at Hannover Fair in Hannover, Germany, to become official members of the ECT. The goal was to develop a common future device integration (FDI), based on a client server architecture and hopeful as an international standard. The FDI would be based on an independent platform and operating system and independent host system. It would be compatible with existing EDDL- and DTM-based device descriptions and applicable to any field device communication technologies. It would also be applicable for hierarchical and heterogeneous network topologies and an open specification. Lab tests EDDL with use cases BIS Prozesstechnik’s testing laboratory in Frankfurt, Germany, conducted comprehensive testing to clarify the extent to which the current EDDL standard allows the process automation industry to meet the demands of device startup, operation, and diagnostics. During an online test, the lab developed a series of typical user cases that could arise during device life cycles and verified these on existing devices. We tested the utility of enhanced EDDL and its advantages and disadvantages from the user’s perspective. This test program included four phases: planning, startup, operation, and maintenance. Each use case contained a series of testing stages. The test system contained devices for measuring temperatures, pressures, and fill levels, as well as various actuators and a frequency converter. Devices equipped with Fieldbus Foundation (FF)/HART/Profibus decentralized peripherals (DP)/process automation (PA) interfaces were available. Planning, startup phases Here are some answers to users’ questions during planning and startup phases. Q: Which device models suit which electronic device descriptions (EDD) revisions, and are there any incompatibilities between host-system EDDs and device EDDs? A: The authors of the specification believed it was important to keep existing EDDs from FF/HART Communication Foundation libraries upwardly compatible to protect existing installations. Compared to HART and FF, Profibus supports the most extensive subset of the entire linguistic syntax specified under the standard. Its Profibus DP devices, e.g., frequency converters, which are employed in manufacturing industries, frequently impose more stringent demands on their operation, and thus on the software applications involved. BIS noted host manufacturers were working feverishly to implement the standard, and had either already implemented it within broad areas or will have completed its full implementation in the near future. Because of the various states of development, some dependencies remain. For example, one of the host systems tested did not support representations of operator guides (wizards) and yielded host-dependent EDDs. If the suppliers of host systems uncompromisingly and fully implement the standard as they have stated, we can realize interoperability—a single EDD per device. Q: Which software tools are needed for planning and startup phases? A: For planning and startup purposes, it is sufficient to install an EDD host system that makes available a number of basic functionalities and covers every device involved. The next step is to load the enhanced EDDs supplied by device manufacturers onto the respective host systems for each device involved. Offline viewing of the EDDs then provides users with a brief overview of the applications and features of the various devices. The devices involved frequently incorporate numerous (usually well over 200) parameters. Users formerly had to search through long lists of parameters to find the correct ones before setting these on each device. However, users only need short subsets of parameters for their applications. These most-important parameter settings may be set by wizards that allow rapid, intuitive, device startups. Q: Which protocols does EDDL support? A: IEC 61804-3 describes the language content for use with FF/HART/Profibus DP/PA devices. None of the host systems currently available support all protocols involved. However, Emerson Process Management and Siemens have said their host systems will support all three protocols within the next year or two. Q: Are software updates necessary to use all features? A: In the case of all those EDDs installed, the lab found the host systems currently being supplied almost completely support all EDDL enhancements. Since current EDDs have been only slightly tailored to suit given host systems in areas related to their graphical user interfaces, those host systems need no updates or add-ons to fully execute such EDDs. However, the goal must be the ability to use EDDs that exploit the full complement of EDDL’s features on any host system. Operation, maintenance phases Q: Is error-free installation of an EDD possible, even on existing installations and during operation? A: A catalog of devices will usually be provided for installation of a host system. Some or all of these devices may be installed on the system. Host systems have their own applications for retrofitting devices. EDD setup procedures will thus have the same look and feel, which is highly beneficial. Even during operation, installation of device EDDs using the applications mentioned proceeded rapidly and without errors. Since the EDD syntax is translated, or interpreted, only by the host system, EDDs have no effect on the operating system involved. No restarts were necessary following their installation. There also were no interactions with Windows system files. Q: Can devices be simply, intuitively operated? A: The lab defined a series of different applications scenarios for various types of devices, ran the applications, and analyzed the results. Example scenarios included rapid operational procedures under which users had to set only the most-important parameters and conduct procedures typical for the devices involved. These procedures included the partial-stroke test for actuators and determinations of the echo profiles of fill-level radars. A series of language enhancements under IEC 61804-3 allow much more flexibly configuring user interfaces than was formerly possible. The first step involves setting the values of parameters, such as starting position and step length. A graphical display clearly informs users what each parameter means. The second step involves measuring the reference time and determining the limits beyond which violations of the reference time will trigger notifications about maintenance status. Users may then conduct a partial-stroke test, save the plot, and compare it to earlier measurements. This sort of representation guides users step by step through the procedures involved, without the need to consult other documentation. It is a good example of how to use EDDL to intuitively implement a complex operational procedure. Q: Is it feasible for interfaces and operational procedures to have a common look and feel? A: All host systems support a number of basic functions, such as reading, writing, printing, numerical comparisons, and data storage. The lab found in all cases users could call up certain functionalities, such as device status transmittals or processing parameter displays, from the same locations. Since those basic functions are not constituents of EDDs, they appear on the respective host systems in forms that have a common look and feel. However, device operational procedures or parameter terminologies, which are usually implemented in EDDs, differed from manufacturer to manufacturer in this test program. Text entries and tabular data previously dominated visual displays of EDDs. It is now possible to implement much more sophisticated interfaces, although they may differ widely from manufacturer to manufacturer. It is imperative to develop a guideline to implement EDDs for typical types of devices from all manufacturers, particularly during early implementation of the standard. That guideline should cover the terminology used to define parameter names and devote particular attention to how the parameters involved are formatted, including their offline/online representations and diagnostics. Q: Can all device functionalities be implemented using EDDL, or are additional tools necessary? A: Of course, the growing complexity of the current generation of processing devices imposes more stringent demands on user software. EDDL is frequently criticized for its failure to allow implementation of complex device operational procedures. However, the BIS testing showed all operational procedures relevant to the tested devices could be implemented without the need for additional software. These included the handling of interfering echoes in the case of fill-level radars, the calibration procedures for temperature Device descriptions should be independent of the operating system involved. User interface and style guides are necessary. Device installation/uninstallation should incorporate into configuration tools. Device functionalities should see full support. The FDT technology group met with EDDL’s cooperation team (ECT) last spring at Hannover Fair in Hannover, Germany, to become official members of the ECT. The goal was to develop a common future device integration (FDI), based on a client server architecture and hopeful as an international standard. The FDI would be based on an independent platform and operating system and independent host system. It would be compatible with existing EDDL- and DTM-based device descriptions and applicable to any field device communication technologies. It would also be applicable for hierarchical and heterogeneous network topologies and an open specification. Lab tests EDDL with use cases BIS Prozesstechnik’s testing laboratory in Frankfurt, Germany, conducted comprehensive testing to clarify the extent to which the current EDDL standard allows the process automation industry to meet the demands of device startup, operation, and diagnostics. During an online test, the lab developed a series of typical user cases that could arise during device life cycles and verified these on existing devices. We tested the utility of enhanced EDDL and its advantages and disadvantages from the user’s perspective. This test program included four phases: planning, startup, operation, and maintenance. Each use case contained a series of testing stages. The test system contained devices for measuring temperatures, pressures, and fill levels, as well as various actuators and a frequency converter. Devices equipped with Fieldbus Foundation (FF)/HART/Profibus decentralized peripherals (DP)/process automation (PA) interfaces were available. Planning, startup phases Here are some answers to users’ questions during planning and startup phases. Q: Which device models suit which electronic device descriptions (EDD) revisions, and are there any incompatibilities between host-system EDDs and device EDDs? A: The authors of the specification believed it was important to keep existing EDDs from FF/HART Communication Foundation libraries upwardly compatible to protect existing installations. Compared to HART and FF, Profibus supports the most extensive subset of the entire linguistic syntax specified under the standard. Its Profibus DP devices, e.g., frequency converters, which are employed in manufacturing industries, frequently impose more stringent demands on their operation, and thus on the software applications involved. BIS noted host manufacturers were working feverishly to implement the standard, and had either already implemented it within broad areas or will have completed its full implementation in the near future. Because of the various states of development, some dependencies remain. For example, one of the host systems tested did not support representations of operator guides (wizards) and yielded host-dependent EDDs. If the suppliers of host systems uncompromisingly and fully implement the standard as they have stated, we can realize interoperability—a single EDD per device. Q: Which software tools are needed for planning and startup phases? A: For planning and startup purposes, it is sufficient to install an EDD host system that makes available a number of basic functionalities and covers every device involved. The next step is to load the enhanced EDDs supplied by device manufacturers onto the respective host systems for each device involved. Offline viewing of the EDDs then provides users with a brief overview of the applications and features of the various devices. The devices involved frequently incorporate numerous (usually well over 200) parameters. Users formerly had to search through long lists of parameters to find the correct ones before setting these on each device. However, users only need short subsets of parameters for their applications. These most-important parameter settings may be set by wizards that allow rapid, intuitive, device startups. Q: Which protocols does EDDL support? A: IEC 61804-3 describes the language content for use with FF/HART/Profibus DP/PA devices. None of the host systems currently available support all protocols involved. However, Emerson Process Management and Siemens have said their host systems will support all three protocols within the next year or two. Q: Are software updates necessary to use all features? A: In the case of all those EDDs installed, the lab found the host systems currently being supplied almost completely support all EDDL enhancements. Since current EDDs have been only slightly tailored to suit given host systems in areas related to their graphical user interfaces, those host systems need no updates or add-ons to fully execute such EDDs. However, the goal must be the ability to use EDDs that exploit the full complement of EDDL’s features on any host system. Operation, maintenance phases Q: Is error-free installation of an EDD possible, even on existing installations and during operation? A: A catalog of devices will usually be provided for installation of a host system. Some or all of these devices may be installed on the system. Host systems have their own applications for retrofitting devices. EDD setup procedures will thus have the same look and feel, which is highly beneficial. Even during operation, installation of device EDDs using the applications mentioned proceeded rapidly and without errors. Since the EDD syntax is translated, or interpreted, only by the host system, EDDs have no effect on the operating system involved. No restarts were necessary following their installation. There also were no interactions with Windows system files. Q: Can devices be simply, intuitively operated? A: The lab defined a series of different applications scenarios for various types of devices, ran the applications, and analyzed the results. Example scenarios included rapid operational procedures under which users had to set only the most-important parameters and conduct procedures typical for the devices involved. These procedures included the partial-stroke test for actuators and determinations of the echo profiles of fill-level radars. A series of language enhancements under IEC 61804-3 allow much more flexibly configuring user interfaces than was formerly possible. The first step involves setting the values of parameters, such as starting position and step length. A graphical display clearly informs users what each parameter means. The second step involves measuring the reference time and determining the limits beyond which violations of the reference time will trigger notifications about maintenance status. Users may then conduct a partial-stroke test, save the plot, and compare it to earlier measurements. This sort of representation guides users step by step through the procedures involved, without the need to consult other documentation. It is a good example of how to use EDDL to intuitively implement a complex operational procedure. Q: Is it feasible for interfaces and operational procedures to have a common look and feel? A: All host systems support a number of basic functions, such as reading, writing, printing, numerical comparisons, and data storage. The lab found in all cases users could call up certain functionalities, such as device status transmittals or processing parameter displays, from the same locations. Since those basic functions are not constituents of EDDs, they appear on the respective host systems in forms that have a common look and feel. However, device operational procedures or parameter terminologies, which are usually implemented in EDDs, differed from manufacturer to manufacturer in this test program. Text entries and tabular data previously dominated visual displays of EDDs. It is now possible to implement much more sophisticated interfaces, although they may differ widely from manufacturer to manufacturer. It is imperative to develop a guideline to implement EDDs for typical types of devices from all manufacturers, particularly during early implementation of the standard. That guideline should cover the terminology used to define parameter names and devote particular attention to how the parameters involved are formatted, including their offline/online representations and diagnostics. Q: Can all device functionalities be implemented using EDDL, or are additional tools necessary? A: Of course, the growing complexity of the current generation of processing devices imposes more stringent demands on user software. EDDL is frequently criticized for its failure to allow implementation of complex device operational procedures. However, the BIS testing showed all operational procedures relevant to the tested devices could be implemented without the need for additional software. These included the handling of interfering echoes in the case of fill-level radars, the calibration procedures for temperature gauges, and the startup of frequency converters.

Related Post: