This is my first look at this forum, and my first post ever to a Y2k subject matter bulletin board. The questions and answers on this site appear to me to be thoughtful, logical, and backed by quoted factual data. Hence, my eagerness to receive some answers that have eluded me for over a year in following the approach to the millenium. Though my career is not in high tech, science, or computers, I believe I understand how computers work, and the implications of embedded chip failure. Go easy on me though, as my lexicon of computer buzzwords is limited. OK Here goes:

Embedded chips are everywhere. No human can possibly know the number of them in existence, nor their explicit function on the planet right now. If I were to hazard a guess, I suspect there may even be millions (at least) of 8086 microporcessor chips still out there today performing slave labor functions. How many 80286 chips are still out there, and how many 80386 chips as well?

Railroad switchyards are dependent upon embedded chips, probably the locomotive engines as well. Hydro-electric dams probably have thousands of pressure sensitive valves, and current sensitive switches. Automobile ignition and timing systems have been dependent upon microprocessors I think since the late 1970's. Obviously traffic control systems, all the way down to the simplest traffic light in the smallest hamlet in the United States, probably use embedded chips to function as well. The delicate balance of cooling a fusion reaction and putting out electrical power is contolled by countless liquid valves, pressure monitors, etc. The falure of embedded microprocessors here would probably cause a fail safe shut down of the core reactor, assuming of course the boron control rods are not monitored by more of these "ancient" embedded chips. So here are my questions:

When 8086, 286, and 386 chips were manufactured were they commonly programmed with a "clock" function. To phrase this more simply, are all the old chips ticking?

Next, if these old chips commonly contain a clock, or timekeeping function, was that function "abbreviated" to the last 2 digits of the year ON THE CHIP (emphasis supplied)?

Third, are these old 8086, 286, and 386 chips functioning out there in embedded fashion, i.e. as monitors, or slaves to valves, switches and the like?

Fourth, (and this is the big one) if embedded chips do all contain a clock function, and are operating in the manner I have described above, then is it possible these old chips will fail even if the clock they contain is not necessary to the embedded function they are performing?

I have queried computer industry consultants on this logic in the past, but each answer is different and appears to be based on guess and opinion. What about it, is my logic plausible? Or am I operating from the planet Pluto? I hope I have piqued some interest. I eagerly await reply.

Ben Simbole

-- Anonymous, October 21, 1999

Answers

Ben,

Welcome to the forum. Very nice post for a first time. But, you sure did pick a hot issue. What you are going to find is that nobody can really give you a good, final, answer for this. Some will rise up and try, but no matter what is said on one side, the other side will disagree. Basically, based on some good research and essays I have seen, there is certainly a possibility of clocks, sometimes "hidden" clocks, to be lurking in chips that are not even being used for time/date keeping. This defaults back to legacy coding that was built into some chips and is no longer needed, but the chips are so cheap they are used. And they were bought on the legitimate market, the gray market, and the black market. (God bless a free market system) Apparently, after the smoke clears, there probably won't be any large percentage of chips that will fail on, or about, the rollover date. Some will fail ahead, and have, and some will fail after the rollover, and it could be *years* after the rollover if their clock is now set to some date prior to current date. So, they won't be a big problem, percentage wise, but if the one that is missed, fails in some critical application, it could lead to catastrophic results. Keep your fingers crossed, because most of these chips have become so difficult to round up, and expensive to test, that Fix On Failure is now a common tactic for many users. Only time will tell how big or bad the Failure will turn out to be.

What it has come down to is like looking for faulty rivets in the Golden Gate bridge, or in every bridge or critical machine in use today. Suppose we have been warned that some bad rivets made their way into the supply chain, but no one knows where they went and they all look alike at first glance. Given enough time, and manpower, every rivet everywhere could be checked, but there isn't time enough left now for that. And there isn't a great desire to spend that kind of money on top of all the other hardware and software expenses so far. Some bad rivets have been found and replaced. Most have not been tested so far. What will happen when the ground shakes and the wind blows? Take a guess, like everyone else. The range is: no big deal, to catastrophic, with everything in between. When you are down to Fix On Failure, you get to choose whatever scenario makes you personally comfortable. OK?

-- Anonymous, October 21, 1999

Re: chips with clocks in non-date-dependent devices: According to the president of the Arizona Farm Bureau, who is himself a farmer, his own irrigation system had a Y2K failure when he had it tested for Y2k compliance. Although his irrigation system did not use a calendar function, the chip inside did, and the test broke the device. Unfortunately, it took him three months and a new control panel to fix it.

-- Anonymous, October 21, 1999

Ann makes some very good points here. There has been a general statement made that if there is no way to set a clock in the system, or if the system is not using a clock in any obvious way, then there is no Y2k clock problem with that system. This is just not true in every case, and there will be a few systems here and there that have been kept under continuous power or have a backup power device built in, such as a battery or capacitor, that can create a date problem. Very small risk, sure, but it's there nevertheless.

