We neglected to credit the author of last month’s tribute to Simon Ramo, who was Terry McMahon. We also misprinted the name of the author of our Factory Automation story. It is Mathieu Bélanger-Barrette. InTech regrets the errors.
FDT open standard
I have a question related to FDT [July/August 2016 InTech]. Are all vendor devices registered to FDT? A few years back, there were some vendors’ instruments or even vendors who were not registered (e.g., Emerson) or did not follow FDT.
If interoperability is the main essence, then how would one know looking at the field device? Is there an FDT-approved mark or identification on the field instrument? If FDT is open source, why are some vendors not registered?
The FDT standard is a truly open standard. All vendors and end users are free to adopt the standard without membership in the FDT Group and without any licensing fees to the FDT Group. As a result, many vendors make FDT-enabled devices, and the FDT Group may not even be aware of their use of the standard.
Regarding vendors or devices not registered, as noted above, there is no requirement for a vendor to be registered with the FDT Group in order to use the standard. However, several large FDT users specify that all device type managers (DTMs) used in their projects must be certified DTMs. Many vendors therefore find it advantageous to have their products tested and certified that they meet the requirements of the FDT Group. In this case, the vendor’s DTM undergoes a battery of tests prescribed by the FDT Group and carried out by an independent authorized test lab. Once the DTM passes all required tests, then the FDT Group issues a certificate of conformance to the vendor for that DTM. The certified DTM is then listed on the FDT Group web page in the “device catalog” section, which is searchable by vendor, device type, and other characteristics.
The FDT Group makes available an “FDT Group Certified” logo that may be applied to any DTM or device supported by a DTM that has passed the FDT Group certification requirements. The use of this mark is at the discretion of the vendor. An end user may also request a certificate of conformance from the DTM vendor or directly download a copy of it from the FDT Group website.
Glenn B. Schulz
Over the past three years, the heightened focus on alarm system management has resulted in my adding a considerable section to my advanced instrumentation and process control courses (three, four, or five days). The article “Getting the most from your safety alarms” [May/June 2016 InTech] is further content to be taken into account: the potential to lower risks through safety alarm usage.
The article points out that these safety alarms are normally dormant. As such, my belief is that there is a risk, just as in an emergency system vent (ESV), that when called to function, they don’t. OK, so in the case of ESVs, the boffins came up with partial stroke testing, which I think is a brilliant innovation.
I am asking if anyone thinks this principle can be applied to safety alarms in a similar fashion. OK, there will be refinements, in that software should possibly place the alarms in a “proof” mode, really only for a matter of milliseconds, then activate and confirm successful operation. Maybe there is a simpler alternative? This would need to be dynamic and not static, in that the process condition would need to be raised (or lowered), thus forcing the alarm threshold to be exceeded; this would hopefully initiate the alarm under scrutiny. Once proven, the system would store this for recordkeeping (as well as for legal and insurance purposes) and then possibly move to the next alarm.
Charles Palmer, PhD
We have an old Spanish saying, “A chain is as weak as its weakest link” (translated and very popular nowadays in English). The weakest link in the alarm process is the “processing” done by a human (see ANSI/ISA-18.2). Because of this, special considerations must be made when taking credit for alarms in process control applications (safety or otherwise). For example, spurious trips that would not affect a safety instrumented function (SIF) will definitely affect the performance of an alarm; the quantity and quality of “continuously training” operators would affect the performance of an alarm; and the configuration and rationalization of alarms in a human-machine interface would affect the performance of an alarm. Performance of sensors and FCE are orders of magnitude higher (the strong links in the chain).
I would advise you to take credit for alarms as a last resource. Maintaining performance of alarms is much more complex than maintaining an SIF, yet the max credit to be taken could hardly reach one order of magnitude in most cases. However, with an SIF you can claim several orders of magnitude. To use your words: The risk that a human would not act upon an alarm is orders of magnitude higher than the risk that a sensor or FCE would not function.
Luis M. F. Garcia G., CFSE