Sampling of embeddeds in the oil industry

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

To all:

Laura (Ladylogic) interviewed a spokesperson (see her OIL & MILLENNIUM GROUP MEETING thread below) for the oil and gas industry who admitted that they're sampling from embeddeds that have the same model number and manufacturer. This carries with it the obvious assumption that they would all be the same in all material respects, so there would be no point in testing them all.

I recall reading something that refutes this idea, but I can't remember where. Can anyone provide me with a link?

Thanks,

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

Answers

eve

Perhaps Brian or Diane can help.

I picked up on this statement the moment he said it, but Laura already had him moving toward a defensive posture and I didn't want to look like a bully.

A number of papers written on embeddeds have stated that you could not be assured that if one chip was good or bad then all others made at the same time and place and doing the same job would be identical.

-- rb (ronbanks_2000@yahoo.com), November 19, 1999.


There was one instance, and it was with RTC's where the same chip "model" was made differently by different manufacturers. That was the only case and that was a few years back. Chips by different manufacturers with the same part numer are the same, nothing else would be accepted by the industry. We have cross reference books for replacement parts by different manufacturers of the same device. So testing of one of a certain device is a good as testing all of them.

Embedded chips thaT ARE MADE TO SPECIFIC SPECIFICATIONS for different industries, such as a medical device, are given an individual part number and all of them are made the same. The idea of having chips from different manufacturers act differently was strictly specualtion by a person or persons who had no actual knowledge of the subject.

-- Cherri (sams@brigadoon.com), November 19, 1999.


I don't have a reference handy, but the issue here is the reliability of so-called "type testing", where you assume that a component that passes the test lets you off the hook for having to test other "identical" components. Unfortunately, due to the differences in the chips used in the component, the reality is that there may not be other identical components. You don't know until each and every one is tested. Which takes up more time than there is until 2000.

This makes sense when you consider that chips are provided to meet specifications that are required. If Y2K compliance was not specified, a non-compliant chip that will otherwise work just fine for the stated specs may be supplied along with compliant chips. Again, you can't be sure until you test. Which takes too much time. Yada-yada-yada.

-- King of Spain (madrid@aol.cum), November 19, 1999.

Ken Evans, President of the Arizona Farm Bureau, testified before the Senate 200 committee in Jan. or Feb. He recounted that in testing his irrigation equipment, he discovered that 2 or 3 out of 6 (I believe) of the boxes for his pivot wheels were non-compliant. These were of the same model and maufacture and of consecutive numbers in sequence of manufacture, as I recall. They "blew up" when they were tested. It displayed that type testing may be invalid. You may be able to get his testimony off the Senate site. It was the same hearing where Glickman testified.

-- marsh (armstrng@sisqtel.net), November 19, 1999.

Cherri,

Thanks for your input. But the source I recall reading gave specific reasons as to why sampling in the situation I gave is insufficient. I do recall that the rationale made sense to me at the time, but that's all I remember about it.

King of Spain,

Thanks, King (may I call you King?). I'm a little confused here, though. In your first paragraph you're talking about testing components where the chip is in the component. I'm just talking about testing the chip. Aside from this, your post makes sense.

marsh,

