I've been following the speculation about Jim Lord's acquaintance, Mr. CEO, and his reported deep level of concern about unrecognized and unappreciated embedded problems.

I believe it was FactFinder who recently stated something to the effect that many embedded systems were never programmed to include ANY leap year dates, therefore many systems that have been around for a few years have already experienced a leap year failure, and the world didn't end. An exception was an aluminum smelting plant in New Zealand or somewhere that tanked because of a leap year problem. I think it was Rick Cowles who publicized that one. Sorry if I've suggested anything incorrect, FactFinder.

Anyhow, if that's the case, it's somewhat reassuring (admittedly, a mistake of 24 hours is way less than a 100 year mistake, but it would nevertheless lead to a monumental mathematical mistake for any vulnerable system).

Anyone have an opinion about this comparison between leap year problems and century problems? And is it true that many embeddeds don't recognize Feb. 29 for any year?

-- Bill Byars (billbyars@softwaresmith.com), December 01, 1999

Answers

> Yes it is true that many embeddeds do not see Feb. 29 for any year.

> As for comparision of leap year and century problems > the following link > > http://www.dalsemi.com/DocControl/PDFs/app31.pdf > > describes the coding sequence in a pseudo language for date time > calcs. that use a binary input. > > After reading this pdf a conclusion can be made:

> It all depends upon "who wrote the code" that went into a chip; > AND IF the person really understood how to implement correctly. > > In 29 days all the y2k questions become moot.

-- Art Soukup (asoukup@mscomputers.net), December 01, 1999.

Bill:

You raise the issue of the definition of an embedded system again. As I recall, the bad code at those smelting plants was in an application, on disk, and not embedded in any device. Reports were that the bug itself was repaired within hours. At best that was what Gartner called a large-scale embedded system.

However, it does show that leap year processing can be critical. And not all programs are old enough to have experienced a leap year yet. And some organizations suffered in 1980 and 1990 when programs written to use a *1-digit year* tanked. There are precedents.

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

Flint, don't minimize the accident at the smelter. Yes, it was the bug on disk. The smelter is just now approaching full operation again --- 2 years later. It was a catastrophic incident and dang near bankrupted the local economy because of job loss and loss of cash flow. They ended up making up the job loss by hiring the workers as day laborers for the repair crews.

Yes, the bug was corrected within 24 hours but the results linger on.

-- Lobo (atthelair@yahoo.com), December 01, 1999.

Lobo:

This is in fact my main concern with embeddeds. I don't expect most failures to be serious, but those that are have one HELL of a lot of collateral damage. I really do expect explosions, and I can only hope they are confined to facilities (like the smelters) and nothing nasty moves downwind (like Bhopal or Chernobyl). But a few of them are probably in the cards as well. There will be cleanup to do.

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

Lobo, You are not quite correct when you wrote "Yes, it was the bug on disk. The smelter is just now approaching full operation again --- 2 years later. It was a catastrophic incident and dang near bankrupted the local economy because of job loss and loss of cash flow"

The smelter concerned was the Tiwai Point Aluminum Smelter, owned and operated by Camalco, and situated at Bluff, not too many miles from where I'm sitting right now. The fault happened on Feb 29th 1996, and although it was a very serious fault resulting in sever damage to all potlines, the smelter was repaired, and back up to full production within months, and with NO job losses. Far from bankrupting the local economy, the extra work provided for contractors in the area provided a short term economic boost.

However, it is now that very same smelter that is causing the power industry in NZ the biggest concern for Y2K. If the smelter fails on roll-over we could see some very interesting results.

Malcolm

-- Malcolm Taylor (taylorm@es.co.nz), December 01, 1999.

Bill, I think you have quoted me well. The examples I can give for some devices that will continue to be used that do not account for the leap year in some cases are some models of Allen-Bradley PLCs (this is true only in power down mode I believe, don't have time to recheck just now, see Rockwell Automation website), and Westronics digital chart recorders, models DDR-10, 2100, maybe some others. If my memory serves me right (50-50 chance here, lol), the Westronics recorders roll over from 2/28/2000 to 3/1/2000 and have to have the date manually entered if you want the chart paper to display the correct date on 2/29/2000. Same problems occurred in 1996, etc.

Some interesting points here though, Bill, especially with the example that you and Malcom are talking about. And Flint is on to this - we can talk about the normal and typical findings in Y2K, but there is always the possibility of a poorly engineered system as in the NZ smelter plant.

I want to make a point here - Y2k failures that could result in catestrophic consequences (injury to people, damage to equipment) are more than a "date issue", it's an engineering issue. Eventually, computers fail, equipment fails, due to numerous causes. Designing a plant or system than cannot withstand a failure without catestrophic consequences is a pretty damn big error in and of itself, in my opinion. Such a design will show itself SOMEDAY, regardless of y2k... the question is, will Y2K be the intiator? Are there many such systems? I personally expect very few significant problems, but there's little need to speculate now.

Regards,

-- FactFinder (FactFinder@bzn.com), December 02, 1999.

Factfinder:

You make a very good point and a point that has been nagging at me every since I spoke to a very good friend of mine.

My buddy works at a local iron mill and he told me this: If "y2k bug" does shut down the machines, it could put me out of work for a long time. Some of these machines cant be forced to shut down immediately. They need to come down slowly and some cant be completely shut down at all. A quick "turn off" can do alot of physical damage, some may be unrepairable or to expensive to fix.

Just a thought to pass along.

-- Familyman (prepare@home.com), December 02, 1999.

Thanks for the input, all.

-- Bill Byars (billbyars@softwaresmith.com), December 02, 1999.