Article View: comp.software.year-2000
Article #22Re: Chernobyling
From: DEW
Date: Wed, 28 Jan 1998 00:00
Date: Wed, 28 Jan 1998 00:00
128 lines
7410 bytes
7410 bytes
Sean Ennis wrote in message ... >Personaly I think it's mostly the fault of a bad design. If I recall >correctly - the Canadian designed reactors (CanDu?) had the benefit of >shutting down in the even of a catastrophic coolent loss. The The Candu seems to be designed to fail away from a meltdown although that doesn't mean that the design is trouble free or even an intelligent to build on our small planet. It uses heavy water to slow atomic particles that hit others and create the reaction. When the radioactive heavy water blows off, the reaction stops. It reminds me... Years ago I attended a manufacturing software seminar at IBM. On the way to a washroom, I passed another seminar just as the leader said, "The message were getting out there is we're number one but we're not very good." Candu may be number one because the others are far more dangerous. You can find documentation on Candu problems on the web. Candus create waste that stays deadly for thousands of years (when we've only had civilizations for 9000?). Candus periodically leak radioactive garbage into the air and water around us just like other designs. >French/American/Russian designs tended not to do do this... infact they >tended to get much worse. The state is not reassuring nor is the way people are acting. Where are the contingency plans to get us by 2000 for these plants? It seems to be too late for fixes. Who really knows what will happen? Can we do anything to reduce the risk? Politicians, officials and managers don't want to believe bad news any more than anyone else. http://www.house.gov/science/couffou_3-20.html This site raises some questions. Before the questions it says: |Software on nuclear sites is subject to stringent quality controls. |However, |experienced software industry professionals already grappling |with the Year 2000 have expressed doubts about how reliable these |design-based reassurances are. Hard and fast test data to back up these |assurances has not been provided. There even seems to be good information on how people react. http://www.csl.sri.com/neumann/neumannSenate.html |Security Risks in the Emerging Infrastructure |Here are a few of the many factors that have slowed progress in the |security of commercially available high-security products -- above |and beyond the many reasons why complex systems are inherently |difficult to develop and operate in the first place. |* The vulnerabilities in the existing infrastructure are poorly |understood. The risks that can result from those vulnerabilities tend |to be seriously underestimated. This lack of awareness pervades |Government, developers, vendors, users, and even bystanders who |would like to believe that their lives are independent of the technology. |* Another factor that has slowed progress in security is that, despite |the very considerable vulnerabilities and risks in today's |telecommunications infrastructures, digital commerce, and national |security systems, serious disasters have not yet struck critical |systems. Major security-related events have not yet occurred that |in their effects on public awareness might be considered to |correspond in scope to a Chernobyl, Bhopal, or Exxon Valdez. |The security-related cases that have occurred have generally not |caused massive damage or affected many people adversely. The |1988 Internet Worm, the Citibank penetrations, and a few other |similar cases are more like the tip of an iceberg. Fortunately, many |serious security flaws have been detected by friendly people who |have reported them before those flaws could be exploited. |People tend not to worry until they have been seriously affected |(either individually or as part of a nationwide or worldwide effect), |and by then it may be too late. It is generally unwise to wait until |after the disaster to plan on what to do. The situation is perhaps |akin to earthquake preparedness -- you know it is going to |happen eventually. In this case, the cost of preparedness |should be chosen commensurate with the consequences |of the risks that could be avoided. Do we read this and then just cross our fingers on the nuclear plant/year 2000 software threat. I made an appointment and met with our local federal representative last week. He thought that the federal industry minister had everything under control. I showed him the Statistics Canada survey results and Toronto Star articles pointing out that under 10% of companies had taken the threat seriously and that his industry minister troubled. The least we can do is make leaders aware what can happen. Our local rep will likely support emergency measures. >Yah... don't tie/chain control valves in on position (3 Mile) don't do >f*cking 'experiments' with a comertial reactor (Chernobile(sp?)). American nuclear reactor personnel still seem to be overriding safety systems. http://www.nrc.gov/OPA/gmo/nrarcv/98-05iv.htm Nuclear Regulatory Commission Office of Public Affairs -- Region IV 611 Ryan Plaza Drive, Suite 400, Arlington TX 76011 Breck Henderson (Phone: 817/860-8128, E-mail: bwh@nrc.gov RIV: 98-05 January 16, 1998 NRC, ENTERGY TO DISCUSS APPARENT VIOLATIONS AT WATERFORD 3 NUCLEAR PLANT The Nuclear Regulatory Commission staff will hold a predecisional enforcement conference Friday, January 23, with officials of Entergy Operations Inc., which operates the Waterford 3 nuclear power plant near Taft, Louisiana, to discuss apparent violations of NRC requirements. The conference will begin at 10:30 a.m. at NRC Region IV offices in Arlington, Texas. The meeting will be open to public observation; NRC officials will be available afterward for questions. The apparent violations were identified during an inspection conducted November 17 through December 5, 1997, and involve mis-operation of a safety-related cooling system, the auxiliary component cooling water system. Operators allowed both trains of the system to be inoperable at the same time and failed to detect and correct the problem for more than seven hours. >I'm told that it's not 'hard' to shut a reactor down... but it may be a >bitch to bring her back up (i.e. it could take a couple days). Three Mile Island and Chernobyl seems to prove otherwise. Both were hard to shutdown. David
Technical Details
Message-ID:
<6ank8a$3t4$1@news.bconnex.net>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<6aiov3$ibt$1@news.bconnex.net> <gUbz.3$Uh1.13072@typhoon.mbnet.mb.ca>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f504b,89ec2381c18aadad X-Google-Attributes: gidf504b,public X-Google-Thread: fc3d0,89ec2381c18aadad X-Google-Attributes: gidfc3d0,public X-Google-Thread: f7b9c,89ec2381c18aadad X-Google-Attributes: gidf7b9c,public X-Google-Thread: 106cdd,89ec2381c18aadad X-Google-Attributes: gid106cdd,public X-Google-Thread: f86b3,89ec2381c18aadad X-Google-Attributes: gidf86b3,public X-Google-Thread: f67a2,89ec2381c18aadad X-Google-Attributes: gidf67a2,public X-Google-Thread: 112f74,89ec2381c18aadad X-Google-Attributes: gid112f74,public From: "DEW" <caper@bconnex.net> Subject: Re: Chernobyling Date: 1998/01/28 Message-ID: <6ank8a$3t4$1@news.bconnex.net> X-Deja-AN: 319990168 References: <6aiov3$ibt$1@news.bconnex.net> <gUbz.3$Uh1.13072@typhoon.mbnet.mb.ca> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: Barrie Connex Inc. Newsgroups: comp.software.year-2000,can.general,ont.general,ns.general,man.general,ab.general,bc.general