When compared with a worldwide embedded systems crunch on 1/1/2000, why do we even continue to bring up the IT issue? It's actually become a red herring which serves only to distract people from examining and making decisions on the embedded systems issue.

And optimists use it as a straw man, proudly displaying failed predictions or issues that have been "absorbed".

This is nothing more than a distraction from the (comparatively speaking) real issue, and should be viewed as such.

I do note that recently there have been some excellent threads on embedded systems. Let's hope that this becomes a major focus from now on.

-- eve (123@4567.com), November 02, 1999

Answers

from overlooked post 6 threads below (three links): http:// www.webpal.org/Beach2.htm#Intro2

2. The Frautschi Bug is the Century Bug in Embedded Processors

In early 1998 Dr. Mark Frautschi published a theoretical speculation

http://www.tmn.com/~frautsch/y2k2.html

that an even greater problem with the Century Bug would be found in embedded processors which are used, for example, in all sorts of industrial machine and control applications. At first I was highly skeptical of this hypothesis and I set out to see if I could find quantitative evidence of the bug's existence. This proved very difficult to do. On January 24th of 1999, I reported my efforts in:

http://www.webpal.org/REPORT.htm

That lengthy survey dealt principally with the Natural Gas Pipeline Industry although I also met with numerous other knowledgeable and concerned individuals in both government and private industry. The publishing of this article elicited numerous comments and insights that caused me to further pursue my inquiry with the petroleum refining industry. Then on April 9th, of 1999 I published:

http://www.webpal.org/Gas.htm

an interview at the Phillips Petroleum Refinery Research Facility in Bartlesville, Oklahoma, which verified the Frautschi hypotheses.

This interview was video taped by a contract producer for the ABC affiliate in Tulsa, Oklahoma but as has been the case everywhere, with all serious evidence and discussion about the Century Bug, has never been shown, and there is at present no indication that it ever will be.

The above essay EMPHASIZED as its MOST IMPORTANT FINDING that 25% of the critical, essential, and relevant embedded processors in that installation had been found to have the Frautschi bug. I have received a number of personal statements from engineers, such as in the Williams Pipeline Company, which have also had the approximate same quantitative experience. The difficulty in getting quantitative numbers in the form of percentages of faulty chips or systems, from the government, large companies, and other experienced and authoritative sources is a part of the curious cover up that has surrounded the Y2K problem for political, legal, and public relations reasons from the outset.

-- dw (y2k@outhere.com), November 02, 1999.

Oh, this is just too good!

First, all the early "trigger" dates, trumpeted by the "pessimists", were turned into pollyanna red herrings and straw men, when they didn't pan out.

But now, Y2k IT problems are just optimist's red herrings and straw men?

Too good.

-- Hoffmeister (hoff_meister@my-deja.com), November 02, 1999.

Quoting dear departed Saint Robert: "What are the facts and to how many decimal places?"

Night train

-- jes a tired ol footballer (nighttr@in.lane), November 02, 1999.

I am so tired of trying to guess, wondering if I have enough stocked, where the problems will be... sigh. Nobody knows, nobody is GOING to know until it hits. I am hoping for a nice boring Y2k.

Those of us who have prepared have pretty much maxed out - those who haven't are highly unlikely to be able to do so at this point and even less likely to figure out that it might be prudent to do so. My best guess is that we will likely see a last minute, panicky grab/run/frenzy the last week or so of December. Prez. Clinton already announcing that he may pre-empt (sp?) other tv programming in the hours up to Y2k -

Sorry for the grumping, just tired and ready for the suspense to be over.

-- Kristi (securxsys@cs.com), November 02, 1999.

Gentlemen...

For a year now I have tried to tell you guys that the software bug was the secondary problem. And that it was the date sensitive chips in the embeded systems which where going to be the real killers. Now bith all you want boys...Kick and schream and drag your feet all the way to the gallows. It will do you no good, the time ("appeals") is all up. In fify-nine days begins a "ride" like you have never seen before.

