Over the last few months I have accepted at face value that a significant percentage (0.1 - 5%?) of embedded chips are date sensitive and that some percentage of these will be y2k deficient. But is this a fact or not? Please read the e-mail below and explain why this writer is incorrect.

Subj: Response to Percent Guesstimate of Embedded Chips with Date Function Date: 98-04-08 10:49:45 EDT From: pattsmith@hotmail.com To: rogaltman@AOL.COM

In order to have a date function which would be vulnerable to the Y2K problem, an embedded system must have constant power, either in the form of a battery or an electrical connection. Clocks take power, as anyone who has ever had to wind up an old grandfather clock knows. The same principle applies to embedded clock chips.

Your PC has a clock chip in it which is powered by a small battery. That's how it knows what time it is even after the power has been off. Once that battery goes dead, in a few years, your PC will no longer keep time properly when it is turned off. It may also lose some BIOS configuration settings like the kind of disk, if the battery also powers the memory chips which record this. Read your PC's owners manual and it will tell you how to change the battery.

The point is, any embedded device which could have a date vulnerability must be one for which you have to enter the time if the power gets disconnected (like your VCR), or one where there is a battery in it and the device will stop working after a few years (like your PC).

Now, consider an industrial controller device with an embedded chip. It's controlling a set of valves somewhere. For that device to have a Y2K vulnerability it must either have a battery in it (making it more expensive) meaning that the gadget will automatically stop working properly in a few years (a maintenance nightmare) or else it must require constant power and to have the date re-entered manually if the power goes out (another maintenance nightmare). In short, such a device would have huge disadvantages in any system where there wasn't an inherent need to know the date, like most industrial applications. Imagine a chip manufacturer trying to sell a device, saying "This is a great little device. Of course, you're going to have to go around and replace the batteries every few years or your plant goes haywire," or, "Of course, you've got to make sure the power NEVER goes out or else you have to go around and re-enter the date in each system." It's just not going to happen.

These estimates that 1% or 5% or whatever of embedded chips have potential Y2K vulnerabilities don't take these issues into consideration. Generally, any embedded device which could have a Y2K vulnerability has such special requirements that it will only be used in applications where it is pretty obvious that date issues exist. Toasters, most consumer devices, and most industrial control applications simply don't apply. The extra costs associated with making the kind of chip that can be sensitive to Y2K issues mean that such chips won't be used unless they absolutely need to be.

Pat

-- Anonymous, April 08, 1998

Answers

I generally agree with the above assessment. Comments follow:

>In order to have a date function which would be vulnerable to the Y2K problem, an embedded system must have
>     constant power, either in the form of a battery or an electrical connection. Clocks take power, as anyone who has
>     ever had to wind up an old grandfather clock knows. The same principle applies to embedded clock chips. 
>

In order to have any functionality, any microcontroller must have a power source of some sort. (BTW, I'm really beginning to hate the term 'embedded' W/R/T control loops and devices in those loops; henceforth I think I'll refer to them as SCE, or system control electronics.) An individual chip is not going to perform its coded function, regardless of that function, unless a power source is available. And let's carry this one step further - I don't believe that there are any SCE's that independently track time at the 'chip' level. Somewhere in the loop, there's a bios/cmos/rtc combination that's providing clock information to the SCE. Now, how the SCE uses this time information is something else entirely. But there are two basic elements necessary for any SCE operate: power, and (more likely than not) time from the bios/cmos/rtc chipset.

>Your PC has a clock chip in it which is powered by a small battery. That's how it knows what time it is even after the power
>has been off. Once that battery goes dead, in a few years, your PC will no longer keep time properly when it is turned off. It
>may also lose some BIOS configuration settings like the kind of disk, if the battery also powers the memory chips which record
>this. Read your PC's owners manual and it will tell you how to change the battery. 

Correct.

>The point is, any embedded device which could have a date vulnerability must be one for which you have to enter the time if the
>power gets disconnected (like your VCR), or one where there is a battery in it and the device will stop working after a few
>years (like your PC). 

I think this is a bit misleading. A hard coded date handling problem can still exist at the chip level, regardless of whether or not the bios/cmos/rtc combination is Y2k ready or not.

>Now, consider an industrial controller device with an embedded chip. It's controlling a set of valves somewhere. For that
>device to have a Y2K vulnerability it must either have a battery in it (making it more expensive) meaning that the gadget will
>automatically stop working properly in a few years (a maintenance nightmare) or else it must require constant power and to
>have the date re-entered manually if the power goes out (another maintenance nightmare). In short, such a device would have
>huge disadvantages in any system where there wasn't an inherent need to know the date, like most industrial applications.
>Imagine a chip manufacturer trying to sell a device, saying "This is a great little device. Of course, you're going to have to go
>around and replace the batteries every few years or your plant goes haywire," or, "Of course, you've got to make sure the
>power NEVER goes out or else you have to go around and re-enter the date in each system." It's just not going to happen. 

