Illustrative. Y2K stimulates other problem.
In this case, the only 'problem' is that the central monitor station calmly sorts an 'emergency' message based on it's age! What happens when there are LOTS of normal monitor messages arriving e.g. today? The message still rolls off the monitor screen, yes? How 'immediately' would be determined by irrelevant factors, but it could be relatively immediate. With all the exposure to the elements, how close will the clocks be to each other? After 1 year, 4 years, 8 years? A present day 'emergency' message from a slow clock could easily find itself at the end of any monitor screen.
Getting anyone to fix the central system monitor code is deemed to be beyond all hope, but I would guess that whoever runs that system also will get around to fixing it's 'Y2K problem' (probably by switching to 4 digit years!) rather than fixing several inherent flaws.
I presume, of course, that the year was (before fix) sent as a 4 digit number, otherwise the dread central system monitor code will have a really tough time coping. Of course, if a 4 digit code was being sent all along, this would mean that the RTC didn't really need changing, but the 8051 code did (to make up a correct 4 digit code from the 2 digit RTC year number. (I would suspect that the RTC was changed to renew battery while all else was going on.)
What would be the minimal fix? Probably to just change the system central monitor sort function to first sort messages by priority of content then by time, doing the 2 digit years correctly. Beyond that, a time calibration for each system needs to be kept someplace, maybe at site, maybe at central system, else the time has little meaning.
None of this really has anything to do with Y2K, except that Y2K caused a retrospective design review, always a good thing. But if this snip is the whole story, it (the fix) didn't go far enough. |
