There are no hidden clock functions in embedded chips. The only chips with the posibility of having a date function are those which have the ability to have software programmed into them. Since most ptogrammable chips are used in systems with an external clock source, they have not been programmed with their own "clock" functions. The main reason for this is that it takes up a lot of memory to write the booleen algebraic equations for seconds up to years, leaving little room left to program the chip for the desired function you attempting to accomplish. So, all chips with the exception of the BIOS chip and the "programmable chip, are Y2K error free. That means that of all of the billions of chips manufactured, there are just a minute number 00.0003% with the possibility of a Y2K impact and of those an even smaller % have actually have an impact, of which the majority are simple date stamps which are a normal, acceptable function today and will be after Y2K and an even smaller have an impact that could cause an error or equipment failure. Origionally Dave Hall, with no practable experience in intigrated circuits, embedded chips, or embedded systems started giving out statements (always disclaimered as his opinion only) that there were billions of chips and (origionally) 5 to 10 % could have Y2K problems that could cause mass failures in every area of life that used electricity. He insisted that each individual device had to be checked. He even spoke about it in front of congress. From that we have had an explosion of speculation, generally from other people who had as little or less experience than him, that has created the biggest misinformation fiasco in history. This is no urban legend, this is planitary legend. Today Dave Hall claims he made his mistakes in judgment because the real information was not available 2-3 years ago. That is NOT true. The informaton was available and he refused to listen to the people who had that information. To pass on information that one has no way of knowing is true or not is morally wrong. To be a member of the United States Air Force, with the training in the UCMJ (Uniformed Code of Military Justice)which is a requirement (The training) leaves any person who knowingly passes on information which they know to be false, or to not have proof of being true, open to investigation which can lead to court martial. There are very strict guidelines in the UCMJreguarding "rumors and propaganda". These days Dave Hall states that he no longer believes what he wrote about the magnitude of the "embedded" problems. Yet he does not publically publicize it in the same manner he did with his origional estimates. He also does not contact and correct those who have his or5igional evaluations posted all over the internet so thay would know to change it. But then all of all he has ever written has been his personal opinion only. Unfortunatly he was taken for an expert in the field of "embedded anything". He has, after stating his origional opinion, attempted to actually learn about the subject, but hey... isn't that going about it backwards? Where is his apology, his public retraction spamming every Y2K mail-list he spammed with his origional opinion?

-- Cherri (sams@brigadoon.com), July 30, 1999

Answers

Cherri,

I appreciate your insight. Are you saying that no problems will occur as a result of embedded systems or what ever problems occur will be very scattered?

Thanks,

Mike

=================================================================

-- Michael Taylor (mtdesign3@aol.com), July 30, 1999.

Will a square peg (four digit logic) pass through a round hole?

zen programmer

-- dw (y2k@outhere.cpm), July 30, 1999.

dunno zen programer. Why don't you eat a few Lincoln Logs and let us know in about 24 hours?

Seriously, how bout you shut the hell up with your nonsense and let this thread stay on topic concerning embeded chips?

-- no zen master (zen@makes.nosense), July 30, 1999.

Just a minor point here Cherri. The term "embedded system" is generally used to describe a black box that that has a CPU and a program stored on ROM/PROM/EEPROM etc. Nobody considers an "and gate" chip an embedded chip, so your figure of 00.0003% doesn't say anything.

Virtually EVERY "black box" has it's own CUSTOM WRITTEN program stored in ROM. Now, you were saying??? <:)=

-- Sysman (y2kboard@yahoo.com), July 30, 1999.

Cherri,

At what point did Dave Hall admit mistakes in judgement, what percentage of chips does he think are vulnerable now...and do you have a link on this? The question of when is important, because by the end of 1998, it was already being said that the larger estimates (you mentioned 5% to 10%) were probably too high and might be 1% or less. A failure rate of even just 0.25% could cause major problems in complex systems, though.

If you have a link about Dave Hall, I'd like to see it.

-- Linkmeister (link@librarian.edu), July 30, 1999.

Pot Kettle Black

Cherri, you know nothing about microprocessors. I could pick this post apart in detail but its 2am and I'm too tired right now I will do so later if someone asks me to.

-- biker (y2kbiker@worldnet.att.net), July 30, 1999.

Miz Cherri

Though it will not do you blood pressure any good...I disagree with you. Now as to your apparent spouce, if that wording is correct. One Mr. Chicken Little (yes I read the y2k Satire forum also).Who seems to believe he is a past master at embeded systems. May be he was refering to your expertice, I have had some excellent journey man (Ladies) on my jobs... Could be you where one of them. Other wise young lady, you are laboring under a false sence of security.

The first recent exception to your proclaimed rule is the Chevron refinery in California. The one which blew up over a month ago. Then went back on line and another section of it blew up..Classic to the staggered sequence of start-up proceedures.

Then there was the coal fired generation plant near Hamlton, Ind. That one was the turbine blowing out of the deck...I was asked if I wanted to go up on it, the information I received was that the embeded vibration sensors failed, allowing the turbine to continue operation and thusly setting up a harmonic vibration which ruptured the hydrogen coolant envelope.

The Ford Dearborne fire was in the on site power generating plant...A valve failed in the closed position.

The there was the coal fired generatiion station out side of K.C. which had it'd safty valve fail and blew out a huge section of it'd boiler. Yep! You guessed it, the embeded system refused to open the safty valve.

But I could go on and on..the point dear lady. There are chip manufactors all over the world. And you most certainly do not have an exhaustive list of them...And there is secondary clocks embeded in a whole lot more of a percentage of the billions of chips than you are trying to make people believe.

To date there have been five power generation complexes that have ceased, violently to provide power,I kow the reason for three of them.

The refineries,are too many for me to keep up with. Certainly there are some every year that explode. But not in the numbers we have seen this past 7 months.

But then. you will hold to your position and I mine. Only I will not be caught by surprise. But you will be, Oh! And give my regards to Mr. Chicken Little.

-- Shakey (in_a_bunker@frty.feet), July 30, 1999.

Miz Cherri

Though it will not do you blood pressure any good...I disagree with you. Now as to your apparent spouce, if that wording is correct. One Mr. Chicken Little (yes I read the y2k Satire forum also).Who seems to believe he is a past master at embeded systems. May be he was refering to your expertice, I have had some excellent journey man (Ladies) on my jobs... Could be you where one of them. Other wise young lady, you are laboring under a false sence of security.

The first recent exception to your proclaimed rule is the Chevron refinery in California. The one which blew up over a month ago. Then went back on line and another section of it blew up..Classic to the staggered sequence of start-up proceedures.

Then there was the coal fired generation plant near Hamlton, Ind. That one was the turbine blowing out of the deck...I was asked if I wanted to go up on it, the information I received was that the embeded vibration sensors failed, allowing the turbine to continue operation and thusly setting up a harmonic vibration which ruptured the hydrogen coolant envelope.

The Ford Dearborne fire was in the on site power generating plant...A valve failed in the closed position.

The there was the coal fired generatiion station out side of K.C. which had it'd safty valve fail and blew out a huge section of it'd boiler. Yep! You guessed it, the embeded system refused to open the safty valve.

But I could go on and on..the point dear lady. There are chip manufactors all over the world. And you most certainly do not have an exhaustive list of them...And there is secondary clocks embeded in a whole lot more of a percentage of the billions of chips than you are trying to make people believe.

To date there have been five power generation complexes that have ceased, violently to provide power,I kow the reason for three of them.

The refineries,are too many for me to keep up with. Certainly there are some every year that explode. But not in the numbers we have seen this past 7 months.

But then. you will hold to your position and I mine. Only I will not be caught by surprise. But you will be, Oh! And give my regards to Mr. Chicken Little.

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

-- Shakey (in_a_bunker@frty.feet), July 30, 1999.

