SG corrosion control: ask the ‘expert’

The demands for higher availability and better operating economics at nuclear power plants have grown steadily over the past few years. In addition to introducing new power plant technologies (eg in the form of new designs, processes and materials), manufacturers have also increasingly applied secondary measures to enhance the safety and operating economics of power plant units. These include more sophisticated process monitoring and analytical systems, and in recent times, diagnostic systems which perform continuous assessment of the plant condition to allow imminent changes that can lead to damage and faults to be detected at the earliest possible time and well before levels are reached at which a protection trip is initiated.

A typical example is water chemistry monitoring. An optimum water chemistry regime and high corrosion resistance for all parts of the systems and components are a major prerequisite to ensure safe and economic power plant operation. For this reason a system called DIWA (Diagnostic System Of Water Chemistry) was developed for diagnosing chemical operating conditions as a basis for cost effective, preventive maintenance.

The economic aspect is reflected in fewer outages, increased operating reliability and longer component service life. Plants which are fully equipped with such systems can, as a medium term goal, replace the standard practice of periodic maintenance (which is time and cost intensive) with condition-oriented maintenance for certain components.

WATER CHEMISTRY MONITORING

Of particular importance in this regard are the steam generators whose trouble-free operation strongly depends on stringent corrosion control. This can be achieved by very close monitoring of the water chemistry conditions in the entire steam water cycle.

Siemens’ DIWA system guarantees optimum and reliable monitoring of the reactor coolant system and/or steam, condensate and feedwater cycle, allowing good corrosion control on the secondary side of the steam generators. Operating conditions associated with water chemistry are rapidly identified and evaluated, allowing any existing as well as incipient disturbances to be quickly pinpointed.

DIWA provides for almost fully automated monitoring of the plant water chemistry. It acquires and analyses significant operating and process variables, uses these to generate reference variables and interprets the parameters to make a complete diagnosis.

DIWA was directly derived from the DIGEST (Diagnostic Expert System for Turbo-Machinery) system, which was developed over the last few years by the Siemens Power Generation Group. It is built up around a knowledge base system which was designed for maximum flexibility and can thus be used for a variety of different applications. The capabilities of the system can be adapted at any time to specific user needs by installing additional on-line monitors and continually incorporating new plant-specific knowledge.

ANALYSIS VS DIAGNOSIS

For marketing reasons, solutions which are at best analytical systems are often sold today as diagnostic systems. The dividing line between analysis and diagnosis is, in fact, not always clear cut. However, when diagnostics is understood and accepted as a new and separate entity, it is relatively easy to define.

The main distinguishing factor is that analysis embraces all the activities performed by applying numerical mathematics in the broadest sense. In particular, this includes the calculation of characteristic parameters or setpoints, the comparison of setpoints with actual data, and the detection of deviations and limit violations. Also included is the broad task of visualising information which has been measured or calculated. In addition to displaying numeric values in tables, for example, one of the main tasks is to present the information intuitively in optically enhanced graphics, trend plots and other presentation formats. The methodology is based on familiar, step-by-step solution procedures, ie algorithms. If the algorithms are known, they are relatively easy to implement in conventional computer programs.

In addition to the above tasks, diagnostic systems are expected to actually interpret the information, in order to assess a process in relation to particular properties and requirements. In analytical systems, this more demanding task is left to the operator. Diagnostic systems must also be capable of explaining the process used to derive the diagnosis, so that the operator can understand it. Finally, the presentation of a forecast for subsequent process events, and the recommendation of countermeasures, are features which must also be included in the performance spectrum. The above work is based mainly on mathematical logic, often combined with the processing of statements in (quasi-)natural language. Both technical and, especially, empirical knowledge, which cannot generally be expressed directly in algorithmic terms, are required from the experts providing the input. A suitable method is to use a knowledge base in which the knowledge is set out in the form of rules.

For a long time, “diagnostics” was regarded as the “task of identifying possible fault causes from the incorrect behaviour of a component or system”. This definition can no longer be considered appropriate in many areas. A more up-to-date interpretation of the term is “preventive diagnostics”, which detects and reports changes, through continuous monitoring and assessment of events, before any damage or fault can occur. This is the concept which the diagnostic component of the DIWA system seeks to implement.

