Automated Testing of Nuclear Plant Control Modules Using NI LabVIEW

Author(s):
Art Frink - Florida Power Corp

Industry:
Electronics

Products:
LabVIEW,

The Challenge:
Automating the testing of electronic control modules in an aging nuclear power plant to improve performance and reliability and reduce cost.

The Solution:
Developing a PC-based virtual instrumentation system of National Instruments GPIB instruments controlled by LabVIEW.

Introduction
When the manufacturer of a 20-year-old control system notified Florida Power Corporation that it would no longer support their equipment, Crystal River Nuclear Plant engineers started evaluating alternatives. Replacing a major control system in a nuclear power plant is no small task. Current technology could improve performance, but not without significant cost. The capital expenditure and the extended plant outage to make the conversion could be justified; however, when unknown initial reliability and start-up problems were factored in, the engineers started looking for ways to salvage the existing system. Florida Power was able to obtain spare parts from an abandoned nuclear plant. The requirement for aggressive testing and the trend toward shorter overhaul schedules in the power industry dictated the need for an automated testing system. We developed a prototype testing system using LabVIEW.

Design
We designed and built a rack-mount test system with existing materials and instruments wherever possible. Although it was a prototype, future expansion was always a consideration. We checked out a Keithley 199 DMM, Wavetek 650 Function Generator and an Elgar AT8A Power Supply from inventory. We also obtained a 19 in. rack with casters following a chemistry system upgrade. Because a Dell 486/33 PC with LabVIEW 3.0 was available from a previous project, the only equipment we purchased was an AT-GPIB/TNT GPIB interface board, a Keithley 707 Switching Matrix, and a rack-mounted computer monitor. The only additional software purchased was the SQL Toolkit for LabVIEW and a report writer from Crystal Reports.

We had two primary requirements for the test program developed in LabVIEW. Flexibility hit the top of the list. We were required to test a total of 652 modules of 46 basic types used in two plant control systems. All of the modules of a particular type are identical, but each module has its own set points and test criteria that are subject to change. Second, we needed to produce standardized test reports suitable for retention as quality records.

For flexibility, we designed a Microsoft Access 2.0 database. We created one or more data tables for each type of module. Engineers easily modified data in the tables as they evaluated the results. It was also a simple task to add or remove test points for a particular output curve. Furthermore, the database served as a repository of test results for both historical purposes and for printing the test report.
The LabVIEW Call Library Function provided a seamless interface to Crystal Reports, which fulfilled the reporting requirements.

We selected six module types for the prototype. By using the Access database and the SQL Toolkit, we identified the similarity of these types from the database so we had to program for only three types of modules. We could also have had the operator program the system, but we wanted to remove the human factor. These six (now three) modules represented 198 (30 percent) of the 652 modules in service.

Operation
The operator’s initial window contains two list boxes populated from the database. Each list box represents one of the two control systems in the plant and contains a list of the module types in that system. Selecting module type with a double-click starts the appropriate virtual instrument (VI) with the Call Instrument VI. The operator is now presented with a list box of all the modules of a particular type in that system. A double-click prompts the operator to insert the selected module.

After the module is inserted into the test rack and the message box acknowledged, no further operator intervention is required unless the operator wants to change report options. The operator can turn on/off Crystal Reports, as well as an unformatted LabVIEW-generated report. When the test is completed, a success/failure indication is displayed; the operator can select another module to test or exit back to the initial window.

Results
Crystal River Unit 3 shut down for a refuel outage in late February 1996. The testing of the Integrated Control System and the Non-Nuclear Instrumentation controls commenced two weeks later. Based on historical data, we had allocated 30 minutes to test each module. But with LabVIEW, we actually averaged about 15 minutes each, even with some downtime. The testing of individual modules varied between two and five minutes depending on the type, but various delays contributed to the extended testing time. For example, one cause of delay was the failure of the Keithley 199 DMM. It was replaced with a Keithley 2000, which required some minor programming and test rack modifications. Overall, the test was a success. The improved productivity and consistent test results were impressive. If equipment failure could have been avoided, testing would have been significantly faster.

What Is Next
Following the success of the prototype, we have identified several areas for further development. We will make minor changes to the existing VIs to improve performance and user interfaces. We will also write VIs for additional module types in preparation for the next refuel in 1998. In addition, we will evaluate the ability to calibrate as well as test modules. We are also developing a plan to market the system to other power plants with similar control systems.

For more information, contact:

Arthur Frink

Florida Power Corp.

15760 W. Power Line Street

Crystal River, FL 34428-6708

Tel (352) 563-4318

E-mail: arthur.frink@fpc.com

Browse All Case Studies »