[Fair Use: For Educational/Research Purposes Only]

http://www.jsonline.com/bym/tech/0214chips.asp

Problems lurk in more than just computers

By Douglas Armstrong of the Journal Sentinel staff

February 14, 1999

Embedded chips are the wild cards of Y2K.

Only a tiny percentage of them are expected to fail when the calendar rolls over into the next century after 11:59:59 Dec. 31. But there are literally tens of billions of these dedicated processors out there in everything from microwave ovens to airliner cockpit controls (a Boeing 777 has 1,000).

Some, obviously, perform critical duties. And, according to many experts, there isn't time to check them all and tell which are bad and which are not by the time the new millennium ticks ominously in.

One reason is that the programming in embedded chips is not always readily accessible for inspection. And there are hundreds of different varieties. It's like looking for burned out light bulbs in Las Vegas -- with the power switch turned off.

"Most of the failures will be nuisance issues," says Bill Thompson, senior analyst with Automation Research Corp., a consulting firm in Dedham, Mass.

Not everyone is so sanguine.

"The embedded systems problem is still a black hole," says Harlan Smith, a Y2K analyst who moderates an online forum on the issue at y2knews.com.

"Identifying the devices that are not compliant and assessing the effect of them on the environment in which they operate is complicated."

Corporations spent a lot of time and money bug-checking the front office software code on their mainframe computers for Y2K compliance before realizing an even bigger problem existed on the plant floor in automation controls and other systems running on embedded chips.

A massive catch-up effort is under way, at least in the United States. How big is the job? Experts can only estimate.

Tava Technologies, a Colorado software and consulting firm that specializes in assessment and repair of plant Y2K problems, says that in its experience at more than 400 sites, it has "yet to find a single site that did not require some degree of remediation (repairs)."

At a pharmaceutical firm with operations in 39 countries, for example, Tava found 4,457 embedded processors in the laboratory equipment and manufacturing facilities of one location.

Based on an inventory it conducted, 18% of the items were not Y2K compliant and 17% could cause a plant shutdown or affect production.

"The chance of these systems failing was 70% for the lab and 80% for manufacturing and facilities," says Bill Heerman of Tava's Denver office.

Tava estimated that it would take 39 weeks to inventory and analyze the firm's 125 plants at a cost of $11.5 million. The fix would take another 31 weeks and cost $54.8 million.

Is there time to fix it all?

"There is little reasonable prospect of timely correction of all Y2K exposures that exist," says a report from Manufacturers Alliance/MAPI Inc. "The effort to achieve compliance is one of damage mitigation."

The effects of a maverick embedded processor are unpredictable. It depends on where it exists in the chain and what is connected to it. Typically, these chips gather a lot of information to make limited decisions.

If a single temperature sensor tied to an embedded chip in a complex chain of measuring instruments used in manufacturing were to go haywire because of a Y2K problem, for example, the manufacturer could end up with a product with different ingredients -- if the product came out at all.

The stakes involved in locating and repairing these chips are huge, given the dependence of our systems on them. The size of the chore is every bit as large, given the proliferation of embedded chips in number and design.

"They are everywhere," says Steve Barnicki, an associate professor of electrical engineering and computer science at Milwaukee School of Engineering.

Why?

"They are cheaper and more trouble-free than mechanical systems," says Barnicki. As a result, they have played a pivotal role in powering productivity improvements everywhere since first introduced in the 1970s.

Fortunately, many (like the one in your portable CD player) couldn't care less about dates.

"There are embedded systems that don't have the faintest idea what year it is," Barnicki says.

So why not hunt down those that compute dates and fool them by turning back the year to play it safe, you ask?

The answer lies in the sheer number of chips and the independent way many have been programmed. These processors also work in tandem with chips and systems that would experience their own set of problems if a false date turned up.

The issue is made more difficult by ubiquitous quirks, such as chips that have the ability to disguise that they have date capabilities and escape detection until they fail. Or those that can have a delayed reaction.

"We encountered a controller on a process line recently that rolled over to Jan. 1, 2000, just fine," says Kurt Schmidt of Tava Technologies' Denver office.

"And it kept working just fine until it went to Jan. 32, then Jan. 33, Jan. 34 and so on all the way up to Jan. 54. Some of these systems won't show the date problems immediately."

Embedded chips come in a number of varieties from a host of manufacturers.

On the low end are ROM (read only memory) chips that contain basic instructions that cannot be changed. If these have a Y2K problem, they cannot be saved. The machine they are attached to may have to go as well, if a compatible substitute chip cannot be found.

Next are PROM (programmable read only memory) chips, which typically can be reprogrammed only once, according to Barnicki.

EPROM chips (erasable programmable) can be reprogrammed thousands of times after they are exposed to ultraviolet light. Finally, EEPROM (electrically erasable programmable) chips and similar Flash ROM chips have the potential to be reprogrammed tens of thousands of times.

Rockwell Automation, based in Milwaukee, is a leading maker of programmable logic controllers (which use embedded chips) to run factory automation configurations. The brand name is Allen-Bradley.

The company lists 17 different known year 2000 issues with its controllers on its Y2K Web site.

In addition, it outlines a procedure to test its controllers for other potential problem dates, such as Feb. 29, 2000 (leap year), Jan. 10, 2000 (1/10/2000 -- first seven character date) and Sept. 9, 1999 (the "9999" date field matches an end-of-data "9999" input signal in some computer programming codes).

Rockwell/Allen-Bradley's programmable logic controller issues are a microcosm of the complexity of the problem. They have:

Processors that won't roll over on their own and must manually be set to 2000.

Processors that roll over to a new century only if the power is on at the time of century change. (Jan. 1, 2000, falls on a Saturday in a holiday weekend when many plants would ordinarily be dark.)

Processors that won't roll over without new software or bug fixes.

Processors that are dependent on the compliance of the system they are connected to.

Processors that are totally dependent on systems that are not prepared for 2000 at all, such as 286 and 386 computers.

Many programmable logic controllers don't have clocks.

"You don't put a date in there unless you need it because it wastes power," Barnicki says. "Embedded processors are stripped down to fit the application."

Although a vast database of embedded chip compliance has been assembled by Tava Technologies and others, manufacturer assessments of the chips can only help so much.

"They can test all they want," says Automation Research Corp.'s Thompson, "but it's really up to the end user with the local application to test out the system. (The processor) might work in a vacuum.

"Once it's installed with custom add-ons and special report functions that have been locally written, there is no way for suppliers to help the users predict what will happen."

Says Tava's Schmidt, "There are going to be hiccups."

And some hiccups may occur in places that cause more than just a nuisance or harm to a negligent company.

The American Chemical Society has warned that chips automating control pumps and valves to prevent spills and other hazards may have problems that have not been addressed by small to medium-size firms.

"Even chemical companies that have actively addressed the Y2K problem may have underestimated its depth," says an article in the society's Chemical and Engineering News.

"Consultants hired by Occidental Chemical found 10 times more systems with potential Y2K problems than the company's own engineers found."

The new assessment of Y2K progress by larger American companies from Manufacturers Alliance/MAPI Inc., on the other hand, found cause for "cautious optimism" among big companies, given the level of awareness and the amount of effort.

Larger companies surveyed said they were on track to be compliant by 2000, while smaller firms were having trouble finding technical help that was affordable and competent.

"In the final analysis, the Y2K issue is an annoying, resource- intensive exercise in triage and damage mitigation," the report concludes. "Time is short and the stakes are high.

"The century rollover could be a nuisance or a calamity depending on the diligence with which Y2K correction is pursued."

----------------------------------------------------------------------

-- Linkmeister (link@librarian.edu), July 30, 1999.

Cherri,

I appreciate your insight. Are you saying that no problems will occur as a result of embedded systems or what ever problems occur will be very scattered?

Thanks,

Mike ****

