[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: P2 and the Y2K "Bug" (examples)



In response to my post of 12/11/98 (RE: P2 and the Y2K "Bug") Mike Callahan
(Mike.callahan@jacobs.com ) wrote in part: 

	"I would be interested in knowing if anyone has identified a "real"
problem with Y2K.....So far, all i have seen are
	urgent cries to spend more money reviewing code and replacing
controls for what is an assumed problem."

Mike --

Good question, and one that has crossed my mind on many occasions.  Like a
lot of people,  I see the neo-survivalist types on television talking about
their reinforced bunkers and food caches and think "even if they're right, I
don't want to agree with them!"  I have similar reactions when I see the
small group of unprincipled consultants out there using fear and
misinformation to sell their Y2K services (just like a small percentage of
our colleagues use these tactics to sell P2).    So I guess I would count
myself in the ranks of the Y2K skeptics who believe that the "crisis" is
overstated and overhyped for a variety of reasons having more to do with
human nature and greed than with technology.   In fact, prior to researching
this article, my main interest in the Y2K issue was to appropriate it as a
metaphor for pollution prevention in the foreword I wrote for a friend's
book:

		"Think of a chemical plant as a computer program for turning
raw materials into products, with the instructions (code) written in pipes
and valves, rather than bits and bytes.  Like the software engineers who
must examine every line of code to find [the Y2K bug], we are faced with the
challenge of methodically "opening up" each process, and eliminating the
sources of waste and pollution that threaten the environment, and threaten
the viability of the industry.

		 In this light, [P2] is essentially a tool for "debugging"
the chemical process industries."

		excerpted from the foreword to 
		"Pollution Prevention: Methodologies, Technologies and
Practices," by K Mulholland and J Dyer, AIChE Press (due to be published
early 1999) 
		(it's an excellent book for those working in the chemical
process industries, by the way, written by two DuPont employees)

