From: ostreamH <fireman@shaw.wave.ca>
Date: Thu, 3 Dec 1998 06:44:05 +0800
To: cypherpunks@cyberpass.net
Subject: Re: y2k+oil refineries
In-Reply-To: <199812012241.XAA19806@replay.com>
Message-ID: <XFMail.981202171540.fireman@shaw.wave.ca>
MIME-Version: 1.0
Content-Type: text/plain



Assuming most power plants are similar, all control instrumentation
must have some way to bypass the computers in case of emergency. The
pulp and paper mill I worked in lost +1M$ / day of downtime so when 
a controller went down, the process that was effected went on manual
bypass and everything continued to run. And yes, all "embedded" systems
were eaisly accessable for quick repair/replacement. 

On 01-Dec-98 Anonymous wrote:
> North's "scrap the refinery, the chip broke" scenario was forwarded to
> comp.software.year-2000 by Paul Milne, resident doomsayer, foul-mouthed
> religious fanatic, economic Marxist, and all around kook.  It prompted a
> very knowledgable reply which pointed out how silly the whole idea was,
> from someone with relevant experience.  Maybe next time Detweiler could
> check c.s.y2k to filter out North's nuttier ideas before forwarding
> them here.
> 
> 
> Author: SAG
> Email: stephen.and.marilyn.goldstein@worldnet.att.net
> Date: 1998/12/01
> 
> fedinfo@halifax.com wrote:
>> 
>> From GN:
>> 
>> Category:
>>  Noncompliant_Chips
>> Date:
>>  1998-11-30 13:28:22
>> Subject:
>>  Fuel Production Plants
>> 
>> * * * * * * * *
>> 
>> I have one very, very reliable source within that industry who tells me that
>> the oil refining industry can't cope with the task. I am told that the
>> problem
>> of embedded systems can NOT be fixed EVER, no matter how much time were
>> allowed. WHY? Because the refineries themselves would have to be dismantled
>> to
>> uncover these embedded systems. Essentially, the refineries would have to be
>> destroyed and rebuilt!!! These embedded systems are buried within enclosed
>> systems. Identifying, testing and replacing these systems is too
>> impractical.
>> It is financially unsound to do so. The better option is to build new ones.
>> There is no time to do this with less than 400 days left and the time to
>> build
>> a new refinery is 3 to 5 years.
>> 
>> So, what does this mean? My sources, especially the most reliable source
>> tell
>> me that it means that on January 1, 2000... the oil and gas refineries will
>> cease operations. These facilities also have converted their inventory
>> management control systems to small inventory levels so that inventory
>> levels
>> are running about 1 to 2 days capacity. A few years ago, the industry
>> averaged
>> a 1 to 6 month supply in storage tanks. Not so today.
>> 
>> The results: By 1/5/2000 there will be no gasoline, no diesel fuel, no
>> natural gas, no heating oil, no fuel oil products at all. This means trains
>> will have no fuel. Trucks will have no fuel. Cars will have no fuel.
>> Electric
>> Power Plants will have no oil for fuel, nor coal... because there will be no
>> fuel to power the vehicles to get it to them. So, there will be no
>> electricity. And you know the remaining domino schematic from that point.
>> 
>> ======
>> 
>> I have no way of knowing whether the embedded systems are just that,
>> embedded
>> in such a way that they can not be accessed. I imagine that some could be
>> under fifty feet of concrete or otherwise inaccessable. If this is so, then
>> there is not the slightest doubt at all, that it is indeed all over. Period.
>> 
>> I am not going to bandy about the issue of whether this source is reliable
>> or
>> not. It makes no difference. The only thing I am concerned with is whether
>> these systems are in fact inaccessable. I know that not every system is
>> inaccessable. The question is whether there are enough inaccessable systems
>> to
>> mean that the refineries etc. will not function.
>> 
>> Of course, I would love to hear someone counter this with evidence showing
>> that what has been related above is not true, or it is an urban myth etc.
>> But, I would like 'evidence'. Not conjecture or inuendo or suppositions.
>> 
>> If it were so, that there were indeed these inaccessable systems, would the
>> companies involved let it be known publically? I think not.
>> 
>> If this report is accurate, the remediation is 100% moot as I have said all
>> along, and you can kiss your butt good-bye.
> 
> I'm not sure if I want to play this game Mr. Milne -- you offer this
> article which is, conjecture, innuendo and supposition but demand that
> any counter story be documented by "evidence."  That's pretty tough and,
> frankly, I'm not up to the task as my knowledge is with electric power
> plants -- not oil refineries.
> 
> They do, of course, share some important characteristics and so I'll
> give it a try.  The approach will be from two perspectives -- first,
> I'll explain some power plant construction practices that contradict the
> refinery story; second, I'll offer another review of the nature of the
> "embedded" systems that might be at issue.
> 
> Power Plant (and refinery) construction . . . .
> 
> Remember, power plants and refineries are:
> o Capital intensive
> o Make increased use of computerized process control systems
> o Operate a continuous manufacturing/conversion process employing high
> temperatures and pressures.
> 
> Typical design life of a coal-fired power plant is 40 years.  During
> that period, any number of components *will* fail and *will have to be
> replaced.*  Wouldn't make much sense to put a $500million investment at
> risk 'cause a $20.00 part failed in some inaccessible location.  Thus
> EVERYTHING is accessible.
> 
> You want evidence and I'm not about to take you on a power plant tour
> but even if you've never been inside a power plant the construction
> practice is similar to that found in many other industrial settings and,
> if you've ever been aboard a naval vessel or taken a cruise, ships. 
> These settings are nothing like your home (or even an office) with all
> the infrastructure components nicely hidden behind walls -- pipes are
> exposed and clearly labeled -- power and control cables are laid in
> exposed cable trays and risers.  Electronic components are often mounted
> in racks with easy access from front and back -- probably not at all
> like your computer or home theatre configuration.  All this is to PERMIT
> MAINTENANCE, REPAIR and MODIFICATION.
> 
> So you need to understand that the problem isn't just maintenance, in
> general, or for y2k.  Process plants need to be modified frequently --
> market conditions demand a change in inputs or outputs.  Can't get
> enough sweet crude?  Exxon doesn't close the refinery -- they modify it
> to handle the new feedstock (I got the grand tour from a fellow I knew
> who worked at Exxon's Baton Rouge refinery, years ago).
> 
> Want some pictures?  Here are a few from several "continuous process"
> industries: http://www.powerprocesspiping.com/,
> http://www.bdmechanical.com/ppiping.htm,
> http://silverweb.nf.ca/m&m/cb-p&p.htm, and
> http://www.shambaugh.com/process.htm.
> 
> Now consider the nature of these embedded components.  This has been the
> subject of much discussion in csy2k.  I'd like to suggest that there are
> three broad categories of components in this context:
> 
> o The control system(s) -- SCADA -- one or more intelligent nodes build
> on traditional minicomputer, or more recently, microprocessor-based
> server technology.  These are very accessible -- they're in, adjacent
> to, or very near, the control room.  In an even more modern "distributed
> control system," some of the capability will be located in different
> areas of the plant.  Nevertheless, they still have to be very accessible
> -- stuff breaks -- memories get hard, multibit errors, disk drives fail,
> etc.
> 
> o Remote devices -- the control systems can't run without data and so
> you have dozens to thousands of remotes -- devices that measure process
> parameters (temperature, pressure, mass flow, volumetric flow,
> acceleration and mechanical position (valve position or tank levels))
> and a smaller number of remotes that can act on SCADA commands (start a
> motor, open a valve, etc.)  Though most of these devices are pretty
> dumb, some may have a bit of silicon-based intelligence and therefore
> susceptible to y2k problems.  BUT, they all have to be accessible
> because 1) they malfunction or need to be recalibrated and 2) plant
> modifications often require removal/replacement to accommodate process
> changes.
> 
> o Embedded systems -- I think that the consensus is that the real
> embedded systems are those systems that are not obviously run by a
> computer -- the power plants water chemistry analyzer or the refineries
> gas chromatograph.  These are on the site but they're not in the "plant"
> -- they're in the lab -- very accessible.
> 
> Now "accessible" doesn't always mean you can walk right up and touch
> it!  Guess where the flue gas monitoring remotes (temperature, opacity)
> are located -- top of the boiler or in the stack.  But here's the
> scenario -- opacity indicator increases (flue gas has more smoke in it)
> but the stack gas "looks" clear.  Do you shut down the plan on
> environment limits or do you send a maintenance man to replace the
> remote?
> 
> Now is it possible that conditions would be different at an oil
> refinery.  Sure, like I wrote at the beginning, I'm not really familar
> with these.  But, really, we'd be looking at some obtuse examples --
> imagine that rather than using a tank level indicator to see how much
> gasoline is in a tank, someone came up with the bright idea of putting a
> strain gauge *under* the tank and determing the amount of product in the
> tank but computing the weight on the gauge and using that to compute the
> amount of product.  The device fails and, we'll all agree, it is not
> practical to replace it.
> 
> Does the refinery stop using the tank?  I wouldn't think so.  They
> retrofit a traditional tank level indicator (float) to provide the
> needed information. 
> 
> HTH,
> 
> SAG

----------------------------------
E-Mail: Rob S <fireman@shaw.wave.ca>
Date: 02-Dec-98
Time: 17:02:18

This message was sent by XFMail
----------------------------------