Mike yes and no. The faults from embedded systems will not be caused by the hardware, rather the system will recieve bad data from a source that feeds the system. An example would be BOMA. Building Owners and Managers Association http://www.boma.org/

The fire system, elevator operation and maintenance tracking, lighting etc is usually controlled by a main computer, usualy a PC. If the PC gives out non compliant dates the bad data is assed on to the "embedded system" which could cause faults. One example of a companiessystem was encourging:

**The letter from Andover Controls Corperation was especially reasuring; "As the technology leader in advanced micro-processor based building controls systems, Andover's engineers anticipated, planned, and tested for date transition from 1999 to 2000 when out building control products were originally developed".**

http://www.egroups.com/group/year-two-thousand/183.html? http://www.boma.org/ Building Owners and Managers Association (BOMA) International is a premier network of over 16,500 commercial real estate professionals BOMA International represents 84 United States, ten Canadian, and seven overseas associations in Australia, Indonesia, Japan, Korea, the Philippines and South Africa.

http://www.boma.org/year2000/ BOMA is committed to helping commercial real estate professionals prepare their buildings for the Year 2000 through timely information. BOMA is pleased to post relevant articles pertaining to the Millenium Bug on its Web site. You will also notice that we have established a Year 2000 Special Interest Group (SIG) where users can download articles, read and post messages and even chat in real time.

http://www.boma.org/year2000/letters.htm Letters of compliance from;

Andover Controls Corporation Dover Elevators Kastle Systems, Inc. Montgomery KONE Otis Elevator Company Timberline Software Corporation The Trane Company U.S. Department of Housing and Urban Development York International

The letter from Andover Controls Corperation was especially reasuring; "As the technology leader in advanced micro-processor based building controls systems, Andover's engineers anticipated, planned, and tested for date transition from 1999 to 2000 when out building control products were originally developed".

********

It has been discovered in many areas that this situation is common.

I hope this helps

Cherri

-- Cherri (sams@brigadoom.com), July 30, 1999.

I'm with Shakey on this one.

-- Andy (2000EOD@prodigy.net), July 30, 1999.

Cherri,

I think I found a thread with parts of the Dave Hall article you're talking about. You posted some of it, and someone else posted more parts from it on the following thread:

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000vRF

"Dave Hall "Embedded Garu" now says: I no longer think that there will be major collapses caused by embedded systems impacts."

-- Linkmeister (link@librarian.edu), July 30, 1999.

Just a minor point here Cherri. The term "embedded system" is generally used to describe a black box that that has a CPU and a program stored on ROM/PROM/EEPROM etc. Nobody considers an "and gate" chip an embedded chip, so your figure of 00.0003% doesn't say anything.

Virtually EVERY "black box" has it's own CUSTOM WRITTEN program stored in ROM. Now, you were saying??? <:)=

-- Sysman (y2kboard@yahoo.com), July 30, 1999. *******

Sysman first of all so many people have a different idea of what an "embedded system" is. I will reply to your discription of one.

We are discussing Y2K year anomolies correct? It is my understanding that no CPU chip contains a clock. RTC to be precise. Yes the ROM/PROM/EEPROM etc can have date calculating programming. But as I said above, that kind of programming is bulky and takes up a lot of programmable space on the chip. Also the programmable chip needs a unfailing timing input to keep the date and time. This is where a RTC and BIOS comes in as the easiest and most common source (if not the only source). The programmable device would be doing the "job" of the BIOS and it would be redundant to have it do so. t s so much easier to grab the date data from the BIOS. To provide accurate date-time you need a source that would keep "time" in a reliable way otherwise the function would be moot. That means the "black box would also have to contain a RTC, BIOS and a Battery, as well as an external source of power. The black box if totally independant of an external computer would have to had the time and date set upon initialization. In my research with semiconductor manufacturers, I have found that they do not do this at the factory for many logical reasons. As it is common practice for maintenance manuals as well as setup proceedures to come with such devices, the information would be available to those who are assigned the responsibility to connect and maintain the device. They would be aware of the need to periodically check the voltage on the battery. They would be aware that the Bios or its counterpart would have to be checked and updated to Y2K compliancy. The documentation would state the fact of the existnce of RTC and Bios and how to set the date.

As for my percentages - they are based on the fact that origionally Dave Hall considered every type of "chip" on his estimates. I am mearly "troubleshooting" *grin* eleminating those without posibility of Y2K impacts. Dave has lowered his "estimate" of possible problem chips, perhaps in the same vein as I have.

-- Cherri (sams@brigadoon.com), July 30, 1999.

Embedded systems fault casebook:

http://www.iee.org.uk/2000risk/Casebook/eg_index.htm#TopOfPage

-- Linkmeister (link@librarian.edu), July 30, 1999.

From the California State Water Resources Control Board website: http://www.swrcb.ca.gov/html/y2ksumry.html

"Summary of YEAR 2000 Embedded Systems Issues

"There is a lot of material contained in these links. Quite a bit of it is redundant. Realizing that your time is limited, and you may not be able to visit each of the sites listed, this document is an attempt to summarize the key issues.

"Based on experience, it takes 21 months to inventory, analyze, fix and test the embedded systems in a small to medium sized plant. "Testing of embedded chips must be done very carefully; there are instances where tests have damaged chips beyond repair.

"Testing of embedded microchips can be very complex, requiring trained specialists with specialized equipment.

"Approximately 10% of embedded chips have date functions. Approximately 4% of those may not be year 2000 compliant. That equates to an estimated 160 million non-compliant chips in the world.

"Just because a chip does not perform a date function does not guarantee it will work properly after 1/1/2000 (date sensitive chips have been used in devices that do not perform date functions).

"Just because an embedded chip works properly on 1/1/2000 does not guarantee that it will continue to operate properly after that.

"There are over 30 tests that must be performed on each embedded system to ensure that it is year 2000 compliant.

"Vendors of electronic devices cannot be certain that they are year 2000 compliant (therefore, all devices must be tested).

"Just because one device is Y2k compliant, there is no guarantee that all other devices that have the same manufacturer, model, version, lot number, etc. will also be compliant (therefore, all devices must be tested).

"A system containing numerous Y2k compliant embedded microchips (from different manufacturers) may not be compliant, because there is no date standard followed by all manufacturers.

"It will not be possible to test all embedded systems and repair the non-compliant ones (therefore, efforts should be focused on the most critical systems).

"It is possible that major utilities (electric, telecommunications, water, etc.) will be unable to operate for some period of time after 1/1/2000 (therefore, it is essential to have a contingency plan).

"Businesses will be held legally responsible for damages caused by non-compliant embedded systems. " [END]

see also http://www.swrcb.ca.gov/y2k/html/links.html#DOEMP

-- marsh (armstrng@sisqtel.net), July 30, 1999.

Cherri,

At what point did Dave Hall admit mistakes in judgement, what percentage of chips does he think are vulnerable now...and do you have a link on this? The question of when is important, because by the end of 1998, it was already being said that the larger estimates (you mentioned 5% to 10%) were probably too high and might be 1% or less. A failure rate of even just 0.25% could cause major problems in complex systems, though.

If you have a link about Dave Hall, I'd like to see it.

-- Linkmeister (link@librarian.edu), July 30, 1999.

************

Linkmeister Unfortunatly Dave does not appear to admit mistakes. He makes excuses. Or tries to justify why he posted his past estimates.

The most recient exchange between he and I started with this article: http://www.dallasnews.com/metro/0725met100y2kprepare.htm

Y2K preparations a two-way street

07/25/99 Some expect the worst, others plan nothing for 2000

snip

Progress noted Many computer "fixes" are lagging - particularly in small businesses, municipalities and some rural utilities. However, authorities said the overall scope of the work has shrunk because larger entities have made so much progress and fewer problems have turned up than first feared.

