Backwards compatibility is necessary to preserve our substantial installed base of everything from field devices through I/O cards, controllers, HMI and data historians. Of course, doing so is not trivial, and as many suppliers can attest, it’s a significant challenge, especially as we increasingly use COTS networking technology (Ethernet, IEEE 802 radios, etc.) as well as operating systems such as Windows, LINUX and others.
Though often overlooked, backwards compatibility also extends to the end user, particularly all the intellectual property they have in their controls, applications, etc., which may have been originally written in some version of Fortran and now must link to function block-based control, with C, C# and other languages in between and still in use. The challenge of finding people who continue to know and support the legacy languages will not become smaller.
A corollary question is, how far back must we be backwards compatible? The answer is, it depends on where you are in the above hierarchy. Field devices are expected to have a lifespan on the order of decades, while HMIs are normally three to five years. Does backwards compatibility go for one or two generations, or all the way back to revision 1? Good luck with that option, especially as chipsets and the associated tweaks to make them work in real time are unlikely to translate to newer multithread processors.
How about considering forwards compatibility from the outset? Some of the newer open systems or international standards-based options could make that possible, except they are not necessarily backwards compatible. That’s OK for a greenfield facility, but then again, just how good is your crystal ball at picking the winner?
Ignoring the compatibility challenges with the higher end of the control system—the controllers and above—because we can use gateways or, as at least one DCS supplier is doing, virtual machines to emulate those environments, the biggest impact is often felt at the field level with field-level protocols and firmware versions of field devices. (ISA 108, Intelligent Device Management, was developed in part to help manage the field device difficulties so when I change one device for another, everything still works like it did before.) The increasing use of digital communications tools such as fieldbuses, wireless and HART to provide increased safety and ease of use, can make device level replacement more complicated as well—just not where you can easily see it.
Though it is getting better, if there are different firmware revisions in the manufacturer’s chipset or the communications protocol, it will probably affect the ability to communicate with the equipment for maintenance and calibration. Worse than not communicating is doing so, but putting data where you don’t expect it, because then you think everything is all right until it’s not, often at the worst time.
Because the core information associated with the process variable, device name, addressing etc. is near the top of the memory stack and transducer information, where calibration and maintenance data is stored, tends to be further down, if there are any changes between device firmware revisions, it’s highly probable that things will not be in the same place. Don’t forget the revisions/new firmware files need to be installed at both ends of the wire, which means your calibration tool as well as the field.
[javascriptSnippet]
Lastly, even though you can access the calibration information (range and span) over the network to verify the field device is correct, you still need to provide an input with some form of external device, especially if a safety installation, which means getting to the process taps. (Reminder to all of you to work with your piping team to make sure you can still reach an instrument either via a catwalk or manlift because scaffolding gets expensive in a hurry.)
We may not realize that by using technology today, we may be causing future challenges, however, as we see, the decisions (sins) of today can have significant impact for many years and generations of control professionals. Meanwhile and just in case, while over the wire/digital communications calibration is fine, I still keep a screwdriver in my coveralls as a back-up. If nothing else, I can use the magnet end to check if the pipe or material is stainless steel.
About the author: Ian Verhappen