Being able to replace a complex embedded system device can take many months. These are often not an "off the shelf" item that you can buy at a parts supply, or even from the manufacturer. Sometimes they have to be re-engineered and manufactured just for you, with lead times of 3-6-12 months or more. During that time the device you need it for will not be functioning, unless you have a manual backup, which has also become more and more rare. It's a real bucket of worms, as the saying goes.

-- Anonymous, October 21, 1999

Living in the Central Midwest, my chief immediate concern (the catalyst/starting point to all my broader preparations) is warmth in winter. Anyone care to hazard any guesses regarding likelihood of utility failures directly caused by date-sensitive embedded chips in the industry? Initially, when I began looking at y2k last December, I thought this was a critical issue; now, it seems to be fiddling second play (or less) to other concerns...

-- Anonymous, October 21, 1999

Jim,

I think you are right, that embeddeds are not the primary danger in the Y2k mine field. It is more like another straw on the camel's back. It could end up being the final straw, but who knows? There *will* be some embedded chip failures. Some will create a nuisance and some will be a major headache, due to their complex nature and the fact that they were custom built, thus will take a long time to replace if they are not already in stock. And the ones in stock could also be just as faulty as the one in use that failed. You know, spare parts can be the killer of any complex system. The US military routinely has countless vehicles, including aircraft, sitting idle or dead due to just waiting for parts to get them going again. This situation certainly will not improve during the year 2000.

-- Anonymous, October 22, 1999

Thanks, Gordon, for your reply to my first post on this board! -Jim Young

-- Anonymous, October 23, 1999

Ben,

In your original post, you commented, "Hydro-electric dams probably have thousands of pressure sensitive valves, and current sensitive switches."

Maybe I can ease your mind on this issue at least partially. The Hydro power stations that I control have no pressure sensitive valves at all. There are some hydro electric stations that do have pressure sensitive valves (usually high head stations, or stations with very long penstocks), but it would be extremely unlikely for any of these to have any electronic components, and so would be entirely immune to any Y2K issues.

There are plenty of "current sensitive switches" called relays which are generally used for protection purposes. These are usually electro-mechanical devices which also are immune to Y2K, but in more recent times we have seen electronic relays being used. Fortunately, the electronic relays generally do not use any date/time functions in their operation, but do use them for time tagging their operations. In the event that such a relay should fail, it is most likely that it would simply dis-able that particular protection system, and would not cause the plant to trip. If that happened it would be up to the operator on duty to decide if there was sufficient back-up protection in service to enable normal operations to continue, or if it would be safer to shut the plant down. At all power stations that I have worked on, when electronic protection systems have been installed, they have always been backed up by electro-mechanical devices, so if any did fail it would not be neccessary to shut down the plant.

The biggest issue facing hydro electro power stations is the failure of their SCADA systems, and ensuring that there is sufficient trained staff to operate manually if required.

Malcolm.

-- Anonymous, October 23, 1999

Malcolm,

When I saw that item about Hydro plants I wondered if it would draw you in. As our resident expert on Hydro plants you are priceless. Once again, I compliment you on spotlighting the problem, as you see it, from what is happening and has been happening in that particular part of the electric utility arena. Also, I note that you once again have mentioned that the ability to run on manual will be paramount if the SCADA system dies. If we are talking about a few weeks on manual, well then I have confidence about that. At some point though, if it goes into months of manual running, the basics change. There will have to be compromises and cooperation on distribution and usage, I think.

-- Anonymous, October 23, 1999

Ben,

You aren't going to get a better or more experienced take then Mr. Taylors. The problem to my eyes is there are just too many possible scenarios and not enough data points. Bennet's senate committee this past week highlighted the unpreparedness of the small to medium sized chemical industry. You could have the best prepared utility around and it doesn't do any good if you or they need to evacuate for a chemical spill. For some excellent reads on the topic I would also recommend "Millennium Problem in Embedded Systems - from the Institution of Electrical Engineers" http://www.iee.org.uk/2000risk/ and anything written by Mark Fratuchi (maybe someone can jump in and help me out with that spelling I can't find his links at the moment)

-- Anonymous, October 23, 1999

Paul, Ben,

Well, without Bonnie and her eagle eye and extensive research files, we just have to muddle through as best we can. You are referring Dr. Mark Frautschi, and his essays can be found at the web site of Dr. Douglass Carmichael. (www.tmn.com/y2k) It was Frautschi that woke me up to this matter about 18 months ago, and I highly recommend you start there. Personally, I also like the Bruce Beach theory about "hidden clocks" as well, but if you are only going to delve just a little bit into this, read what Dr. Frautschi has to say.

-- Anonymous, October 23, 1999

Ben,

I don't have time just now for a long answer in prose, but I can give you a few facts to think about. Also, use the search feature to search for my other answers regarding x86 chips and embedded systems. (search for "ajedgar")

Other people have stated what a mixed up grey area this is, and yet there are certain things we can state for a fact that help put parameters on the whole embedded systems issue.

You wrote: >If I were to hazard a guess, I suspect there may even be millions (at >least) of 8086 microporcessor chips still out there today performing >slave labor functions. How many 80286 chips are still out there, and >how many 80386 chips as well?