Water plants, for example, are not complicated and have very few problems, said Dave Hall, a Chicago embedded-systems engineer and member of the Society of Information Management's Year 2000 Working Group.>/b> "Surprised the heck out of me," he said. "If you'd asked me a year and a half ago, I'd have been heading for the hills. But there's been so much work done. There are still problems, but I don't think there will be disasters or the grid will go down for months. (This paragraph says a lot NOT) "I'd be ready for a slowdown in the velocity of the flow of stuff. Stuff will still be available, just not as fast or as much as you want."

We then went on to exchanging e-mails (through a variety of lists) *************** Gartner:"....doing nothing is probably a good bet." Dallas News FRONT COVER STORY (Sun.7/25/1999) xxxxxxxxxxxxxxx

Need proof that "On the Job Training" is an "educational experience"??

REMEMBER THIS "TRUMPET OF EMBEDDED DOOM"??

DAVE HALL (looks like he wants to work at something after 1/1/2000): Water plants, for example, are not complicated and have very few problems, said Dave Hall, a Chicago embedded-systems engineer and member of the Society of Information Management's Year 2000 Working Group.

"Surprised the heck out of me," he said. "If you'd asked me a year and a half ago, I'd have been heading for the hills. But there's been so much work done. There are still problems, but I don't think there will be disasters or the grid will go down for months.

"I'd be ready for a slowdown in the velocity of the flow of stuff. Stuff will still be available, just not as fast or as much as you want."

*************

To which Dave replies: Date: Sun, 25 Jul 1999 22:08:13 -0500 From: David Hall

It's not that Y2K experts "Now don't expect problems", it's more that we don't expect OVERALL disastrous problems in the more prepared countries. Do we still think there could be pockets of major problems in those countries? Sure we do.

snip

And by the way, without the original "Trumpet of embedded doom (although all we stated was that we did not know how prevalent Y2K impacts were in embedded systems but we were worried about it and everyone should check to see what the real story was in their systems and equipment. Check out our words and articles rather than letting someone interpret them for you),

(Cherri here with a little input from an older e-mails)

From: "Dave Hall" To: Subject: Re: Embedded Systems Date: Tue, 14 Jul 1998 21:18:31 -0500

"John, Only one comment on the info you wrote - None of the people working the embedded chip problems has ever said that we must find, test, and fix some billions of microprocessors (chips). What we are saying is that somewhere among the billions (pick your own number, I'm tired of arguing about a number that is really impossible to get and prove) there are maybe 10% (again, pick your own number, it's different in each industry sector and in each type of facility) that will be affected by the "00" transition or "00" dates. Now, find those 10% and fix them. FIND THOSE 10% AND FIX THEM. How do you suppose we can find them? Well, by testing every one of the billions of chips out there. If you have another way to PROVE to us that there is no risk of an unknown failure, then please provide it to the mailist."

(Cherri here- continueing the e-mail I interupted)

would everyone have rushed to check out and fix Y2K problems they found? History says not until too late. Enough embedded systems problems have been found to shut lots of stuff down if they had not been found and fixed. Simply because people found and fixed problems and fewer impacts will occur, I think vilifying the original question askers is a little on the ugly side. There was simply no data available to make more than very rough estimates, so that is what was done. Know a better way to get people started? If so, you should have used it.

***

To which I, Cherri, replied;

Date: Sun, 25 Jul 1999 22:57:42 -0700 From: Cherri Stewart

Dave Hall says: "There was simply no data available to make more than very rough estimates, so that is what was done." **** There was plenty of data and plenty of people who knew the data, but you did not want to hear it or believe it. I have told you for over a year that your "estimates" and opinions were wrong.

This shows why people who express their "personal opinions" about a subject they have no knowledge of, should be ignored and not called "experts". Learning the subject after giving predictions of X% of billions of chips failing does not justify having stated the "opinion" on the first place. Especially considering it is considered Fact due to the wide spread reproduction of that opinion which to this day is still believed by too many. The damage has already been done. And will not be forgotton.

Cherri Stewart

*************

Next Dave replies: Subject: Re: Y2k experts now don't expect problems. Date: Tue, 27 Jul 1999 20:14:42 -0500 From: David Hall Organization: Hall Associates To: Cherri Stewart

Point out the data and test results that were available four, three, two or one year ago. What publications had such data in them? What group provided such data and where? What were the tests that provided the data? How often and what equipment was tested? As you and Charlie often say - Furnish the references. Amazing how often people will say "the data is available" and then refuse to answer the question "Where?". By the way, if you disagree with my opinions, you don't have to read them. At least I do not claim to know everything about computers. My opinions are expressed as opinions, for anyone to agree or disagree with. I don't stoop to threats and personal attacks to try and silence anyone who has a different opinion. I do hope that "It will not be forgotten."

Dave Hall My opinions only, of course

****************

And by now you know I have to answer that e-mail *grin*

bject: Re: Y2k experts now don't expect problems. Date: Wed, 28 Jul 1999 16:55:59 -0700 From: Cherri Stewart

(warning, this is a long one-but you see this is not on a web page to be read, so I am doing it this way)

David Hall wrote: > > Point out the data and test results that were available four, three, >two or one year ago.

The "data" is everywhere, and has been for anyone who knew/knows how to "read" it. Tests are not needed to prove a full wave bridge rectifier has no Y2K problem. It is not necessary to "test' every electronic device to determine if it has a Y2K impact. It is called knowledge. People have studied and worked with digital electronics for decades. They can eleminate potential (Y2K)problem chips and "devices" simply from their ability to understand how they work. As for testing being available to people who do not know or understand such things, the need has never arisen. It is rather like asking for data and test results on how your car works. Not many care and much bother to even think about it. They leave that job to those who's job it is to maintain and fix them, Those who know what is needed to be known and what tests, if any are needed.

>What publications had such data in them? There are plenty, but then again you would have to worked in the field to have knowledge of them. One I have used for decades is the Allied Electronics catalog. Personal preferance. But I have yet to know a "shop" that did not carry a few copies. I know of some shops that have copies dating back as far as 1968 (I believe) There are books that cross-reference part numbers between manufacturers. There are even groups on the internet who exchange information and have copies of data sheets and schematics of equipment that has long been out of production. But then again you have to have the ability to understand what you are reading in them. AND you have to at least know what to ask for. And, no, they do not carry "test results" for Y2K faults, although some catalogs are now coming out with "Y2K compliant" notices for those devices which could have Y2K impacts.

You have to have a knowledge of electronics/digital electronics to understand what you are reading.

>What group provided such data and where?

Group? Are you asking if some "group" tested every single electronic device to determine if it had a Y2K impact? That is totally unnecessary.

It is akin to looking down the POP isle in the grocery store and asking for proof that each has been tested to prove they contain some form of liquid. There are many groups/companies with the information on such devices. As a matter of fact I have researched over the internet different semiconductor manufacturers and found that even "embedded chips" (those with the ability to be programmed) are sold unprogrammed.Some buyer have the factory programm the devices for them-to their specifications, but that information is the property of the buyer and not the responcibility of the semiconductor manufacturer. That does not mean that those who buy and themselfs program the programmable devices did not input factors that could cause Y2K impacts after having purchased the device. In which case the manufacturer who purchased the device would have the information on what they burned into the device.

The devices that have the ability to be programmed with "date" data are clearly defined.

>What were the tests that provided the data?

This is a non applicable question.

This is not software where you have to test the results of a program. This is physics, the capabilities of the devices are determined by their design, and once in production, function as designed.

>How often and what equipment was tested?

I suppose the equipment is "tested" each time it is used, if a fault occurs then the equipment has failed and needs to be fixed. Just lke a flat tire on your car.

