On every May 1st, like many communists countries, we celebrated Labor Day in Poland. On that day adults as well as children were required to attend a parade organized by the Communist Party followed by dancing, various contests, and sporting activities for children. Each time we waited all year long for this day to come. May 1st, 1986 was different from other years. I was 15-years old back then. I remember that we gathered in front of the school and waited impatiently for the activities to start. Suddenly, sirens went off in the whole town. People panicked because it never happened before. Without any explanations we were told to go to the nearby hospital. Each child was given some brownish liquid to drink. I will never forget the bitter and awful taste of it.
Many children were crying from not knowing why they were forced to drink this unpleasant liquid. Some of my schoolmates even fainted. After receiving a dose we were told by the teacher to go home as quickly as possible, close the windows and stay inside. My parents explained to me that something horrible happened in nearby Ukraine. They were very disturbed. One word caught my attention: Chernobyl. Later on, I learned that this bitter, brownish liquid was diluted iodine that was supposed to protect us from radiation. Being only a child it was difficult for me to understand the enormity and consequences of the accident. Chernobyl is the example of the worst nuclear plant accident in the history of mankind.
Having an efficient, reliable and up-to-date monitoring system is essential to all nuclear plants to ensure safety to the surroundings. Failure in functioning of such a system can have enormous social, economic and health related consequences.
Nuclear Plant Monitoring and Risk Analysis System
In this paper, I focused my research on the power plant monitoring and risk analysis system implemented by the Illinois Department of Nuclear Safety (IDNS). The goal of IDNS is to provide an adequate and sufficient early warning to the off-site public surrounding each nuclear reactor in the state of Illinois. To achieve this goal, a tree-element Remote Monitoring System, an integrated suite of software analysis packages, and a set of analytical procedures have been developed.
a. The Remote Monitoring System
The Remote Monitoring System consists of three sub-systems: the Reactor Data Link (RDL), the Gaseous Effluent Monitoring System (GEMS), and the Gamma Detector Network (GDN). Data from each sub-system is sent to both the primary Radiological and Environmental Assessment Center (REAC) and the alternate REAC via a self-healing communications network. The RDL sub-system receives about 1000 data points from each reactor every two or four minutes. The frequency of transmission is plant-specific. Every six months the current point selection is reviewed and a new catalog of points is implemented. IDNS does not access the nuclear plantТs process computers. The RDL gives REAC vital information on the operational state of each reactor. This information is used to determine the actual or likely failure of the clad, the primary coolant system boundary, and the containment barriers to off-site radiological releases. The GEMS sub-system monitors the plantТs engineered release points for radiological releases. The sampling time is changed manually or automatically. The GEMS provides REAC with information on any release and this information is used to assessing the effects of the release, including dose projections. These projections provide the bases for off-site protection recommendations such as relocating affected populations and restricting access to the contaminated areas (Parker 1).
b. Reactor Accident Monitoring Software Package
An integrated suite of procedures and software packages has been developed to rapidly assess the operational state of each reactor using data from the RMS. There are currently three major software packages available to the Reactor Analyst. The first is the IDNS Early Warning System (DEW), designed to monitor key areas of operation and alert the analyst whether key systems are challenged or fail to perform their design function. The second is the Emergency Action Level Monitor (EALM). The third is the Reactor Analyst Procedures (RAP), series of hard copy and computerized flowcharts, which guide the analyst in determining fission product release barrier integrity. Both DEW and EALM run continuously and feed a summary screen. The RAP software is not running all the time, but is used during the event to guide the analyst in reaching conclusions regarding the level of risk to the public and attendant protection action decisions.
DEW, this software package, using predefined rules, continuously monitors data, primarily
from the RDL, to determine if an event is leading to, or can lead to, core damage, a breach of containment. Additional information from the GEMS and GDN sub-systems supplies IDNS-derived measurements of radiological parameters to confirm and supplement plant data. DEW monitors reactors for a number of categories: fuel cladding, primary coolant system boundary, containment integrity, emergency core cooling status, electric power status, residual heat removal system status, balance of plant status, and plant environmental radiation status. DEW is written to provide a user-friendly environment by adopting a layered approach to data analysis. A main alarm summary screen is available for each site indicating which category of rules for which reactor, at dual unit sites, is in alarm. From the summary screen, the user can access the detailed logic to determine the exact cause of the trip within each category. Each logic screen shows the logic, the setpoint, and real-time data. A graph of the data can easily be displayed on the screen or printed. To aid in the analysis, tow types of event logs are available: a chronological log for all DEW trips showing site, reactor, category, and rule number fired, and second log that allows the analyst to summarize all trips from a given site for any time period, in hours, up to seven days. The detailed logic for DEW is derived from a variety of sources like the extensive collection of plant-specific and plant-controlled documentation including plant drawings, normal and emergency procedures, system descriptions and technical specifications.
The EALM consists of the four main categories: abnormal radiation levels/effluents, fission product barrier degradation, system malfunctions, hazards, and other conditions. The first two categories are easily encoded with the RMS data available to the IDNS. Two latest categories are most difficult to program, as many conditions do not have corresponding RMS data.
Taking Boiling Water Reactor (BWR) Emergency Operating Procedures as a point of departure, IDNS developed flowcharts based upon available RMS plant data to guide in the analyses for release barrier failure. There are flowcharts for determining failure of the cladding, the primary coolant system, and the containment boundaries with additional flowcharts for Pressurized Water Reactors (PWRs). A computerized version of these flowcharts was developed using live RMS data. As plant conditions worsen, highlighting flowchart conditions that are met indicates progress through the flowchart. A feature unique to these is the on-screen display of actual plant operating curves. These curves, updated every two to four minutes, include core/clad damage versus time after shutdown, subcooling limits, fuel damage versus core exit temperature, suppression pool heat capacity temperature limits, and primary containment pressure limit.
IV. Support software
IDNS has developed a software package, DISPLAY that forms the backbone of the analysis structure. This software is a Fortran-based program that allows the analyst to develop logic using simple text files. These files can then be viewed with real-time data using DISPLAY. Line graphs and data history windows are also available. Another program developed by the IDNS is MESSAGE. This program interfaces the analyses software with an alarm screen in the 24-hour-per-day dispatch center in Springfield, IL. Alarms in any analysis program can be routed to the dispatcher to have appropriate response personnel notified. New alarms show in reverse video and must be manually reset.
The software package developed by IDNS for monitoring nuclear plant has been proved more than adequate during plant accident exercise. During normal plant operations, the software has reliably detected plant operations outside plant technical specifications and conditions defined by utility emergency plans.
Malfunctions in any part of the software package designed to monitor nuclear plant could cause a disaster on a massive scale. Two examples described below show how either human error or equipment malfunction lead to an accident. Each of these accidents had an enormous social, economic, and health-related impact.
3. Accident in Chernobyl, Ukraine
Christopher Flavin describes the accident in his book УReassessing nuclear power: The fallout from Chernobyl. At 1:00 a.m. on April 26, the operators at the fourth and newest nuclear reactor at Chernobyl was one full day into a special test. They wanted to see whether the residual energy of a spinning turbine could provide sufficient power in case of an emergency shutdown with loss of offsite power. In the course of the test, operators disconnected safety systems and violated operating procedures in order to press the test forward. Each adjustment caused further departures from the plantТs intended performance, making it unstable.
By 1:23 a.m. the reactors power output had fallen to just 6 percent of its normal level. The fission reaction in the core had been slowed by the buildup of xenon gas. The emergency core cooling system had been shut down; other safety mechanisms had been disconnected. All of the control rods that moderate fission in the reactorТs core had been at least partially pulled out in order to keep the reactor going.
The operators pushed ahead, apparently oblivious to the fact that the reactor had become dangerously unstable. Slowly, the reactors power output began to rise to the intended level and then far beyond. Operators pushed the emergency button known as AZ-5 that sends the control rods back into the core to stop the fission reaction. But the control rods failed to fall fully into the already deformed core. A few seconds later, shocks were felt in the control room, followed almost immediately by two large explosions.
The accident at Chernobyl is the example where human error, equipment malfunction and poor judgment combined, created a disaster on a massive scale. The course of the accident was compounded by the existence of significant drawbacks in the reactor design, which made the plant potentially unstable and easily susceptible to loss of control in case of operational errors.