Oil Industry Register Professional (Chemical) Engineer shares his opiniongreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread |
There is an interesting post on Roleigh Martin's message board.The gentleman has lots of experiance, this is just a snip so check out the rest at the link below.
From: Steve Elwart
Snip
>I am a Register Professional (Chemical) Engineer (3 states) and have
>workedin the Oil Industry since 1972. I've worked in the oil fields as
>a roughneck, a refinery process engineer in 8 oil refineries, corporate
>environmental compliance, and for the last 20 years (obviously some
>overlap in job responsibilities there), in computers and computer
>applications,both for manufacturing computers and network & BackOffice
>applications.For the last 18 months, I have written a technology
>column with an emphasis on Y2K.Snip
>Most manufacturing control systems (not to be confused with embedded
>chips) do not run off of calendar time. They run off of incremental
>time, that is the interval between one action and the next. An example
>would be that a control system scans a point every 2 seconds not "look
>at the point at 09:27:46 December 14, 1999, then again at 09:27:48
>December 14, 1999." The calculations are independent of the calendar.
>The is a big "but". The underlying operating systems may run off of a
>calendar date and may not be compliant. These systems need to be
>replaced. If they are not, yes, there could be problems, but they would
>affect the data collection and "higher level functions" of the system.
>The actual operation of the plant, at the controller level would not be
>affected. I have yet to have someone quote me a manufacturer and system
>model, which will catastrophically crash on 1/1/00. What may happen is
>the assessing of some big environmental or safety fines involved due to
>a lack of record collection or retention.
>
>Will things fail? Probably. Will things blow up because of it?
>Probably not.
-- Brian (imager@home.com), November 08, 1999
Brian,You got it wrong. We DO NOT want to hear this. Things MUST blow up.
-- the Virginian (1@1.com), November 08, 1999.
VirginianListen!!! How is the world going to end if things don't blow up??
Then we would have to wait for entropy, and that takes alot longer. We might as well watch paint dry.
Where do these radicals come from?
-- Brian (imager@home.com), November 08, 1999.
Mind you on a serious note this comment is more sobering. As I understand it, if there is a interruption in gas then the house line should be closed off and only started by someone in the gas industry. If anyone has experiance with this I am sure plenty of folks could benifit by sharing.>3. How vulnerable are the pipelines? > >Having worked in pipelines I know that embedded chips are widely used. >Many times, especially overseas" documentation is very bad and the >location of these sensors are not known. However, at every pumping >station and gas transmission header I have seen, there is a manual >bypass valve. If there is a problem, yes, the pipeline could shutdown >and could cause interruptions down the line. Industrial plants could be >knocked off-line. Homes may lose their gas supply and pilot lights need >to be re-lit by gas company personnel. However, we aren't talking about >ripping out miles of pipeline because of it.
-- Brian (imager@home.com), November 08, 1999.
About what I've said: it's not exactlythe embedded chip/board/sensor/controller, but the whole process.Raw material/goods/information goes in ->
Automated process does something (using information/power/control ckt's/programs/loggers/motor controllers/etc. ->
Automated process sends output to next system, which takes input from first ......
---
The failures are more likely to be in the processor (what he refers to as the computer) than in the actual sensor/embedded chip.
That's bad enough - even if only the usual 2-3% have problems, it only takes one per plant to cause to cauyse an unexpected shutdown.
It only takes one, in the wrong place, to cause a serious malfunction.
And I have seen no evidence of systemic integrated testing in any of the chemical engineering periodicals, paper making, shipping, gas lines, pipiing, or steel fabrication magazines I subscribe to.
I have seen no evidence of overseas infrastructure remediation - in enough areas to avoid troubles.
I have seen no evidence (outside of the privately subscribed EPRI utilities) of systemic database tracking and system-wide remediation of distribution systems.
-- Robert A. Cook, PE (Marietta, GA) (cook.r@csaatl.com), November 08, 1999.
Verrrrrrrrry interesting.This guy took the 6 questions that Gary North asked of DD Reed and supplied his own answers. It is a rebutal to Reed's comments.
That answer to the question of shortages is one that's been seen before: "We won't have a problem if you crazy doomers don't hoard. The real problem is hoarding."
I was wondering when we'd get a spin on Reed's take.
Thanks Brian
-- Rocky (rknolls@hotmail.com), November 08, 1999.
Hey Brian--Was this an actual interview, ala face to face, or a cyberspace exchange. I first smelled something unpleasant but familiar, in this statement ~~>
I have yet to have someone quote me a manufacturer and system >model, which will catastrophically crash on 1/1/00. --
Sound familiar to you? Sends the ol' olfactory to a reminiscent replacement of a cesspool, which could be a clue as to the idenity/credentials of our mystery guest.
During my stay in the patch (oil fields) there were untold numbers of monitoring, safety, polling, controllers, valves, etc. etc. sending realtime data to monitors, operators, emergency response systems etc. etc. Seems to me, meaningful reports would have to have exactly the correct time and date stamp available, for them to be...well... meaningful!
Also, any deviation in the error trapping routines within the system would necessarily STOP the offending process, until the error is flagged, tagged and bagged, analyzed and sanitized, to insure the measure of effect is within fault tolerance parameters of any of the many intended recipients of the data. Wouldn't it? I'm just asking a question here.
Respectfully; Michael
-- Michael (mikeymac@uswest.net), November 08, 1999.
I don't think this is spin. That word implies deliberate concealment of known facts or opinions. If this guy is going to be in the middle of a refinery at rollover, he is confident that whatever failures may happen, they are very unlikely to be dangerous to refinery personnel. If he's really not planning to be there, he's not spinning, he's lying. I believe he is that confident. I don't know if I would be.
-- Bill Byars (billbyars@softwaresmith.com), November 08, 1999.
MichaelActually it is a bit familiar, but there is backup for this position as stated in Gerald Poje's testimony below. Still it is not reassuring
Senate Y2K Committee
Year 2000 Computer Technology Problem
And Chemical Safety IssuesTestimony of Gerald V. Poje, Ph.D.
Snip
Scope of Issues
The Expert Workshop, as well as the research conducted for our report, concluded that the Year 2000 problem is one of major proportions and has the potential for causing disruption of normal operations and maintenance at the nations chemical and petroleum facilities. Compliance activities reported to the Chemical Safety Board to date have not found a single failure (embedded microchips or software) which by itself could cause a catastrophic chemical accident. However, it is unclear what the outcome might be from multiple failures, e.g., multiple control system failures, multiple utility failures, or a combination of multiple utility and control system failures. Surveillance of the industrial sector that handles high hazard chemicals is insufficient to draw detailed conclusions applicable to all localities.
-- Brian (imager@home.com), November 08, 1999.
And if you think this subject is a mess......try SAP, LOL
-- John Galt (jgaltfla@hotmail.com), November 08, 1999.
Hmm. Wouldn't it be interesting to get Steve Elwart and D.D. Reed into a chat session?
-- Dean -- from (almost) Duh Moines (dtmiller@midiowa.net), November 09, 1999.
Brian--Does this count? I think so.
For Educational and life saving purposes only-- snip--
The Institution of Electrical Engineers
The Millennium Problem in Embedded Systems
Embedded Systems Fault Casebook (May 1999)
EXAMPLE NO EG-08
Equipment Type DCS Industry Sector Process PC or Computer based No System Age 8 years Application DCS Control System controlling smelter plant Description of the Problem Rollover to year 2000 System on reboot reverted to incorrect date How was it Identified Power down rollover test What was the Solution Replace battery backup Consequences for the SYSTEM Erroneous Result Consequences of failure to the BUSINESS Loss/corruption of trend data
Went back through some of the very first posts I saved, to ferret out some background for those lurking. While browsing I came across an old post from IEE, refreshed to current site posting and found this..Sorry about the formatting, I'm too tired to change it all for readibility, it's the content that counts.
FUNCTIONALITY CHECKLIST Functionality -
Does the system... Guidelines YES NO Display or print a date or time Visible output of the date is a certain indication of date functionality. A 2 digit year increases the likelihood of failure. Implement a timed control sequence Such timed control sequences may be based on absolute calendar operation, not just on elapsed time. Such systems are at risk of failure. Perform operations on a timed basis Starting or finishing a sequence of action son a date/time based schedule is a certain indication of date dependence. Produce regular reports Any report (stored, printed or displayed) which contains a date indicates date dependence. Calculate time based totals, averages, rates or trends Any calculation that uses an absolute date to calculate something will use some degree of date arithmetic. This places it at risk of failure. Time-stamp its data or use time stamped data Data stored by a system or products physically dated by it, indicates date dependency. Use of time-stamped data from electronic tabs, bar code lookup tables or optical character recognition similarly indicates date dependence. May also be used for expiry dates. Maintain historical records Where a system stores data histories, storage efficiency is often maintained by date/time data vectoring techniques. These use date arithmetic to store only changed data by tagging them with their time of measurement. Display or print data by time sequence Lists of data such as alarms or timed events are often displayed in date order. In order to display such a list, date arithmetic is used. Generate alerts at pre-determined intervals. e.g. calibration. Some systems include monitoring/diagnostic functionality to warn the user when a set running period has elapsed. Although in many cases simple elapsed time indicators can carry out these functions, in some instances a real-time clock/calendar system is used with associated date arithmetic. Request the date on start up Some systems, which contain only a software clock, will request the date when powered on. Know which day of the week it is by date Knowledge of the date (or at least the number of the day in the month) and the day of the week implies that some form of calendar functionality exists. Send date and time information to other systems If other systems remain in synchronism with this one or update their date/time when this one is adjusted, then there is a high probability that date/time synchronisation is being carried out by a data connection. Connect to, or contain, a time-transmission receiver Some systems employ a real-time clock that is synchronised by a radio transmission such as the MSF transmission from Rugby. The MSF transmission carries only a 2 digit year and so assumptions may be made by the user software regarding other digits. Connect to a network providing access to the date Systems connected to some form of local area network may have their real-time clocks set by another system connected to the network. This may not be apparent to the user. Have its date set by a visiting service engineer It is known that some systems contain real-time clocks for engineering purposes (e.g. logging faults). The user may not be aware of these systems because the real-time clock may be set during visits by external maintenance engineers. Require adjustment to allow for daylight saving time Clearly, if the time has to be adjusted in the spring and autumn, a real-time clock must be incorporated. This may also contain the date. Have a command or function allowing the date to be set If the operator, or programming, command sets include a command for setting the date, it is likely that a real-time clock is fitted to the system and may be used by application software.
Yes or no answers to these basic questions give a good indication as to whether it is likely that an item will have date dependencies. A YES answer to any question in the form indicates some measure of date dependency so that further investigation will be required. If the answer to ALL the questions is no, then the likelihood of item concerned having a Year 2000 problem is low and further consideration can be given a low priority.
-- Michael (mikeymac@uswest.net), November 09, 1999.
Bill,You said,
-----------
"I don't think this is spin. That word implies deliberate concealment of known facts or opinions. If this guy is going to be in the middle of a refinery at rollover, he is confident that whatever failures may happen, they are very unlikely to be dangerous to refinery personnel. If he's really not planning to be there, he's not spinning, he's lying. I believe he is that confident. I don't know if I would be."
---------------
Confident? Of what. No one said that the refineries were going to go ballistic. The implication is that they will shut down -- or slow down.
Big difference in danger to the personnel.
-- de (delewis@XOUTinetone.net), November 09, 1999.
BrianHow is this one for you.
The Millennium Problem in Embedded Systems
Embedded Systems Fault Casebook (May 1999)
EXAMPLE NO EG-07
Equipment Type DCS
Industry Sector Oil & Gas
PC or Computer based No
System Age 6 years
Application DCS control system control for petrochemical plant
Description of the Problem Online rollover to Year 2000
How was it Identified During testing. Offsite testing on a testbed was performed with satisfactory results. Upon testing of stations on site, control was no longer possible after the system had rolled over to Year 2000. It was not until this problem was evident on three of the four operating stations was testing aborted.
What was the Solution No known workaround. Plant had to be operated from one station until problem could be rectified
Consequences for the SYSTEM System Stops
Consequences of failure to the BUSINESS Near catastrophic. Limited reliability and operability of plant. Reduced production
http://www.iee.org.uk/2000risk/Casebook/eg-07.htm
Again: Consequences for the SYSTEM System Stops
Consequences of failure to the BUSINESS Near catastrophic. Limited reliability and operability of plant. Reduced production
-- Brooklyn (MSIS@cyberdude.com), November 09, 1999.
Well, it seems we have what appears to be an industry "shill" coming forward or else we have a moron, or both. I know plenty of oil operators, engineers, remediators will be extremely nervous during the rollover period. ANYTIME... ANYTIME there is an oil refinery sudden shutdown, closure, incident safety risks rise. Even a minor problem can have extreme consequences. I'm not saying that it will create explosions but they certainly do happen... Just look at all the refinery fires and explosions. Workers can get killed in those events quite easily.USUALLY... or so it seems (I speak generally here)... if its a human error and not mechanical failure that causes a refinery explosion or catastrophe my relatives have noted that its a human oil engineer at fault...usually one of the stupid ones who should never have been given the degree and who really doesn't know the first thing about engineering... these are the kind of fellows that always pretend to know, but don't anything. Other engineers and plant operators always have to be alert for these guys... usually their small in numbers, but it seems each refinery has its own "Barney Fife" of the engineering world. These guys are indeed dangerous...and sometimes they've got more sheepskins on the wall than a Professor holding a chair at your favorite university.
What we need to do is get this guy tied down on rollover to a catcracker at one of the typical large refineries with embedded systems. Then let's see how much he sweats. I suspect it would be quite abit...even if the temperature was zero degrees.
Bottom line: This guy is telling us that refineries are NOT dangerous. Refineries are always dangerous. ALWAYS! ...and anybody who'd tell you otherwise is either a fool or a liar. That is what we've got here with this guy, IMO to which I'm entitled. Now this alone should be a tip-off to question everything else this fellow has said. Frankly, I doubt he'd know an embedded chip system if it jumped up and bit him in the ____. So which is he? A shill? or a Moron? Probably both, IMO. Too bad I can't get some of my contacts to come on here and take this guy apart piece by piece ... course, really the guy doesn't say much, technically to have to take apart. But the safety aspect is a dead giveaway of a "Barney Fife Shill".
-- R.C. (racambab@mailcity.com), November 09, 1999.