If you are speaking of a device that is made up of a number of electro-mechanical and digital parts, then the first thing you do is determine if there is a "date" function. Next you examine the documentation to see how this "date function" is used. ie if used for a date stamp and will it roll over to 00, and you do not care (you have been accepting 7/21/78, 5/14/92 etc forever) then there is no need to go further. If the "date function" is used in calculations, then you must troubleshoot (diagnose) the cause and effect and fix the problem. If there is a date function which is used to calculate, you must first determine where the "date" informtion origionates. As you yourself have found, most situatiuons like this led back to a "software function" that that preseeds the device itself. ie form a "PC" type computer microprocessor / mainframe.

>As you and Charlie often say - Furnish the references.

I did not realise you believed Charles and I were joined at the hip~~

>Amazing how often people will say "the data is available" and > then refuse to answer the question "Where?".

The "data" Mr. Hall is in my head and in the heads of the thousands of people who have worked on this type of equipment, be it in Power generation and distribution, Building management, Biomedical equipment maintenance and repair/ water and sewer etc. Each field has its personell who know how the equipment works and can define if there is a Y2K problem in that equipment. This is a VERY different situation from working on mainframe computers.

I apologise, having assumed that with your credentials as an embedded system/chip expert, you would have knowledge of the sources of available critical information on the subjects. It must be difficult for you to make knowledgable informed opinions on a subject you do not have the basic data base for.

> By the way, if you disagree with my opinions, you don't have to read >them.

The problem I have with your opinions is not that I read them and believe they are incorrect, it is the fact that less knowledgable people read them and do not have the ability to know if they are correct or not.

> At least I do not claim to know everything about computers.

Not all people can claim the ability to know as much about computers and computing as I, I do not fault you on your lack of ability.

> My opinions are expressed as opinions, for anyone to agree or >disagree with.

Unfortunatly your opinions have been taken as facts, even with your disclaimers, and have spread far and wide with inpacts in many areas.

>I don't stoop > to threats and personal attacks to try and silence anyone who has a > different opinion.

After much thought I have decided NOT to cut and paste an answer to that remark.

>I do hope that "It will not be forgotten."

No chance of that, it being publicly posted I am sure there are plenty of Y2K sites still carrying your origional opinions. > Dave Hall My opinions only, of course

Cherri Stewart

************

Finally the last mail-so far

Date: Wed, 28 Jul 1999 21:53:30 -0500 From: David Hall Organization: Hall Associates To: Cherri Stewart References: 1 , 2 , 3

Last reply on this thread to the various maillists from me.

The major problem here is that you are talking hardware and I am talking software/firmware. Of course electronic hardware has no year 2000 problem. The potential for creating Y2K problems comes in when the hardware has the ability to be controlled by some sort of software program.

Dave Hall My opinions only, of course

(Cherri again) what ever happened to what he said about: FIND THOSE 10% AND FIX THEM. How do you suppose we can find them? Well, by testing every one of the billions of chips out there.

-- Cherri (sams@brigadoom.com), July 30, 1999.

Bold off.

-- Linkmeister (link@librarian.edu), July 30, 1999.

Shakey, you are confusing apples with oranges. I am talking about Y2K embedded failures.

I have to agree with you totally on failures of (embedded?) systems failing. What I think you so not comptrehend is that these systems are not necissarily digital systems, but analog. Just because it is electric that does not mean it is computerized. Valves in general have always been electro-mechanical and demand strict periodic maintenance and diognostic testing. Unfortunatly too many companies have become slack in inforcing standards that would, if followed, prevent these tragities. It is easier for a worker to "sign off" that a test or inspection has been performed than to go out and do it. It's boring, most of the time they do not find anything. So why bother? Also downsizing has dwindled the manpower that is needed to do these tasks. That is being shown to be the cade with the fire from the pipeline in Washington state. The government has now determined that the regulatory organization that oversees fuel, oil and gas pipelines has been very lax in their job due to pressure from the companies they are assigned to inspect. But that fact can not be blamed on computerized Y2K failures.

"he Chevron refinery in California. The one which blew up over a month ago. Then went back on line and another section of it blew up..Classic to the staggered sequence of start-up proceedures. "

(Cherri)I agree this shows a criminal lack of using correct proceedures!

the information I received was that the embeded vibration sensors failed, allowing the turbine to continue operation and thusly setting up a harmonic vibration which ruptured the hydrogen coolant envelope.

(Cherri)The vibration sensors were hardware electro-mechanical not Y2K computer date failures. Once again poor maintenance and repair-pure lack of proper management. Shamefull!

The Ford Dearborne fire was in the on site power generating plant...A valve failed in the closed position.

(Cherri) again a hardware and/or electric failure. The valve should have been checked periodically to make sure it was in working order.

The there was the coal fired generatiion station out side of K.C. which had it'd safty valve fail and blew out a huge section of it'd boiler. Yep! You guessed it, the embeded system refused to open the safty valve.

(Cherri) It has been my experience and knowledge gathered from many areas, that safty valves may rely on a computer input, but that onput is bypassed, for safty reasons by hardware. In other words in a situation like that the harware safty system over rides any computer instruction.

But I could go on and on..the point dear lady. There are chip manufactors all over the world. And you most certainly do not have an exhaustive list of them... (Cherri) I do have the resources of contacting most of the manufacturers, throughout the world, at least those that trade in the United States. I admit I do not have the ability to understand the companies in countries such as Russa or others that use other languages. There are a finite number of manufacturers and resources available to reach them.

And there is secondary clocks embeded in a whole lot more of a percentage of the billions of chips than you are trying to make people believe.

There is no such thing as a secondary clock, that is an urban legend made up by a person for his own reasons and has been debunked even by people who fear the worse from Y2K.

Who is Nr. Chicken little?

-- Cherri (sams@brigadoon.com), July 30, 1999.

Linkmeister, That was written in a vein of potential problems and non detailed examples. Most is speculation and others, such as the "embedded chips" in the cockpit of a 777 are said without explaination of what and where they are. The 777 has hundreds of "fuses" and resetable light switches , each of which have a riny basic chip and small amout of eoectronics in them. They have absolutly no year impact, much less possible cause of failure of any system on the aircraft. as a matter of fact they have the advantage to have a backup light if the main bulb burns out. Just a little safty measure. So it sounds omonous (sp) but is simple and harmless.

-- Cherri (sams@brigadoon.com), July 30, 1999.

I'm going to have to get some sleep, but here's a snip from a thread with links to some sites for further research:

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0013zI

[snip]

Allen-Bradley http://domino.automation.rockwell.com/webstuff/y2k.nsf Of their 199 listed date sensitive items they listed, 89 (or 45%) need to be fixed or replaced.

Texas Instruments http://www.ti.com/corp/docs/year2000/dspsds.htm Of their 121 listed date sensitive chips, 37 (or 30%) are not compliant.

Motorola http://mot-sps.com/y2k/realtimeclocks.html They only list their non compliant chips totaling 72. I guess if it's not on their "Black status" list, your ok.

[snip]

-- Linkmeister (link@librarian.edu), July 30, 1999.

Excuse me Cherri,

Y2K IS a management problem.

Whether you want to call it a date problem or not is immaterial.

The people who have already died in these explosions will not come back to life because we relabel the problem.

-- nothere nothere (notherethere@hotmail.com), July 30, 1999.

Cherri:

My two cents worth, for what it is worth.

As a non-tech who just wants it "all to work ok", it doesn't matter to me whether a chip failure or control system failure comes from the chip itself or from software. It's still broke, with results ranging from annoying to catastrophic.

However, that said, and having placed controls engineers, in what way is trying to remediate custom coding any better than dealing with mass produced chips? At least with the chips, as in the Allen Bradley an Texas Instruments illustrations above, you can look up a darn model number.

With software, some Electrical Engineer who left 6 years ago may have inserted a "favorite" piece of coding into a control system that he carries around with him from job to job. Is it compliant? Is there source code? Can you track him down to find out?