THE EXPERT SYSTEM

The overall structure of the system is shown on the previous page. The operating principle is evident from the diagram. After performing plausibility checks, calculations of characteristic and additional values, which cannot be measured directly, all of the measured data are directly accessible to the expert system kernel. From these values, symptoms are derived (fuzzification). This task is performed by the help of parts of the knowledge base of this system.

After creating symptoms, the system accesses another part of the knowledge base where the rules of the expert knowledge are to be found. After running through all the rules, the expert system creates one or more diagnoses. Based on the operator connections within the rule base, the system calculates confidence factors for every created diagnosis, which represent the safety level for the diagnosis. This workflow is directly related to the work an expert is doing.

All diagnoses which are created by the expert system kernel are stored together with the related measured data within the data base of the diagnostic system. The user has access to the results via a graphical user interface.

A practical example of the application of the DIWA expert system is corrosion control in power plants. The second diagram shows an overview of a PWR water–steam cycle.

The concept of the analytical part of the diagnostic system takes into account the fact that more than one input source can be available. In the case of power plant water chemistry, it is normal that some of the measured data are collected on-line via installed sensors. Most of the data which have to be collected are measured at power plant laboratories via special analytical methods and equipment and, therefore, have to be input into the system “off-line”.

The analysis part of DIWA performs the following tasks based on the specific data input:

• Plausibility check on all measured data. The data check is performed with respect to limit violations, characteristic changes within the trend and their affinity in relation to other values. All results of these checks are stored in a quality identifier and are accessible to the diagnostic part of the system.

• Calculation of derived or not directly measurable values. This includes time and resource expensive numerical calculations of the distribution of major species and impurities within the several physical phases of the feed and cooling water, and estimates of characteristic values of major components (steam generator, condenser etc).

• Derivation of statistical data of process monitoring (mean, maximum and minimum values of important chemical measurands, time range and distribution of limit violations, monitoring of operational states etc).

• Compression of the raw data material and transfer to the historical archive.

All of the collected and derived data can be accessed by the user through DIWA’s graphical user interface. DIWA provides this service in several ways – process displays, trends, tables, protocols and the ability to freely configure diagrams.

SYMPTOM GENERATION

The next step consists of the actual symptom generation. This requires answers to the following questions:

• What symptoms are relevant for a diagnosis and how can they be formulated?

• What measured data and characteristic parameters are suitable for symptom generation and what linguistic properties are appropriate for the diagnosis?

An intermediate result can be the input as a symptom to other rules, with the result that the entire rule base has a net-type structure. Since reference is often made to the same symptoms within the rules, the rules can be represented graphically, and rules which refer to the same symptoms can be combined in a group. The following example shows one rule, corresponding to a complete pathway, which reads as follows:

“If the steam generator conductivity is rising and the conductivity of the main condensate is high or rising and the conductivity of additional water is at a constant level and the conductivity of feed water is rising or high, then a condenser leakage must be the result.”

A specific language was created for the formulation of these rules in a form that can be processed immediately by a program. This language is called FCRSL, the “Fuzzy and Crisp Rule Specification Language”. The notation in this language is quite similar to the formulation in natural language shown in the above example. The mechanism for integration of the rule into the program is to specify all rules in an external fileset (knowledge base). Rules can thus be changed or added as desired, without the need to modify the program.

The verification component, with which the user can analyse the generated diagnosis, is an important component of the expert system. The complete rule tree involved in the diagnosis analysis is presented graphically on the screen. All graphical elements are mouse-sensitive: when the user positions the mouse on any of the symbols for rules, symptoms, operators or diagnoses, the associated values (names, states, weightings) are displayed. Elements are also highlighted in colour, wherever possible. Since the rule trees can, in certain circumstances, cover large areas and may not fit completely onto the screen, it is possible to expand and collapse rule symbols simply by clicking them with the mouse. This enables context-sensitive navigation through the rule base, allowing the operator to concentrate on specific areas of relevance within the analysis.

With these features, the explanation component presents a powerful tool with which even less experienced users can rapidly trace the path of the diagnostic system from the measurement of the data to the generation of the diagnosis, and thus pinpoint the causes.