You know, I vaguely recall reading this, and being somewhat blown away (if it's possible to be "somewhat" blown away). Thanks so much for the reference; I'm going to try to check this out again.

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



http://www.govexec.com/tech/articles/0199mantech2.htm

[snip]

Manufacturers don't always know precisely what chips they included in a product, and sometimes the chip manufacturer cannot be located to answer inquiries about whether the chip has date-related functions. Some makers of chips and products that use chips aren't responding to queries about Y2K, on advice of their lawyers who are worried about liability. Although a recent federal law reduces this exposure, not everyone believes candor is advisable. Moreover, definitions of Y2K compliance are elastic, despite efforts to make them more precise.

Furthermore, seemingly identical pieces of factory-made equipment can have different versions of the same chip. That means that if a Coast Guard office has five of the same fax machines, for example, testing one of them isn't enough. All five must be tested. More complex machinery tends to have more chips. A single huge crane in a port could have 150 chips, federal Y2K czar John Koskinen told an audience last year. Some organizations reportedly have been pleasantly surprised to find that their embedded-chip problems were less serious than had been feared, but the chips still need to be checked.

[snip]

-- Linkmeister (link@librarian.edu), November 20, 1999.


It all depends on the program.

Here's a non-Y2K example. Many years ago I was involved in the development of a terminal controller. It was a shoe-box size device with an input port connected to a modem, and several output ports that were connected to "dumb" terminals. It's main function was to simulate the polling logic required on a "multi-drop" line. It was far less expensive to have this box and 8 "dumb" terminals, than it was to have 8 "smart" terminals, that each contained their own polling logic.

One day the boss came up with the idea of doing data compression. If you look at a data entry screen, you will see fields like Name, Address, City, etc. The Name field may be 30 characters, allowing for a pretty long name. But a name like John Doe that only takes 8 characters, would be transmitted with 22 following blank characters. Now this was in the days when a 9600 modem cost about the same as a new luxury car! And keep in mind that there may be 15 or 20 terminals all using the same line. Finding a way to decrease the size of a message would have a big impact of performance.

We deceided to use a special character (DC1 if I recall) followed by a binary count of the number of blanks. So the above example would be reduced from 8+22 characters to 8+2, a big difference! We made the changes on the mainframe, and to the program, contained in a ROM, on the controller.

If you looked at 2 "boxes," one with data compression and one without, you would not notice any difference. The hardware was the same. The only thing different was the VERSION of the program contained in the ROM. If you used a non-compression controller on a line that was doing compression, you would get junk.

Hope this helps.

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), November 20, 1999.


Linkmeister,

Your post is interesting, but I was referring to chips from the same manufacturer with the same model number behaving differently. See marsh's post above, which seems to me to come close to a real-life example of this. I appreciate your efforts, though.

Sysman,

Thanks for your response, but I was referring to embeddeds with firmware, not an IT-related software issue.

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


link

-- bn (test@m.mm), November 25, 1999.

eve:

We're dealing with two issues here:

1) Is it possible that the firmware has changed between two otherwise identical devices? Yes, this is possible. The actual firmware version is nearly always (that is, I know of no exceptions but nobody knows everything) marked on the part. So if you open it up and read the fine print, the devices are no longer quite identical. This is quite different from commercial software, which is "slipstreamed" (that is, each new press run of the product has fixes, but the version is the same).

2) Could the code inside the device be different because the device is designed to be field-programmable? This is fairly common. PLC's are programmable logic controllers, and can be (and are) programmed to fit the implementation. But these aren't regarded as "identical" devices, any more than two of the same hard drive would be considered "identical" if they held different contents.

So, is it safe to do type-testing? That depends on what degree of risk you're willing to take. You trade off the probability of a critical difference (extremely small) with the time required to do the test (which could be far better spent on an unknown device), and with the cost of testing (again, better spent on something unknown).

This is one of those cases where, yes, it's *possible* you could be hit by a meteor. It can't ever be ruled out. But the possibility is so small as not to constitute a viable threat.

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



Eve --

I did embedded systems for about 15 years. A 'chip' may have multiple versions of the software. Typically, if the program could be 'optimized' for specific circumstances then there would be multiple versions. These are *not* normally identified by a different part or model number. They are distinguished by a 'version' number. On a typical 'bill of materials' this would be reflected by some identifier appended to the part or model number.

If the versions are the same, then the firmware would be the same, and 'type' testing works. If there is no information on the version, it is possible to take a chip where the program is optimized for one set of circumstances, test it, find that it works, and assume that all others of that model will work, while, in reality, having two or more actual 'versions'. Which might or might not work.

As a disclaimer, I would not expect this to be 'common'. It may happen, but I would not expect massive numbers of problems of this type. As I said above, it might exist where the program gets 'optimized'. This is not a particularly common practice.

-- just another (another@engineer.com), November 25, 1999.


Here are some links to manufacturers of just a small portion of the thousands of different types of embedded devices used in the oil industry:

oil electronics

Keep in mind that for every one of these organizations that has a web page, there are probably ten more that don't.

It's the sheer numbers folks, that's why the "everything's fine" attitude is a farce. It would require nothing short of a miracle for all of these devices to be compliant anytime in our near future.

-- Hawk (flyin@high.again), November 25, 1999.


Moderation questions? read the FAQ