I don't know, but I'm not reassured. Thanks for the careful definition of the real area of potential trouble, though.

-- Jon Williamson (jwilliamson003@sprintmail.com), July 30, 1999.

Funny that no one has yet even mentioned the still ongoing problem at Amerada Hess. How come?

-- George (jvilches@sminter.com.ar), July 30, 1999.

Cherri,

Whih ALL due respect...Go to www.embedded-science.com and download the 5+ MB Pdf file Instruction Manual for the DELTA T PROBE. It is an Eye opening course (VERY readable) on embeddeds.

By the way, failure rates for these systems are in the 25-40% range. It really is

ALL going away in January!!!

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

My Dear Miz, Cheri

I found your reply to me to be interesting, to say the least.Can it be, you don't think I would know the difference between analog and digital system and where the one begins and the other picks up in a sub system?

Let's take one you ca check on if you wish...the time 75/76...location Huntington Canyon Power house...Huntington, Utah.. The event! The turbine had been down for a 24 hour inspection, and then brought up to 80% od sync speed (sat out put of 9,000 volts) the misshap... The operator checked the switch ard to see if there was any voltage in it...It read to have none. He then begin the proceedure to cut the turbine into the lines leading to the switch yard..The analog/digital controls failed and allowed him to close the switch...There was in reality 13,800 volts in the switch yard. The higher voltage of course came back in...stopped the turbine and then spun it in reverse (we call it motoring) causing the hydrogen colant envelope to be broken...an explosion of unbelieveable power then occured...I remember as if it where yeaterday, the dog and pony show that was put on for all the big shots from just about eey major utility in the United States as they came down to see what had happened...for by all reason it could not have happened! But it did!!!

Your reference to Andover broght back memories o the Cotton Wood mall in Albq. N.M. It has an Andover conteoll system installed on it's air conditioning systems...quite an elaborate set up...It does indeed have a central pc...But it also has a huge numer of PLC's also...Ask me why, then go check, each store is setup with it's own programmable temp/billing/time usage etc and all can be called from a remote location to find out temp/billing/to regulate the temp/time running ect...

Just an old shirt tailed electrican...But I spent on devil of a lot of time learning my trade lady

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

-- Shakey (in_a_buner@forty.feet), July 30, 1999.

OK Cherri,

I guess we agree on what an "embedded system is? I'm no ES expert, but I have been playing with all kinds of DIGITAL computers for the past 3 decades or so, esp.with ASSEMBLY language. So, I guess I've got a few more "minor" points:

"The main reason for this is that it takes up a lot of memory to write the booleen algebraic equations for seconds up to years, leaving little room left to program the chip for the desired function you attempting to accomplish."

Come on now Cherri, what does it take to "count and compare?" Let's make it easy, and assume that we have a "clock" that generates an interrupt every second. Do you think the following (x86) code would work, to update seconds, then minutes?:

WAIT: NOP ; wait for interrupt

INC SECONDS

CMP SECONDS,59

JL WAIT

MOV SECONDS,0

INC MINUTES

CMP MINUTES,59

JL WAIT

; DO THE SAME FOR HOURS, DAYS, MONTH AND YEARS!!!!!

This only generates a few bytes of program code, next to nothing, hardly a dent in the space available on the ROM. Next point:

"To provide accurate date-time you need a source that would keep "time" in a reliable way otherwise the function would be moot. That means the "black box would also have to contain a RTC, BIOS and a Battery, as well as an external source of power."

First, we don't need a RTC since the above code EMULATES a RTC.

Second, the BIOS is OUR PROGRAM that is contained in the ROM. We are the BIOS.

Now, lets talk about the battery, and the external power. I'm in a bit of a rush, and don't have time to locate the link in the archive. We had a post about a SOLAR POWERED WATCH, that was placed in a dark drawer for 30 days, and it kept perfect time. It had NO BATTERY. but a CAPACITOR was charged by the TINY solor array, that kept the watch powered in the dark. Yes, a capacitor is just like a battery, it stores juice. A capacitor is a very common component, maybe more common than a "chip."

So what do we have in the "guts" of the watch? A very tiny DIGITAL circuit, that takes a TINY amount of power to keep it running, and it is VERY accurate. Do any "embedded systems" use such a clock? I don't know, I'm not the expert. I sure can't think of a reason why not. Next point:

"The black box if totally independant of an external computer would have to had the time and date set upon initialization. In my research with semiconductor manufacturers, I have found that they do not do this at the factory for many logical reasons."

Another, less common component is NON-VOLATILE RAM. This is a special kind of RAM that remembers it's contents when power is lost (maybe we can't keep the watch in the drawer for 60 days...). When power is restored, it picks up where it left off. This is important when "sequencing of transactions" is important. Do any "embedded systems" use NV-RAM? Somebody sure does, but I'm no expert..

This is what our old friend, BRUCE BEACH is about. Is he an "expert?"

Any comments, Cherri? <)=

-- Sysman (y2kboard@yahoo.com), July 30, 1999.

The above should have read:

Do any "embedded systems" use NV-RAM for timer or "clock" storage.

Are you out there, Cherri? <:)=

-- Sysman (y2kboard@yahoo.com), July 31, 1999.

Sysman, yep but I'm getting ready to take a nap.

-- Cherri (sams@brigadoon.com), July 31, 1999.

Can't blame ya for the nap Cherri, going to do the same, this heat and no rain sucks...

Maybe one of our other "pollys" would like to discuss this. Flint, you're a "chip" guy? Hoff maybe, or are you stuck on "aviation?" Doomers@suck.com?

Come on folks, this is the start of my reply to BRUCE BEACH. Am I nuts? Is Mr. Beach nuts? Is Cherri nuts?

Or is it all hype??? <:)=

-- Sysman (y2kboard@yahoo.com), August 01, 1999.

Sysman:

OK, I'll do my best. I've written a lot of this before, you know.

(1) Your example is correct, it's quite possible to keep track of time without some RTC function. Indeed, most low-level embedded programs do just that for a variety of purposes. Far fewer of them keep track of real, calendar time (synchronized to the outside world) since there is rarely any need to do this. Those that do generally require some method of resynching, since those crystals aren't all *that* accurate. An RTC itself passes muster if it gains or loses less than about 2 minutes a day. But that's a day off every 2 years, so some outside update function is required if the time needs to be synched with real time. And if such a sync function isn't required, then it isn't real time after all, it's just a timer.

(2) Your example is fine, I've done this myself. But you will notice that there is no y2k error in it! Typically, to introduce such an error your code must store time values as binary coded decimal (why?), then allocate a single byte for each field (normal enough), then initialize all these values to real time (implying some method of setting the time, required as discussed above), then ignore overflow of the year byte, then create code that assumes that such overflow can't happen! Finally, when overflow does happen and is mishandled, the device needs to misbehave in some way that seriously compromises the application it's used in.

Now a couple of observations here. To find embedded systems where all of these things are true, you must eliminate all but a very small handful of systems. Very small. The vast majority of embedded systems don't keep track of real, calendar time at all, since there's no reason to. They use simple timers.

Of those systems that *do* something with the date, as opposed to just keeping track of it, this functionality is rarely burned into the microcontroller or other ROM space. That would be the wrong logical level in almost all remaining cases (which was a small total number to begin with). This is NOT to say that improper function due to date mishandling isn't part of the "system", it just happens at a higher level.

(3) Most of the misunderstanding about the dangers posed by embedded systems are based on one or two sources of confusion. First, people tend to equate what is *possible* (as in your example) with what is actually *done*. This is a simple error to make. As I said, it's a rare system that keeps track of calendar time at all.

