HART and the millennium -------------------------------------------------------------------------------- Is the HART protocol millennium-proof? What should I do? -------------------------------------------------------------------------------- Introduction It is now quite widely understood that many computer systems and software will be upset by the arrival of the 21st century in just over a year. The problem arises from the common habit of using only two digits to represent the year, assuming "19" for the hundreds digits. Obviously, this assumption will be wrong from 1 January 2000; indeed it may well be wrong before that, for applications which look ahead into the future. The two-digit representation may be used internally to store dates in memory or disk files, or it may simply arise in the format used to display and enter dates. In either case, a human user might well be able to resolve the ambiguity, but a computer program probably wonot, at least not without some new rules to guide it. There are two straightforward ways to fix these problems. You can re-write affected parts of a program to use 4-digit years, or you can add a new rule to interpret two-digit years using a "pivot year" (for example: any number xx above 50 is "19xx", while 50 or lower is "20xx"). The second method only postpones the problem, but that may be acceptable, depending on the expected life of the product. Using a variable pivot year, depending on the actual date, may also help. Of course, the hard part is to find and understand the operation of the program code, especially in older or poorly-documented software. For a fuller discussion of the millennium problem (otherwise known as "Year 2000" or "Y2k") look at the DTI information page at http://www.bsi.org.uk/disc/year2000.html, the "Year 2000 Information Center" website at http://www.year2000.com, or the ISA"s Year 2000 pages at http://www.isa.org/journals/intech/mcweb/year2k.html. On the whole, industrial process measurement and control systems are less likely to be seriously affected than business systems, which may depend heavily on the use of dates. However, we cannot afford to ignore the problem. -------------------------------------------------------------------------------- Is the HART protocol millennium-proof? So, what about the HART protocol? Is HART itself "millennium-proof"? The short answer is YES, HART IS OK. But read on ... HART does define a format for dates, which is used in Universal HART commands #13 and #18. Every HART device must store a date, in order to implement these commmands. The protocol specification doesnot say what this date should be used for, only that it must exist. Typical uses are to record the date of the last instrument calibration, or the date of the next one; this is entirely at the whim of the host application programmer. The HART date format consists of a set of three 8-bit numbers (that is, numbers which could be anything from 0 up to 255) representing day-of-the month (1 to 31), month (1 to 12), and "year minus 1900" (0 to 255). Happily, because the year byte represents "year minus 1900", this scheme will work unambiguously until 31 December 2155. Dates represented in this way are not affected by the "millennium problem". (Personally, I am not too worried about what happens in 2156. Maybe HART will not still be in use by then. At least, I donot expect to be around to worry about it!) However, just because HART is ok as a communication protocol, doesnot necessarily mean that products using HART are ok. It is true that most of today"s field instruments have no concept of date and time, so will not be affected. But a few instruments, and a good proportion of host application software, could be affected - particularly those which include datalogging or configuration management functions. Instruments may include dates stored in proprietary formats. Use of the HART date format is not mandato