Clocks on embedded systems : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I have a question on embedded systems for the more technical savvy of the group.

In PC's, I believe the BIOS date is fixed during boot by addressing the CMOS file and RTC. So when we do roll-over tests we get a pretty good Idea if the computer is date compliant. (hardware not software compliant)

In the real production world of massive control and process systems a computer may control the front end of a process, but what level of influence does this have on embedded systems under the computers control downstream. In other words, if a team tests the y2k compliance of a process by rolling the date on the main computer, what level of confidence do we have the PLC's and other embedded chips that might be date sensitive actually see a date roll-over. Most PLC's have battery back-ups so turning off a process will not "reset" the date on these devices. Even if the main computer can direct the instruction set via feed-back to the last component in the stream there must be some individual date functionality in the local PLC's or we would never have had to give these devices RTC's to begin with

Almost all the "end to end testing" I've heard about involves the above scenario. If date sensitive embedded chips remain "time independent" during a forced roll-over we end up accomplishing little as far as knowing how they will react during a natural date change.

Is my thinking flawed or am I just wrong on the basics.


-- richard shockwave (, December 21, 1999


The specific problem that I've seen raised is that many PLC's, even those ones that deal with calendar dates (and which can be deliberately set from a SCADA or whatnot) also have ANOTHER clock that just sits there and happily ticks away regardless of what the date clock is showing.

Why would they have this? Well, what about a rate of flow device? It needs a concept of time to be able to work out flow over time. But it's not DATE based, so might get missed in a compliance check.

When the "hidden" clock rolls over, you get a one-off negative time value (more likely a large unsigned value) and some wacky behaviour. What does "wacky" mean? Well, that's the problem, it's undefined.

There's a big flaw in that argument in that this won't necessarily (or even probably) happen on rollover, it'll happen when the timer wraps round, and depending on the storage size, units, whether it's battery backed, and what it was initially or last set to, this should be happening at distributed and possible frequent occasions anyway.

The reason why I am still a little concerned is that when I worked with PLC's, I quickly realised that the "veterans" that I was working with (on the SCADA side) had no idea at all what went on inside them.

So how can they test them?

-- Servant (, December 21, 1999.

Moderation questions? read the FAQ