I have seen you and your peers postulate that there were at the most a decimal point of a percent of actual date sensitive chips. Sigh...You poor beknighted fools. The average was and is ranging from the stated 25% (in the thread above) to 10%. And it is as Just Another (engineer) stated...18 weeks to 18 months to blue print out a replacement form the failed chips in some if not most places.

A year ago I offered to a coupleof you guys, Chicken Little being one of them. To go on a verbal tour and calibration of a power generation complex.A pipe line or a oil refinery. And I was ignored. Probably because you pollys thought I was smarting off. Such was not the case...It was the only way I could think of to illistrate the seriousness of the looming black hole coming at u in 59 days. I at first believed that we could fix on failure, painful as it would be. Because the chips would fail over a period of 18 months. But I was apparently wrong. And the DOOMER Bob Brock was right about the time frame being two weeks or less. Saving for the chips which would continue to function to, through and after the roll over (untill the first time they needed to be re-set, re-booted in the 2000 date) then they would fail (or as I said, hit their infinity date and freeze up).

But I no longer see any need to worry about your not understanding the embeed systems problems. The threads and posts of the past few days are far better in their content and accuracy than I ever could have been in my efforts.

She is a coming at us boys...And she's a bitch kitty!

~~~~~~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~

-- Shakey (In_a_bunker@forty.feet), November 02, 1999.

Hoffmeister:

Perhaps it would be best if we all refrain from discussing who said what when, and simply observe that the IT issue, when compared to the embedded systems issue, has become nothing more than a quaint distraction that should be reserved for leisurely tea-party discussions for those who have the time for this.

Of course this comment does not pertain to those who are actively working on IT issues.

-- eve (123@4567.com), November 02, 1999.

eve,

When the first digital controls were proposed for applications in Process Control (including Power Generation and Distribution), they were FAR inferior to analog controls. Yet you have no idea about the wide eyed Zealots who pushed and peddeled them. Why, the Digital Cult could offer only one advantage...DATA LOGGING, which, by definition is date sensitive.

This Digital Cult triumphed not by offering a better product, but using appeals to ideals of their own making to "snow" upper management. And Zealots they were/are. The shear insufferable arrogance of these people.

Now, as is the wont of most cults, blood sacrifices seem to be in the offing to atone for their arrogance...except we are the scapegoats.