Second, there is a real problem defining an "embedded system" at all. These tend to be layered as used in sensitive applications (I'm not talking about your VCR here). As an example, think of an ABS braking "system". Each wheel has a wheel control "system" (consisting of sensors, servo mechanisms, a microcontroller, etc.) That's an embedded "system". Now, each wheel system reports to a vehicle-level braking system that 'knows' about each wheel. At this level, we find logic to prevent swerving due to differential friction coefficients at different wheels. This system in turn reports to a subsystem that, for example, handles wheel control generally -- braking, differential, alignment, whatever. Finally, this subsystem reports to a master system that handles all aspects of the vehicle. And perhaps you could throw in the diagnostic system used by the mechanic to query and update each vehicle's system.

The purpose of this example is to emphasize that in most important cases, there really isn't any good place to draw a line and say, *this* embedded system is everything within *this* circle. As the circle becomes larger, of course the number of actual chips within it grows. At the chip level, y2k bugs are vanishingly rare. At the highest levels (the "assembly line system", for example), you are talking not only about millions of chips, but about networks of servers running custom applications handling thousands of tasks being performed by tens of thousands of pieces of machinery.

At this "highest" level, it's not at all surprising to find 30-40% of "systems" have y2k issues. But people confuse the incidence of issues at this level with the incidence at lower levels, so I've seen people claiming that 30-40% of "embedded chips" have y2k errors, and there are 50 billion chips! This is a logical and semantic problem, NOT an accurate assessment of what we're facing.

As a footnote, there was a thread not long ago asking me to respond to Cory's challenge. In that thread, I spent some time explaining why embedded errors are less "contagious" than IT errors. I won't repeat that here, but it's another aspect of this same issue.

-- Flint (flintc@mindspring.com), August 01, 1999.

Flint, Thanks for explaining it as you did (I am NOT good at explanations>. As for the crystal ascillator, there is usually a capacitive/reactive , well a cap and a coil that is used to refine the frequency to a tighter standard. But as you say, it is difficult to make the crystal exactly as you need it. In larger systems (Yes mainframes - my first experience with a RTC) there is more physical space to put the hardware that can keep the ctystal more accurate. Thank you for helping to explain that there are not chips out there with "hidden" (unknown) clocks (as in hour/day/year) that will fail because they were put in systems that did not "use" the clock but it would keep time anyway and fail on the roll-over, or sometime after because it was started (again unknowingly) when put into some system. Such as a washing machine.

The distinction between an "embedded chip" and an "embedded system" is something I have been trying to show people for over a year now.

A lot of the examples that people are giving of "embedded system" problems comes down to the software running through the system, in the form of a program as apposed to what is "burned into" a programmable device. Yes these problems exist and yes they must be be found and fixed. But it is important for people to understand that every electro-mechanical or even every digital device does not have to be physically tested.

I know without even looking at my table lamp that it does not and will not have a Y2K failure. If there is a power failure at my local utility and the lamp does not work, it is still not the fault of the lamp- it is the fault (lack of power) from the utility. Just as it is not the fault of a chip if the software going through it functions in a way to cause a Y2K error or failure, the fault origionates at the source of the software-the program.

Bruce Beach does NOT know what he is talking about.

One thing that scares people who do not know about "chips" is if they see a diagram or pinout and see the CLK pin. They assume it has to do with time and date. They do not understand that it is what "steps" the bits (voltage) through the chip.

-- Cherri (sams@brigadoon.com), August 05, 1999.

Wow, what an educational thread. Brain-ache central calling :)

It occurs to me, as we get further and further into this issue, that a minor contribution from my un-technical self may assist in illuminating a little "big-picture" perspective to this debate, particularly as it applies to the layman.

On late-night TV the other night, (which over here consists of educational programming, mostly output from the Open University), a documentary was running for a post-graduate technology course. The programme was dealing with certain issues involved in the integration of technology into real life scenarios. It was particularly interesting when viewed by someone with a degree of Y2K interest, although the topic was not touched on directly. A few of the statements by some of the egg-head experts did give me pause for Y2K related thought though.

Principally, the part which caught my eye was a technical discussion of the safety, accuracy and fallability of computer programmes when applied to life-critical applications in the real world. Principally, the discussion dealt with the issue of software, but the general message seems to be appliccable to hardware concepts also.

An example was given of a piece of medical equipment, namely a 3 part multi-purpose scanning device, incorporating a low-intensity electron- beam scanner, coupled with an X-Ray device, and a light-sensitive scanner. The software was written so that a patient could be located on the scanning table and positioned accurately using the light- scanner (which uses no accelerator beam and is therefore 100% safe)> The software was then designed to rotate the patient on a turntable, to place them accurately in front of the low-intensity electron scanner, where they received a scan. Finally, the turntable was moved again and the patient would be X-Rayed. Take into account that the X- Ray device is the most dangerous, as it uses high-intensity accelerated beams, and if used wrongly can harm the patient.

Despite extensive logical testing in the lab, the software proved glitchy. In some cases it wrongly positioned the patient in front of the wrong device, and then sent the intensity setting to that device based on where it *thought* the patient was, and not where they *really* were. This led to some patients receiving an electron scan at X-Ray intensity. This is a BAD idea. The system was decommissioned and the software re-written. There were other examples.

Commenting on this, an eminent professor from the OU stated that . .

{quoting loosely) "Computer systems are rarely, if ever allowed to operate without a practical level of human participation and intervention. Where such systems ARE permitted, their function tends to be deemed non-critical to life-supporting processes. In most cases of computer related failure leading to injury or loss of life, the fault can be traced to a degree of human error in the supervision or intervention in the process" {this kind-of echoes what Cherri was saying about people not bothering to check mechanical valves etc)

Basically, the concept being that people should not "trust" computer systems to perform perfectly every time. Thats not the way they are designed, and few designers or engineers would attempt to claim a 0% failure rate for ANY system. The prof actually went on to state that . .

"In any computer software program or application developed nowadays using modern, complex programming languages, it is generally accepted as an engineering principle that some kind of informational error will occur within the data at least once in every 200 instructions."

The point being that this kind of error rate is absolutely acceptable, because systems are designed to incorporate a degree of tolerance of inevitable minor errors. Furthermore, it underlines the fact that all modern systems are designed with just this kind of tolerance in mind. This explains the need for human participation in computerised processes. Even the engineers and designers know that nothing is ever 100% perfect.

This all sounds like support for the position that Y2K errors have the power to destroy the systems we use and benefit from today, but in fact it's just the reverse.

Bearing in mind that most, if not all computerised processes operate with a "1 in 200 instruction" error rate tolerance (or worse), how can we argue logically that one more source of data error could cause irrevocable failure ? If computerised systems are designed to be checked, monitored, and maintained by human beings NOW, that suggests to me that most if not all Y2K-based errors should fall within the remit of this safety sequence, and it is only in circumstances where the human factor has been irresponsibly removed from the process that we face a real risk to the continuity of service. This kind of in- built lack of the security of human intervention it seems would, in the industry's own rule book, represent the unneccesary imposition of an irresponsible risk.

Bizarre isnt it, that information pertaining to the inevitable and inherent imperfections, fallabilities and unpredictabilities of complex computer systems can actually make you feel SAFER.

I hope all this was in some way relevant.

Kindest Regards

W

-- W0lv3r1n3 (W0lv3r1n3@yahoo.com), August 05, 1999.

Wolfe, You nailed it exactly!

" Bizarre isnt it, that information pertaining to the inevitable and inherent imperfections, fallabilities and unpredictabilities of complex computer systems can actually make you feel SAFER." I hope all this was in some way relevant. 20 years ago while working at the Lazy B, they were developing the 757 and 767. They were adding a lot of digital equipment. I literally had a vocal tissy fit asking how they could allow such unreliable devices (those containing chips) to have control over something as important as flight. Knowing first hand and with decades of hands on experience that some "IC's (not even embedded ones) can fail from a stray bit of static electricity. It was explained to me and shown to me, physically, that the only digitally computerized systems were there as a convienence, to help piloting the aircraft easier, and would in no way replace the physical harware and instrumenttion that ran and flew the aircraft. Just over a year ago I joined Peter DeJagars mail-list and there was a lot of speculation about aircraft falling out of the sky. IKnowing exactly how they fly and what equipment does what, I jumped in and stated that they would not, could not and will not fail due to Y2K. There was a lot of discussion from a lot of different people giving opinions and what if scenerio's, all of which I answered with facts. I contacted a few "old friends" (I no longer work there) and got the word to them about the speculatation. I was not allowed to say anything about what tests were done or where they were in double-checking for Y2K butapon verifying what I knew, posted this: I am stating that no Boeing Aircraft will have problems due to Y2K. A few months later Boeing and the FAA made public Statements Stating the same thing. The point I am trying to make is the one you wrote so well :o) That although the digital age is great for information technology, it does not replace physical harware that we have depended on for centuries. Water works depend on valves, pressure and physical hardware. Electricity depends on the physical generation of power, voltage regulation, high voltage transformation to lower voltages until it gets to the transformer that feeds your house at the correct voltage and frequency. Power plants use harware to generate electricity, but from basic common sense they will not depend on digital computing for more than superficial uses much the same as an aircraft. Timestamping, measurement tracking, usage tracking etc can all be done by dgital computers, but are not necessary to produce the electricity itself. Or for more than a user friendly way to monitor safety and running the plant. The workers can sit and look at computer screen and monitor the equipment. That is convenienct. But the same equipment that they are monitoring is still monitored by the physical-hardware guages that have always been used. So if the computer monitoring is unavailable, the workers just do what they have always done (before the computer) and walk over and look at the guages etc. NOTHING safety wise is left strictly to computers. That is why nuclear power plants systems fail in the safety positions. The equipment runs with the safety "interlocks" held in the energised position (it takes power to keep them in that position) so if there is a power failure the voltage loss causes the interlocks to de-energise and close (in the safty position). You are correct in realising that because of the nature of digital computing (and embedded systems) of its tendency for failure, that critical functions are never left strictly to their use.

Unfortunatly, as has been seen in the fuel pipeline failures reciently, people are becoming complacent and less responcible when it comes to the physical hardware. What goal does someone in highschool have for their future these days? Computing. How many highschool students are encouraged to go into the fields of physical mechanics and hardware? not many. How many people want to take the time and use the mental work it takes to learn these (once common) things? Not many, it is easier to take some cources in "information technology" and make big bucks playing with pre-written programs. They don't know "how" the software works, nor do they care. If the teacher in this field and schools teaching it were so "brilliant" then why did NONE of them realise the potential for the Y2K problem? Because it does not take much thinking to be an IT. They are not brilliant. Hell even Bill Gates is rather dumb. Lucky, but dumb. He had motion etectors put in his "computerized mansion" to turn the lights off and on, so what happened? Heh Heh. Every time he turned over in bed the lights came on. DUH~~ The glut in IT and the falacy of the talent it takes to be one is now being exposed. Who was origionally called in for Y2K remediation? IT's. Guess what? After they went through their little routine (learned in college) on how to "milk" a job for all the money and time they could get away with, they had to turn to the people who did the real work in Information technology, the programmers. Big business learns real fast, especially where the bottom line is concerned. They also communicate with each other. They learned that their people in-house, who knew their systems, were the ones they needed to use to fix their Y2K problems. And what were many of those Y2K problems they needed to fix? Except for legacy systems, the problems that had to be fixed were those systems put in place by the "so called brilliant" IT's they had hired in the last 10 or so years to work for them. There was absolutly no reason for any of those Y2K problems to exist in the equipment and systems put into place in the last 10 years. Micro-doft and Silicon Vally are responsible for producing COTS that were non Y2K compliant simply because, although they could write all kinds of nifty doftware, they lacked the basic understanding of "how" it actually worked physically on the machines. They did not have the knowledge to "see" the problems they were creating. The days of "recient college graduates" walking out and making a fortune is over. They have been exposed for what they really are. They have cost the businesses and governments of the world so much money and problems beause of Y2K that they will never again be accepted without proving themselfs. Who will be the big money makers - job wise in the next century? Those who have the talant and training and brains it takes to run those things that no one wants to learn today. The people who understand and know what to look for in water work valves and flow systems, Those who know how to operate, troubles shoot and repair harware systems in the physical infrastructure. Compare today with 20 years ago. How many people in their teens and twenty's know how to fix a simple thing in their cars engine? How many even have the basic understanding of the way a car works? How many people in that age group know what a circular saw is, much less could use one? Do they know how to prevent the kickback ? How many would loose their hands or legs if they had to use one today? How many teens or those in their twenties know where the starter is located in their car, much less how easy (and cheap) it is to replace one? A lot of peope see the split between those in the "high technology (and pay) fields and those who do not understand or use computing? The posibilities in computing are infinate, in information technology are finite. It will be those who know the physical sciences as well as computing that have the future open to them. Gee, I went on a tangent on this post didn't I *grin*.

-- Cherri (sams@brigadoon.com), August 06, 1999.

Cherri, your comment on Dr. Gordon in a newer thread piqued my curriosity, i.e. that she didn't know anything about embedded systems. You sure seem to have experience in that department, but wether you understand the nature of Y2K in general is another matter.

Wolf said: "Bizarre isnt it, that information pertaining to the inevitable and inherent imperfections, fallabilities and unpredictabilities of complex computer systems can actually make you feel SAFER."

Wolf, I assume you have as much background as I do on embeddeds, that is, not much. But this quote above and your conclusion is simply not logic to me.

"Bearing in mind that most, if not all computerised processes operate with a "1 in 200 instruction" error rate tolerance (or worse), how can we argue logically that one more source of data error could cause irrevocable failure ? If computerised systems are designed to be checked, monitored, and maintained by human beings NOW, that suggests to me that most if not all Y2K-based errors should fall within the remit of this safety sequence, and it is only in circumstances where the human factor has been irresponsibly removed from the process that we face a real risk to the continuity of service."

First, take into account the sheer number of embedded systems and apparatus that use them. Off the top of my head, I would say that there just aren't enough people to monitor them all. Not even enough people to monitor a large number of them at once in one location.

So, we're now back to that question, which systems will fail, and which won't. We know that many systems have failed already, some due to Y2K, some that we don't know for sure but certainly look suspicious, such as the recent explosion in numbers in the refinery/plant explosions. The bell curve starts spiking around April of this year.

Some systems will fail while being monitored by people, other systems will fail while not being monitored. Each system, wether being monitored or not, will cause a disruption. Those being monitored (as in your example of your x-ray scanner) can recieve quick attention and hopefully minimize damages. Those not being monitored have the potential to cause even more serious damage until they are seen as having failed. If you keep in mind the window of time that systems are expected to fail due to Y2K, an increasing strain is placed on the people responsible to monitor and fix them, and the "collateral damage" increases.

10 people dead at this plant explosion, 3 patients dead at this hospital, one subway train wreck here, one air traffic accident there. So far, that's the routine we read and see on the tube. No big deal, it's not you or me, and we've got one huge population.

But think in terms of bell curve and Infomagic's Charlotte's Web and devolutionary spiral. One so-called embbeded system "expert", or even 2 or 3, cannot convince me that embedded systems aren't the problem. Even if a smaller percentage of y2k problems than Cherri claims there is were to happen, it is still too many, because our qualified workers who are curently dealing with these systems are not equipped to handle more failures than they already are in a relatively short period of time, and the people responsible to clean up the messes aren't either.

I don't feel safer one iota knowing that failures that happen now are expected and are being handled, that has nothing to do with the nature of Y2K.

-- Chris (%$^&^@pond.com), September 04, 1999.