An interesting discussion on chemical plant embeddeds.

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

G Moore wrote:

> On Thu, 25 Nov 1999 02:45:43 GMT, Ralph Daugherty < ralph@ee.net > wrote:

> > But every time you post that the software industry doesn't care, I will post that there are some embedded systems with software that will generate a 3 character string for the year that was unanticipated by the programmer. That in other words: there is some memory 1231990XXXXX the 0 represents the null terminator when 1 is added to 99, it becomes 0101001XXXXX because the operation was never expected to hit 0 now, you come along and do a string copy (not a memory copy), which was supposed to find that 0, the copied data gets trashed.

so you have three conditions:

a) string copy
b) addition must overflow to the next memory location
c)the date chip and data must not be found by a programmer

extra character will overwrite the string output buffer null terminator if the buffer is defined to the exact length, and a subsequent string copy operation will trash anything beyond the destination.

which sort of makes me have to ask... how many of these problems have you found, and how many are theoretical constructs found in the y2k faq?

Hi G Moore,

I have no source code to an embedded system. I have no direct knowledge of an impending embedded system failure. I know of no embedded system that would have failed had it not been fixed. I don't have any URL's, no figures, no proof. What I'm saying here is unbridled speculation. If pollies don't like it, they can kiss my ass. They'll be kissing their own good-bye soon enough.

The scenario that I contend will happen in enough places to cause a Bhopal, that is, several thousand deaths caused by a system gone haywire releasing toxic substances, is this:

- a very large number of control systems are written in C
- they keep track of elapsed time by counting ticks, they don't use the date for that
- a large number care nothing about the date at all
- but a sizeable number of control systems written in C will generate a time stamp that includes the year
- C programmers primarily access the year from a field that goes from 99 in 1999 to 100 in the year 2000
- very few of these were programmmed to handle the year by adding 1900 to it and treating the year consistently as a 4 digit number.
- whether a 19 was prefixed to the year or not is irrelevant
- the programmer has a buffer in the program to assemble the time stamp which includes the year
- the buffer is a certain size and is almost always followed by a null termination character. If the character following the buffer is not a null, it is still likely to be data important to the program.
- a significant percentage of these buffers will be defined as the exact length needed to hold the time stamp, perhaps 30% or 40% of those C programs generating a time stamp.
- that length will be enough to hold a 2 digit year. The C programmers neither added 1900 to the year and allocated 4 positions for the year, nor did they the allocate a third growth position to hold and display a year value of 100. They just stored and displayed the 2 digit year that was generated pre-2000. That's the way most programmers wrote code.
- in those programs with an exact length buffer, either the null terminator or the first byte of data following the buffer will be overwritten with the rightmost 0 of 100.
- the C programs will then copy a buffer containing the year elsewhere. If the null was used as an end marker, it is no longer there to stop the transfer of data. If a count was used and no null terminates the buffer, significant data following the buffer has been overwritten instead.
- in either case, some number of programs will thrash wildly as cascading failures quickly crash it, with the potential for significant harm to occur as the program executes randomly
- the number of programs that crash in this manner and release toxic substances is exceedingly small

How many Bhopals does it take to start a multi-year inquiry into just why there was zero concern in the embedded systems industry about Y2K? One Bhopal may be shrugged off, two Bhopals and all hell is going to break loose.

Ralph

-- Ed (ed@lizzardranch.com), December 25, 1999

Answers

Sure would liked to have seen this posted a few months ago when the other programmers could have joined the fray. Just don't have time left to break it down and noodle out the flaws(if any). A couple more 5 gal. jerry jugs and I'm through. Any C programmers out there to respond?

-- Blew5M (gaf@mindspring.com), December 25, 1999.

I have no source code to an embedded system. I have no direct knowledge of an impending embedded system failure. I know of no embedded system that would have failed had it not been fixed. I don't have any URL's, no figures, no proof. What I'm saying here is unbridled speculation.

Ralph, is an idiot.

-- Cherri (sams@brigadoon.com), December 25, 1999.


Cherri, it takes one to know one. LOL

-- Yuk Yuk (thatsyoucherri@airhead.com), December 25, 1999.

Cherri, you are an utter fool.

-- cody (cody@y2ksurvive.com), December 25, 1999.

Bottom line - refineries already are experiencing between a 1-5% failure rate of embedded that they can *find* and more importantly ***access***.

The rest can't be touched because it would mean shutting down the refinery followed by a lenghthy and costly start-up...

So the bean counters in all industries in all parts of the world have adopted a FOF (fix on failure) ostrich mode...

I prefer to call it now FON - Fix On Necessity.

When the merde hits the fan there will not be enough trained experts to go in, locate, fix or replace the chips... the VENDORS of the chips will be the weak link

The Vendors need to be on the ball and up and running and not hit themselves by y2k bugs.

Cheeri you are a complete imbecile. Merry Xmas.

-- Andy (2000EOD@prodigy.net), December 25, 1999.



Hey Andy, BTW, what vendor? Some of them ain't around anymore. Some of them aren't gonna be around if you catch my drift. If there is hell to pay, they don't wanna get stuck with the check. I know you get this.

Ralph hits on one potential scenario which to this lay person seems feasible in theory, but the reality is there will be hundreds of scenarios. We can't get to all the chips (the mantra of the embeddeds). Shut down is the only safe option for the short term, but it has long term consequences in every industry.

Since we are dancing with the devil here, I would rather chem plants have the imagination needed to grasp scenarios that are plausible, so that they realise that either way they cut it here, there will be unbearable losses.

I want them to realize that they ARE choosing between potential Bhopal near rollover verses longterm lives that are irreparably harmed due to a closing. This is the reality of the choice today, because there is no time now to orchestrate a third option.

-- Hokie (nn@va.com), December 25, 1999.


Yuk Yuk and Cody,

You folks are jerks. There will be embedded chip failures. People will die if they are located in critical places. It is just that plain and simple.

-- the Virginian (1@1.com), December 25, 1999.


Yup Hokie many Vendors are no more - bankrupt, gone. The north sea oil platoforms were built 20 odd years ago and are full of embedded chips. I wondor how many Vendors are still around from 20 years ago.

-- Andy (2000EOD@prodigy.net), December 25, 1999.

Virginian,

I believe Cody and Yuk agree that the imbedded chip problem is serious.

Sincerely,

-- Uhhmm... (JFCP81A@aol.com), December 26, 1999.


I think the embedded chip problem is not just serious; I think it's deadly.

-- cody (cody@y2ksurvive.com), December 26, 1999.


Moderation questions? read the FAQ