As a process engineer with some (long ago, and mostly forgotten) experience
with programmable loop controllers, I also agree that on first blush it
would seem that even though a process control device might use a date stamp,
the process control logic generally doesn't need to concern itself with the
day/month/year portion of the stamp.  So intuitively, one would expect that
the issue would not cause a problem.  But consider that time stamp
information is often used in date arithmetic -- in calculating time
differences, integrating control variables over time (e.g., to smooth
control response), etc.  This is where the discontinuity between 1900 and
2000 can lead to problems.  Two other root causes are register overflows --
similar to what causes Windows to crash when poorly designed applications
experience unexpected data values in variables that aren't tested for
validity; and control logic which ignores data values that have improper or
unvalidated time/date stamps (examples of which can be found at
http://www.granite.ab.ca/year2000/incidents.htm )

So, yep, it COULD happen that the Y2K bug would lead to failure of a control
system.  "It's possible in theory," as they say.  But a lot of things that
are plausible  just won't happen (I COULD lose 50 pounds by the time of the
NPPR Spring meeting, but I wouldn't bet on it!).  So I sought out some
specific examples, and candidly didn't come up with many.  But they do
exist.  I've tried to use only examples that I could verify through specific
and multiple references, in order to avoid the propagation of urban legend
and apocrophyl tales:

		* An aluminum smelter in Tiwai Pt, New Zealand shut down in
1996, not due to Y2K issues, but because their control system had failed to
factor in the fact that 1996 was a leap year.  
		Source: "The Dominion" -- Wellington, New Zealand, 8 Jan
1997; 
		account on-line at
http://www.granite.ab.ca/year2000/incidents.htm and numerous other
locations.

		* A small manufacturer of industrial liquid solutions found
their production line completely stopped on January 1, 1997. It was
discovered that their process control systems were not designed to account
for a leap year (1996) and subsequently shut down when the changed from 1996
to 1997. Before company personnel could remedy the situation, the liquid
solutions that were in the process pipelines hardened and could not be
removed.  The company was forced to replace the process pipelines at a cost
of $1 million. They were unable to manufacture products for several days,
thereby, causing late deliveries to customers. In addition to the cost to
repair the pipelines, the company believes they lost three new clients
because their shipments were delayed."
		Source:  Congressional Testimony of Ann K. Coffou, Managing
Director, Giga Year 2000 Relevance Service  
		before the House Technology subcommittee, March 20, 1997
(available online at: http://www.house.gov/science/couffou_3-20.html) 

		* Y2K testing was conducted on a generator temperature
control system at a power plant in the United Kingdom. To test for Y2K
compliance, the control system clock was set to just prior to midnight, Dec.
31, 1999. Twenty seconds past midnight, the unit tripped on high generator
temperature.   It turns out the process value for the control valve for
generator cooling is integrated over time for smoothing and when the time
moved past midnight from '99 to '00, the PV was integrated over infinity.
The valve closed (fail safe), tripping the unit on high generator
temperature." 
		Source: Electric Power Research Institute Proceedings from
EPRI Embedded Systems Workshop, Proceedings dated 10/4/1997.  
		Excerpted at http://www.euy2k.com/reallife.htm.  

Remember, we don't have to have catastrophic failure in order to have P2
implications -- in fact, I suspect that catastrophic failure will be rather
rare (blame it on my incessant and generally unwarranted optimism and belief
in technology).  But, since off-spec product and process upsets are common
sources of waste in many types of manufacturing processes, there appears to
be at least some justification for viewing this issue as a P2 concern.  

There are other areas of concern from a P2 perspective -- e.g., failures of
Electronic Data Interchange (EDI)  transactions (what happens when your
waste hauler doesn't come to pump out the sump on schedule?  or if
flocculent or some other ancillary chemicals run short resulting in
additional loadings to treatment systems?  we've all met manufacturers who
would not be above continuing to operate and accepting the environmental
fine as a tolerable consequence, preferable to shutting down the plant).  So
while a lot  of the attention focuses on issues related to embedded control
systems, any number of plausible scenarios can be built which have
environmental consequences.  Some finite percentage of these  scenarios will
likely come to pass (with a low probability of the catastrophic ones).    A
good technical discussion of this is presented in "A Risk Management
Approach to Dealing With the Year 2000 Problem in Process Control & Safety
Systems," by NW Ritchie and P Ferron, to be presented at the Gas Processors
Association 77th Annual Convention, March 1998.  This document is available
online (albeit in the much-despised PDF format) at:   
http://www.risk-solutions.com/y2kpaper.pdf

I still don't plan on hiding out in a mountain cabin (though perhaps if it
had a trout stream nearby.....), or even storing away food.  
But I guess I feel there's some legitimate cause for concern, and a rational
basis for addressing it as one more aspect of P2.

Anyway, thanks for a good question, and for an excuse to look into this a
bit further

Scott Butner (rs_butner@pnl.gov) 
Senior Research Scientist, Environmental Technology Division
Pacific Northwest National Laboratory
4000 NE 41st Street, Seattle WA   98105
(206)-528-3290 voice/(206)-528-3552 fax
http://www.seattle.battelle.org/P2Online/
http://www.chemalliance.org/




> -----Original Message-----
> From:	Callahan, Mike [SMTP:Mike.Callahan@Jacobs.com]
> Sent:	Friday, December 11, 1998 3:42 PM
> To:	'Butner, Robert S'
> Cc:	'P2Tech'
> Subject:	RE: P2 and the Y2K "Bug"
> 
> Robert,
> 
> I would be interested in knowing if anyone has identified a "real" problem
> with Y2K.  All of the articles I have read to date, including the CEP
> article, are vague in providing actual problems. For example, where would
> you need to control a process based on the year and not the second,
> minute,
> or hour ? Can someone give me an actual process control example of where
> the
> assumption of 19XX instead of 20XX matters ?  With all the money being
> spent
> to address this problem, we should be flooded with concrete examples of
> how
> potential upsets and releases were averted.  So far, all i have seen are
> urgent cries to spend more money reviewing code and replacing controls for
> what is an assumed problem.
> 
> Mike.callahan@jacobs.com  
> > ----------
> > From: 	Butner, Robert S[SMTP:butner@battelle.org]
> > Reply To: 	Butner, Robert S
> > Sent: 	Friday, December 11, 1998 1:35 PM
> > To: 	p2tech@great-lakes.net
> > Subject: 	RE: P2 and the Y2K "Bug"
> > 
> > Folks --
> > 
> > Some time ago, a P2TECH subscriber (I think it was Catherine Dickerson
> > from
> > PPRC) asked about the potential P2 implications of the "Y2K" bug.  
> > I thought it was one of the more interesting questions I'd seen on
> P2TECH
> > in
> > some time, but candidly spent little time thinking about it at the time.
> > 
> > Recently, though, a co-worker and I spent some time looking at material
> > specifically related to the relationship between Y2K and the process
> > industries, and the potential for unplanned releases due to failure of
> > process plant equipment, monitoring equipment, etc.  We've collected a
> > number of references and links to online papers on the topic, along with
> a
> > really well done piece from EPA-OW staff, and posted them to the
> > ChemAlliance site:
> > 
> > 	
> >
> http://www.chemalliance.org/Columns/Regulatory/Will_the_Y2K_Bug_Put_You_Ou
> > t_
> > Of_Compliance.htm
> > 
> > (Yeah, I know it's a ridiculously long URL )
> > 
> > Though the emphasis of the article is on the impact of potential
> > date-related glitches on compliance, I think that technical assistance
> > providers working on P2 will find a lot of value in some of the tables.
> > These include a list of common pieces of process equipment which are
> > likely
> > to have embedded microprocessors (and hence be susceptible) and a list
> of
> > "other" Y2K dates (besides Jan 1, 2000) which are likely to lead to
> > problems.  So I thought I'd pass this along, as food for thought for
> those
> > of you who are working with the process industries.
> > 
> > Hope this helps.  Happy Holidays.
> > 
> > Scott
> > 
> > Scott Butner (rs_butner@pnl.gov) 
> > Senior Research Scientist, Environmental Technology Division
> > Pacific Northwest National Laboratory
> > 4000 NE 41st Street, Seattle WA   98105
> > (206)-528-3290 voice/(206)-528-3552 fax
> > http://www.seattle.battelle.org/P2Online/
> > http://www.chemalliance.org/
> >