Correct. There are millions of these chips out there. In 1980 there were over 700,000 computers of all kinds sold worldwide (mainframes, minicomputers, microcomputers, and home PCs). That number does not include embedded controllers. In 1982 Intel announced the 80286, and in 1984 IBM introduced the IBM PC/AT with a 6Mhz 80286 processor. Also in 1984 Compaq shipped 149,000 PCs worlwide. In April 1985 Compaq introduced the Deskpro 286 and the Portable 286. April 1986 the IBM AT 8Mhz is introduced. Even though 80386 based PCs had been introduced in 1986, 80286 based PCs were still being sold well into the early 1990's. IBM introduced the 10Mhz 80286 based PS/1 in December 1990. In April 1986 Compaq shipped its 500,000th PC. They had been in business for four years. By November 1987 they had shipped their 1 millionth PC. In 1987 there were roughly 10 million PCs shipped worldwide. Roughly the same number of embedded systems were shipped using an x86 CPU as the core processor. One of the most popular embedded chips still used today is actually the 80186. Today more than 5 billion embedded MCUs and MPUs ship each and every year. 1 billion 4-bit MCUs, 2 billion 8-bit MCUs, 1 billion 16-bit MCUs, 800 million 32-bit MCUs/MPUs, and 200 million 64-bit MPUs.

Fortunately only a small percentage of them use time/date functions and only a small percentage of those will have Y2K problems. However, 0.01% of 5 billion is still 500,000.

>When 8086, 286, and 386 chips were manufactured were they commonly >programmed with a "clock" function?

No. No CPUs have built-in realtime clocks (ie. time-of-day, day/date clocks). The date functions is always provided by a seperate chip called an RTC chip click here for a list of such chips.

>To phrase this more simply, are all the old chips ticking?

Yes. But only in systems with an integrated RTC. The original IBM PC (4.77Mhz 8088) did not have an integrated RTC. Everytime the PC was powered up or rebooted it prompted you for the date and time. With the introduction of the IBM PC AT in 1984 an RTC was included. This RTC only stored the last two digits of the year. All variations of this chip from all vendors without exception only stored the last two digits rigth up until 1994. Around this time one manufacturer, Dallas Semiconductor introduced a true 4-digit year RTC.

>Next, if these old chips commonly contain a clock, or timekeeping >function, was that function "abbreviated" to the last 2 digits of the >year ON THE CHIP (emphasis supplied)?

Yes. As per the above.

>Third, are these old 8086, 286, and 386 chips functioning out there >in embedded fashion, i.e. as monitors, or slaves to valves, switches >and the like?

Yes. But mainly in higher level functions not in controlling individual valves and/or relays. You may have a couple of PLCs which are monitoring and/or controlling valves, relays, and sensors which are then monitored and controlled by a simple PC based cell-controller.

>Fourth, (and this is the big one) if embedded chips do all contain a >clock function, and are operating in the manner I have described >above, then is it possible these old chips will fail even if the >clock they contain is not necessary to the embedded function they are >performing?

No and Yes. No, the CPU chip does not contain an RTC clock function. Yes, it is possible for the embedded controller (containing CPU, RTC, memory, I/O logic) to fail even if the RTC is not necessary to the programmed task. It's possible but not very probable, and I provide an example of such in one of my previous threads. It is much more likely that embedded systems will fail because they contain an RTC and use it, and also use the secondary software clock, and the system was simply not remediated, or remediated incorrectly, or the customer accepted the letter of compliance without doing unit testing, let alone end-to-end, integrated testing.

>I have queried computer industry consultants on this logic in the >past, but each answer is different and appears to be based on guess >and opinion. What about it, is my logic plausible? Or am I operating >from the planet Pluto? I hope I have piqued some interest. I eagerly >await reply.

Your logic is not only plausible but quite accurate. You're operating with your feet firmly planted on Terra. This has been exactly my interest since I first tested a PC based embedded system in 1995 and found that it would fail, even though it was running a realtime Unix variant with an internal clock representation that would work fine until the year 2038. There are going to many, many embedded systems failures that are due to Y2K problems in embedded Unix systems running on PC hardware.

Please feel free to ask further questions or for more clarification.

Regards,

-- Anonymous, October 26, 1999

Thank you everyone for your replies to my first (and only) post on an internet bulletin board. I ahve sent along spelcial thanks to ajedgar, who was the last reply, but I repost my comments to him on this board:

It has been over a month since I visited the euy2kelectric bulletin board, I returned to "refresh" my memory on the responses provided to my initial "embedded chip inquiry".

I said then, and I repeat, that I am not knowledgeable in this area, but that I only have developed my own string of logic to which I sought confirmation.

I am dleighted that I was able to communicate my thoughts clearly enough to provoke answers. I am most grateful to the time you took to post your answer to my question. Though I am not familiar with all of the jargon, your answer is clear, and backed by factual data.

I think I am ready at home, and I hope that a 1-2% "failure" equates to only minor public inconvenience; but since we really don't know the magnitude of a 1-2% failure I shall do my best to be ready for the worst.

-- Anonymous, December 09, 1999