-- K. Stevens (kstevens@ It's ALL going away in January.com), November 02, 1999.

The following site looked at the problem you are speaking about. http://www.mfx2000.com Could you tell me if they have the answer. My boss has sent me on a search and find mission to locate a "REAL" system soulution to our short date issues. we found 9% of the programs in house with problems. Is this software a fix or more hype? The Rotterdam Report is comming out soon and addresses this very concern. I have been givin what i believe is the best information on the subject. Could you please dash all hope for me and my company. Or provide some level of comfort.

Sincerely, Bluefish

-- Blue (bluefish@thepond.com), November 02, 1999.

Eve,

Some folks regard some possibilities as more likely, and some other folks regard other possibilites as more likely. That's just one of many reasons why. Some folks might even regard your "red herring" assertion as quite absurd. We shall see what we shall see.

Jerry

-- Jerry B (skeptic76@erols.com), November 02, 1999.

A parable of the infrastrucure:

(Jane's driving on the Interstate, John's a passenger)

John Hey, watch it! There's something up ahead in this lane!

Jane I see it -- I can get around it on the left -- Whoa!! the steering's gone out -- I can't turn!

She hits the brakes...

The wheels fall off...

The car screeches to a stop, well short of the obstacle.

(Surely I jest....)

-- Tom Carey (tomcarey@mindspring.com), November 02, 1999.

From: Y2K, ` la Carte by Dancr (pic), near Monterey, California

I don't really think most forum regulars had much fear surrounding the 1999 dates. It would be helpful if those who claim otherwise would document it. I could be wrong, but I know at least that I didn't. The threads that I chose to read this year (about 10% of the threads available) did not make a big deal over these dates, unless they were started by pollies or anonymous posters stirring the pot. However, admittedly, I would not seek out threads on this topic, since these dates did not worry me.

In another thread, I lamented about how the "failed" 1999 dates had been unfortunately seized upon. I also was thinking at that time, but did not say so, that these dates got much played up by anonymous people. I believe that some of these people could be professional spinmeisters. I the originator of this thread on that point.

-- Dancr (addy.available@my.webpage), November 03, 1999.

should say: I agree with the originator of this thread on that point.

-- Dancr (addy.available@my.webpage), November 03, 1999.

Eve:

Embedded systems are very hard to get a handle on. Consider some of the issues involved here:

Defining the "system". Let's say you have a huge assembly plant. There is one master server talking to (say) 50 line servers. Each line server is talking to 50 robots. Each robot averages 10 subsystems. Now, do you have 25,000 embedded systems (the number of robot subsystems)? Do you have 2500 systems (the number of robots)? Do you have 50 systems (the number of different *types* of robots)? Or do you have one big system?

This question becomes critical when you look at reports of observed failure rates. Let's say you find date bugs in three of the line servers. If you regard the whole schmeer as one big system, you had a 100% failure rate. At the line server level, you had a 6% failure rate. At the subsystem level your failure rate was insignificant.

Much better would be some idea of the magnitude of the task. In this case, you need to fix at most three systems (if the "failure" was just an incorrect display but the line works fine, you may decide not to bother with a fix).

So the approach is to inventory all your systems at the level where testing makes the most sense, and either test those systems or research what results other companies with the same systems have discovered. Usually this is a combination, because results elsewhere (these are shared, by and large) will enable you to categorize your sustems into groups -- Date not used, no known problem with the date being used, problem but with established workaround, problem that *must* be remediated, and unknown (test it yourself).

Once inventory and testing are complete, you get to resource allocation. This is a tedious, case-by-case process of deciding what to do about each problem. For each problem, you need to balance the cost of fixing it with the cost of NOT fixing it. Finally, you start with the most cost-effective fix and work your way down the list until you run out of time.

Now, how much of this is being done, and where do critical industries stand? This is a black hole. I know from personal experience that I often get problem reports from equipment manufacturers on a non- disclosure basis. Nobody wants to publicize their errors and vulnerabilities. Some of the "reasonable worst case" SEC scenarios mention "unexpected" equipment failure, whatever that means, but this isn't considered the likely *primary* cause of the worst case, merely a possible contributing factor. The reliability of such reports, I believe, is a function of the legal department's assessment of possible lawsuit exposure.

I know this sounds a bit silly, but if you were an engineer put in charge of the y2k compliance of your physical facilities, do you think it might cross your mind to ask, "Gee, I wonder if our equipment will break?" I suspect this question has crossed the mind of more than one such engineer, don't you?

The major concerns have been expressed regarding all the "little guys" who aren't taking this problem seriously. I have no idea where this may stand. I have seen notices from manufacturers saying essentially "You purchased 5 model XYZ widgets from us within the past 3 years, and these devices must be (replaced/upgraded/repaired) or they'll stop working." Now, if you know these widgets are critical to your operation, you might get nervous. What if the manufacturer isn't just trying to rip you off, and the widgets really will fail? Should you risk it?

My sense of all this is that there *will* be breakdowns, in large enough numbers to have a visible impact. Still, from an economic viewpoint embedded failures are much like IT failures -- they happen all the time, and they get absorbed. I personally doubt they'll be absorbed without a ripple, but an economy is adaptive and has a lot of slop. I believe we're in for interesting but not catastrophic times. I'm not a psychic, though.

-- Flint (flintc@mindspring.com), November 03, 1999.