Again, this statement is misleading, because it doesn't account for hardcoded date handling at the chip level. (Agreed that it's not a pervasive problem.) But let's think about the power source issues for a moment - in a typcial PC, you have a power supply that provides power to all the components in your computer. Your onboard battery does not do this, it only keeps cmos and the rtc intact when the power is off. In a typcial control loop, you may have power supplied at the controller level, and then all kinds of devices powered downstream directly from the controller. Pull out a logic diagram and electrical schematic for a garden varitey Distributed Control System, and you'll see what I mean. (For those of you without access to such schematics/logic diagrams, there are several available on the net in sales type brochures; use the search term 'programmable logic controller' in Alta Vista, and scan some of the brochures.)

>Toasters, most consumer devices, and most
>industrial control applications simply don't apply. The extra costs associated with making the kind of chip that can be sensitive
>to Y2K issues mean that such chips won't be used unless they absolutely need to be. 

Agreed. Consumer devices are lousy examples.

-- Anonymous, April 08, 1998

Patt Smith wrote:

>> The point is, any embedded device which could have a date vulnerability must be one for which you have to enter the time if the
power gets disconnected (like your VCR), or one where there is a battery in it and the device will stop working after a few 
years (like your PC).  << 

Rick Cowles responded:

>> I think this is a bit misleading. A hard coded date handling problem can still exist at the chip level, regardless of whether or not the bios/cmos/rtc combination is Y2k ready or not. <<

It's not misleading at all if you assume Patt's point was that date-vulnerable systems can at least be identified based on the fact that there's a way to set the correct date and time. Many people have been saying there's no way to identify the systems that will potentially fail, and this is a contention I disagree with.

In addition, that fact that all date-sensitive systems must have a means of entering the correct date and time(*) means we have a fall-back. If the plant goes haywire on 1/1/2000, the first thing I'd do is set *everything* back to 1/1/1996. Why 1996? It's a leap year, and 1996 is most likely to be an "acceptable" date to most systems. Yes, the day of the week will be wrong. Setting everyting to 1/1/1972 would solve that little discrepancy, but there's a lot of systems that likely won't accept a date that early.

-Uwe-

* As I stated previously, there are two other reasons why a date-sensitive system must have a means of entering the correct time and date:

1) The manufacturer of the equipment utilizing the RTC module does not know what time-zone the thing will installed in, so he *has* to give the end-user a means of setting the correct time and date. 



2) Long-term drift. Over a typical life of 10 years, these things will drift. One part per million is still about 30 seconds in a year. Again, this necessitates giving the user a means of entering the correct time and date. 



-- Anonymous, April 09, 1998

Many others, myself included, have made the same very pragmatic observation. I learned however, that it only applies to systems which deliberately have a date dependency. It turns out that many embedded apps are impemented with off the shelf single board computers which can support dates, even if the actual embedded app doesn't use it. These systems are subject to Y2K problems at the BIOS and OS levels anyhow.

Sigh.

To make matters worse (or is it better) if they don't have continuous power or battery backup, who knows which year they might experience the Y2K problem. Perhaps every day in the 21st century might see one of more of these embedded chips finally reach 2000-01-01. Pass the asprin please.

-- Anonymous, April 10, 1998

I can think of at least two cases where a continuous power supply or manual intervention is NOT required to set the date/time. I have a JVC VCR at home. When the power goes off for any extended period of time, the VCR downloads the date/time from the air waves. To the best of my knowledge, this VCR does not have a battery. My TV operates the same way.

I also have a GPS. Although the GPS does have batteries to maintain waypoints that I have set, the date/time comes from the GPS satellites. There is no way to manually change this date/time.

Since this technology is available for home appliances, I would assume that the same technology can be used for embedded systems used in the manufacturing environment.

B.K.

-- Anonymous, April 29, 1998

Yes, a GPS or a TV/VCR can pull the date and time "out of thin air". But this is almost free in these devices because they already have an RF receiver and an antenna; your typical shop-floor embedded system or PLC does not have those. So while the technology exists, chances are very good it isn't used in the devices we care about here. Nobody would put an RF receiver and antenna in somthing just do it could pull down the time and date unless they had a really good reason.

-- Anonymous, May 03, 1998

Let me start by saying I have no information on whether there is or is not a significant Y2K problem in embedded chips. I would just like to point out that the above reasoning overlooks the fact that a system can have a Y2K problem even if it has no clock whatsoever. Y2K is about logic errors in processing dates, not about reading the current date/time. For example, suppose the embedded chip receives messages containing date/time stamps. In comparing the most recently received date/time to a previously stored stored one, it could get the wrong answer, leading to various kinds of incorrect behavior. As a general rule for testing for Y2K problems, it is not sufficient to set the clock ahead. You must also provide test data with post 2000 dates.

Hal

-- Anonymous, May 18, 1998