TECHNICAL 'Intro to Embedded Chip Problem Detection'
What is going on at a typical customer doing factory floor Y2K remediation. Interesting reading!
John
___________________________-
To: year2000-discuss@year2000.com
From: "Y2K Maillist (Via: Amy)" <amy@year2000.com>
Subject: Embedded Systems: "Intro to Embedded Chip Problem Detection"
Date: Wed, 25 Feb 1998 21:16:32 -0600
To: year2000-discuss@year2000.com
From: Charles Reuben <buytexas@swbell.net>
Subject: Embedded Systems: "Intro to Embedded Chip Problem Detection"
To ALL:
I have been reading a lot of comments on the "embedded chip
problem". I have concluded there is a great deal of confusion about the problem. This is understandable because in order to thoroughly understand the problem and be able to solve problems one really should be both an Electronics Engineer and a Sr.Y2k Programmer.
The following might help.
This correspondence was cc:(copied) to me way back in Oct. 1996. I kept it because it truly clarifies the nature of several issues re:
Embedded Chips and the "due dilligence" one must perform inspecting the devices for Y2k problems. Essentially, it is from a Working Y2k contractor to an IT Director seeking some background on the problem. NOTE: this is not "Holy Writ" and a lot of it is "empirical" (seat of the pants).
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
The following comment from the end of the response is MOST IMPORTANT:
".....I'll close with the observation that so far, it appears that
process _control_ devices are usually not at risk to Y2K problems other than those that hatch in the central control computer. However, _instrumentation_and_monitoring
devices seem to be loaded with TOD clock functions. These are likely to misbehave and I'm paying extra-close attention to them."
mmmmmmmmmmmmmmmmmm end SNIP mmmmmmmmmmmmmmmmmmmm
This observation is coming true as workers in HEALTH CARE and all "instrumentation uses" are finding out.
NOTE: while the emails cover "process control", it goes without
saying that ANY piece of machinery or instrumentation in use in YOUR ENTERPRISE ..can be explored (and should be) in much the same way.
Small and mid sized companies (SMEs) without an EE or an Engineer on staff could do the first steps of at least opening the 'boxes' up and looking at the boards. If you find something that looks like it "could" be programmed, a quick call to a good "Franchised Distributor" or even a JDR type mail order company can tell you whether or not certain chips might be "suspects". Byte and other real techie mags.(CMP etc) run ads for stocking distributers and the device functions usually appear in their pricing chart. All major mfgrs. of chips give away tons of info on their products and I suspect they will respond to email readily. Don't forget the INTEL WEB SITE; a major resource of checking.
HINT: if you learn the device is : programmable
ROM,(PROM,EPROM,EEPROM,FlashROM), the box it is used in...is a Y2k suspect.
It is not brain surgery but it is work. Most chips can be read
easily. There are usually two sets of numbers on them and the logo. Most of the logos are well known:
F--> Fairchild, I Intel, twin lightning marks: Nat.Semi. THE STATE OF
TEXAS: T.I. ETC. There are old Mostek devices out there and they are now: SGS Thompson.
The two sets of numbers are easy to understand. One is the ID of the chip FUNCTION itself: p74ls04 or D8086. The other set will often contain the week of the year and the year the chip was encased(not made) : 0688 (6th week 1988). In the 1980s,most manufacturers would not take delivery of chips older than one year and this was the method of checking. So if it looks like a date...it is. The other is the ID. To this day, date of encapsulation is critical in dRAMS because of the improvements in the "process". Users always wanted the "latest versions" of RAM as the makers went down the Learning Curves.
NOTE ESPECIALLY: the Contractor's method of CYA: taping phone calls to vendors to have a record that he had in fact performed the research into "Vendor Compliance".
I trust it will help some who are just "exploring" this mine field
in Y2k. I would only extend one comment here on the "semiconductors" involved. Not only are the XX86 CPUs suspect but many others in the Intel line were also used 80186,D8048,D8049 and D8051. For those who don't recognize the term "TTL" ....those are the more common Logic chips starting with the gates like 74ls02,74ls04 and moving through the old T.I./Nat.Semi.
Logic lines. One would like to say that "If it had a glass window in the middle of the chip, that was an immediate tip off". However, a lot of the other programmable devices did not have those windows. I would think that most EEs would agree with the comments that all TTL boards probably were not a problem. But be careful. I once saw a device that had a big PC board and a small modular one with an Eprom on it hidden in what looked like a little case with a cable sticking out. Turned out that the designer though it would be neat to "Swap out the brains" every now and then simply by yanking the small board and pushing a new one right in. (Just like upgrading from 4 meg sims to 16 or 32 megs in your PC). That was a long
time ago, and I would bet anything the puppy is not Y2k OK.
CHARLIE REUBEN
DALLAS,Texas
mmmmmmmmmmmmmmm
Sent: Monday, October 28, 1996 11:10 AM
Subject: Y2K Problems in Process Control Systems
Importance: High
XXXXX,
I am somewhat curious on what you have come up with on the Y2K issues concerning the external infrastructures (including Process Control Systems). Would you know which devices are compliant which are not? Would you have any leads on who has done testing on some of the equipment.
Thanks.
YYYYYY
mmmmmmmmmmmmmmmmmmm
To: YYYYYY,
>From : XXXXXX
In response to your question, so far my experience has been pretty crude. But I hope it is nonetheless effective.
First, I have my client's technical and maintenance staff physically inspect each device to see if it is even electronic. Many are either hydraulic or pneumatic, even on nearly-new industrial equipment. Clearly, these units are no problem. But, don't forget that they may be operated by a central control computer. I've read on Peter's Y2K forum that DEC PDP-8 CPUS _are_not_ capable of being made compliant (!) and unfortunately, many industrial plants are run by PDP-8 CPU's. (I haven't yet had time to check out the PDP-8
situation personally.)
mmmmmmmmmmmmmmmmmmmmmm NOTE BENE'mmmmmmmmmmmmmmmmmmmm
Second, if the device is electronic, I have the technician pop the cover to see if it is all TTL or whether it contains CMOS, PROMs or xx86 CPU's. If it is all TTL, I'm comfortable saying that it's probably OK. Otherwise, it gets put on the "questionable" list.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
The next step (tedious, dull and unfunny) is to contact vendors with specific model and serial numbers for each "questionable" device. I'm in this phase of the process right now. I'm not asking whether the devices are "Y2K Compliant" because that's too scary a way to put it -- the legal department's hair starts to bristle as soon as anyone mentions "Year 2000", I've discovered. What I do ask is whether the device internally keeps track of dates and times in any way -- and if so, exactly how is it done.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
So far, I've received no written response. However, I _have_ enjoyed a number of very helpful telephone conversations with sales engineers and technical support people. Because I'm paranoid, I tape record these calls and transcribe them (1) to make sure I get the facts straight and (2) to provide evidence in the event of future litigation about whether I did my job.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
As you can guess, the information I receive is all over the map about how various devices work internally. Some "questionable" devices track TOD but don't use it. (They're probably going to misbehave, I suspect.) Most process control devices do not track time in any way, fortunately. Those that do track time seem to use it only for short-term averaging or in stability-control loops. Frankly, these may misbehave at the ultimate midnight, but I'm not
sure yet.
I'll add that in most of these conversations, the people that have called to answer my questions have been _very_ interested in why I was asking and the implications of my questions. Everyone, without exception, has been most cooperative and helpful. I have the feeling that in a couple of instances, my questions may have triggered an internal meeting or two to raise the awareness
about Y2K issues regarding product performance and related (liability) issues. But, I really have no way of knowing whether this is actually the case, of course.
The last step (which I have not yet undertaken) is to take the equipment off-line or, if possible, remove the controller from the device. Then we plan to set the clock to just before ultimate midnight and watch its behavior.
I'll close with the observation that so far, it appears that process _control_ devices are usually not at risk to Y2K problems other than those that hatch in the central control computer. However, _instrumentation_and_monitoring devices seem to be loaded with TOD clock functions. These are likely to misbehave and I'm paying extra-close attention to them.
In terms of who might have already done some testing, or who might offer testing services, I'm afraid that I've nothing to offer. My clients are all planning to do all of the testing themselves -- at least so far.
I hope I've been of help! {:-)
--- mmmmmmmmmmmmmmmmmmmmmmm
CPR
Charlie Reuben,
--------------------------------
Charles P. Reuben,B.Sc.,M.A.,
Hancock Prop./Kamco,Inc.
DALLAS (the Lowest Cost World Class City) |
