SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : REFERENCE

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: C.K. Houston who wrote (193)11/24/1997 7:07:00 PM
From: C.K. Houston   of 411
 
Society for Information Management Year 2000 Working Group COPY FOLLOWS
year2000.unt.edu Free, immediate registration
SELECT: Embedded Systems - Automated Process Control Systems
================================================================
33. Author: Geoffrey Jahnke Nov. 20 3:37 PM 1997
I am not going to elaborate on a recall that, as I stated when I first posted, is an unconfirmed rumor. When I have confirmation of that, I will give you more details.

As for my experiences with shop floor equipment: Embedded systems are a REAL problem. I try to share with the group the different phenomena of failures I find, not every failure. In order to demonstrate an EXACT PROVEN failure (i.e., failure mode, reproducibility, etcÝ) more than just the model number of a piece is required.

In DOCUMENTED CASES (1), two IDENTICAL machines in the same identical process have different DOCCUMENTED Y2K test results. Upon further investigation, one machine was one firmware revision ahead of the other. The same has been found true with microprocessor substitution.

Therefore, in order for me to give you documented proof of a failure, I must include firmware version and microprocessor model number as well as the BIOS revision and standard make/model. I don't exactly have the firmware version handy of the PLC-5 which failed in conjunction with its HMI. The point of the example is that a compliant PLC can fail in conjunction with its user control interface.

This problem has not been addressed in most major shop floor embedded systems audits. The point of this is not that in one case a specific PLC fails with a specific HMI, the point is that an HMI could trip a PLC. If you in turn take this information and check every specific AB PLC-5/20E with a Control View HMI, you could be missing that same exact problem (hypothetically) with a PLC-3/10 and an ABB HMI.

In addition to this, there is not the space here for me to relay to you every problem with every system on all of our shop floors. There is not even near the space for me to give you one representation of every problem. Therefore, I try to relay phenomena in embedded systems failure. I do not believe that time dilation is an issue. If you want me to send you my archives of the conversations taking place between Tom Becker of RighTime and the people doing the testing, I will. But, if time dilation is shown to be an issue, the model of what processor fails is irrelevant. If there is a possibility of time dilation in one series of embedded controllers, I better test them all, as dilation in one does not rule out dilation inanother.

Like I said, if you want a list of every failure on one of our shop floors, contact our auditors. If you want a huge database of what PLCs fail with what process controllers with what ladder logic on what tests, contact the EPRI. They are getting a rather large database going.

Oh, don't believe me that in a shop floor audit of a major US auto manufacturer more than half of the 1700 embedded systems failed? Contact Jim West, project manager for Deloitte and Touche.

Don't believe my that a good number of PBX's are going to fail? Try Bob Foley, vice president of Stone & Webster. Want their emails or phone #'s? Contact me. I don't put stuff up here that I am not willing to back up, unless I precede it with the word "unconfirmed".

====================================================================
If you're interested in some of the previous discussion ...DEFINITELY worth it.

15. Author: Geoffrey Jahnke Oct. 16 11:03 AM 1997
I think that Dave had a pretty good overview of safety issues and the year 2000, however I can provide some specific examples. I have documented proof of the first example, contact me for details DEC PDP-11 series embedded microprocessors are used for a wide variety of purposes, fire and security systems being a major use.

The PDP-11, when rolled over to 2000, will go haywire. It will not only cease to properly function, but will also corrupt its history file, rendering it useless and impossible to easily roll back for a temporary fix. Some real time torque tracks have been seen to roll over incorrectly; some even roll through the last minute of the year continuously! [the rest of this is an unproven made-up, but possible, scenario] The torque track doesn't properly shut down at the scheduled time, which overloads the motor. Instead of the motor properly shutting down at the overload, it remains active because its temperature monitoring system is in an infinite loop due to the failure of its RTC to properly roll over.

This generates enough heat for a small, usually easily sustainable, fire. However, the sprinkler systems are dead, thanks to the PDP-11 chip in the system. Suddenly this small fire is overtaking your factory, and no alarms are going off. Result:???- a safety concern at the least
Geoff Jahnke, Deere & Company - y2k embedded systems, email: gj35922@deere.com This represents my personal opinion and is not in anyway guaranteed or verified by my employer.

16. Author: Geoffrey Jahnke Date: Oct. 20 11:04 AM 1997
It has recently come to my attention that there may be yet another y2k bug that none of us have considered. This bug has been called the "time dilation" malfunction. Allegedly it causes an af affected machine to either loose or gain time after it has rolled over to the year 2000. A problem was supposedly found in an 8o286 embedded controller which, after rolling over to 00, no longer kept correct time. This does not even seem logical to me, seeing as a clock pulse is not software dependant. However, this wouldn't be the first y2k bug that is a little obscure. Has anyone heard anything more about this issue or experienced it in their testing?
Geoffrey G. Jahnke, Deere & Company, Year 2000 Compliance, Embedded Systems (309)765-4320 This represents my personal opinion and is not in any way verified or guaranteed by my employer.

17. Author: Rick Cowles Oct. 25 8:12 AM 1997
There are several people working on attempting to verify this issue, including Tom Becker of RightTime fame. The issue was first noted back in August of this year. Potential depth of the problem is still, as of yet, unknown. As far as I know, only older PC systems have been tested. If you'd like more in-depth details, go to www.dejanews.com, and do a search using the following key words:
comp.software.year-2000 time dilation

24. Author: Geoffrey Jahnke Nov. 17 10:47 AM 1997
In a recent embedded systems meeting I attended, the following examples of y2k failure were given:

1) An electric company has 29,000 non-compliant meters with no hope of complete replacement before 2000

2) A NEW $10,000,000 SCADA systems was shown to be non-compliant

3) Virtually every PBX system is non-complaint

4) UNCONFIRMED RUMOR Buick will be recalling a large number of cars due to y2k failures

5) In an unpublicized test of the New York City power grid, significant y2k failures were found. Enough to bring down the grid for a minimum of 13 days.

Real problems are out there.

25. Author: Bruce Hevner Nov. 17 2:00 PM 1997
This LOOKS like some kind of information but we need NAMES to call and NUMBERS to use to confirm that these things are true. I wish that everyone would do some investigation before they post. It's not that I don't believe it but as soon as you start to talk about things like this, the naysayers want NAMES and NUMBERS. And I can't say as I blame them.

29. Author: Geoffrey Jahnke Nov. 20 11:07 AM 1997
Steve and Bruce: While I understand you why you want the facts and proof, supplying that information is not possible. In the case of the Buick recall, do you honestly think that I am going to give you the name and number of the person in GM that gave me that information and jeopardize his position (provided that is where I got the information)?

When I do a shop floor test and find out that a perfectly compliant PLC is failing when used in conjunction with some HMI, what difference does it make if I give the model? If I say it was an Allen-Bradley PLC-5/20E that won't do you any more good that just saying it was a PLC. I would have to give you the firmware version, the bios version, the exact microprocessor used in that PLC production run, the basis of the ladder logic, and its use in process for you to be sure that you would have the same failure. The fact is that a compliant PLC can fail when used with a HMI.

I am trying to tell you that component testing is not good enough. If you want all the specs on the machinery of the testing, why don't you call Deloitte and Touche, our auditors. Send them a couple hundred grand and they will give you a database of all the tests they did for us and GM and Chrysler. Or send the EPRI 75 grand and they will be more than happy to let you look at a lot of proof.

The point is not the exact failure, rather the possibility of that failure. And if you want names and numbers to back up information that I have given on this site, contact me. Look in my profile.
Geoffrey G. Jahnke, Deere & Company, Year 2000 Compliance, (309)765-4320
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext