embedded chipsgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
What is the proplem with embedded chips/systems? What are they? Do they have clocks in them? How do they relate to the y2k problem?
-- johan (firstname.lastname@example.org), August 24, 1998
Good evening Johan,
Embedded systems generally are control systems based upon microprocessors and built into various types of equipment. The software instructions they execute are "burned in" permanently and for that reason they are frequently refered to as "firmware" instead of software. Many of these systems don't give a damn about the date and time, but a significant percentage do. Test results I've seen on the internet imply that approximately 3 embedded chips out of every 1000 (0.3%) have problems when the date rolls over to 2000.
These chips are built into all kinds of devices, including your VCR and automobile, medical equipment, traffic control systems, HVAC equipment, alarm and security systems, PBX phone systems, vibration sensors on power generators, gas valves, etc., etc., etc.
There are some unusual aspects of the Y2k problem with embedded systems which makes fixing them very tricky.
First off, you can't tell if a particular product has a problem unless you know for sure what type of chip is embedded into it. Furthermore, if you identify the chip in one device, that is no guarantee that the apparently identical device sitting next to it is using the same chip. Manufacturers frequently purchase chips from multiple vendors for the same function and one vendor's chips may fail to handle Y2k while another chip which does the same job handles it with no problems. To get around this, you need to test virtually every device which has an embedded chip - a very expensive and time consuming process.
Second is the number of chips that are out there. There are about 25 billion embedded systems in the world. 0.3% of that number equals 75 million. You have to test all 25 billion to find the 75 million with a problem (not really, but you have to test a huge percentage of them).
The third problem is that you usually cannot repair a bad chip, you have to replace it. This means you have to find Y2k compliant chips which can perform the same functions as the bad ones, in the same equipment, with the same power, heat and space requirements. A lot of older embedded chips are no longer manufactured and the only practical way to fix the problem is to replace the entire device it is embedded into. Also, there probably are not enough spare parts, or technicians, available to fix all the problems in time.
A fourth problem is accessibility. Many of the devices which use embedded systems are out of reach - for example, automated pressure sensors and valves installed at well heads in the oil wells of the North Sea. In other cases, the device with the embedded chip is accessible but cannot be taken out of service for testing and repair without causing tremendous problems.
If you would like a lot more information about this, visit the following wed site: http://www.tmn.com/~frautsch/y2k2.html
or you can try: http://www.iee.org.uk/2000risk/
-- Ed Perrault (EdPerrault@Compuserve.com), August 24, 1998.
If you are going to view Frautschi's report, you should also read the rebuttal, as well. Some of it is well worth the bandwidth.
-- K Golden (email@example.com), August 24, 1998.
I just read the rebuttal mentioned above and I'd like to clarify one of the statements I made in my earlier response.
A large part of the embedded "system" problem is finding the systems which have the problem. There are a huge number of devices with embedded systems (the rebuttal author keeps mentioning 40 billion, which is more than I had seen elsewhere). Finding the 25 million or so with a problem (if you accept his lower number) is a tremendous task. Fixing them when you find them is still subject to the additional problems I mention above, particularly lack of parts.
The good thing about embedded system problems is that they are unlikely to propagate - your VCR will not pass corrupt data to you microwave. The bad thing is that they don't have to propagate - 25 million problems is plenty all by itself.
-- Ed Perrault (EdPerrault@Compuserve.com), August 25, 1998.