2.1 Principle of test

Generally, a test system generates test signals in a particular order and transmits those signals to the input interface of the tested device. The test system then collects the test signal responses at the output interface of the device or some intermediate point after an appropriate time delay. The collected result is subsequently compared with the expected value to identify inconsistencies. An inconsistent comparison reveals the presence of abnormal states within the device that must be investigated [15-18].

The RPS of the TMSR-SF1 reactor was designed with a triple-modular redundant architecture, as illustrated in Fig. 1. Each channel of the three input modules receives the protection variables and passes the information to the module's respective FPGA processor. The three FPGA processors synchronize and communicate with each other via RS-485 protocol communication. Each FPGA processor executes its logic program and sends the results to its respective output module. The output protection signal results from a 2-out-of-3 voting logic of the triggering signals. The surveillance station collects RPS information via RS-485 protocol communication. The TMSR-SF1 RPS requirements are summarized in Table 1.

Fig. 1.Full-screen View

RPS structure for the TMSR-SF1 project

RPS testing is divided into a number of test sequences, each of which corresponds to a protection function. Each sequence is also divided into several test steps, where each test step corresponds to a combination of input of the protection function. The test system sends a test signal to several inputs of the RPS synchronously within a single test step, which can form different kinds of logic configurations. To ensure that the RPS provides a realistic signal response, an appropriate time delay is incorporated between each test step. The overall scope of testing proceeds from the input interface of the RPS to the output interface of the RPS.

2.2 Structure of the test system

The test system for the TMSR-SF1 RPS employs mobile automatic test equipment that is connected to the RPS by a test cable. Once the test is completed, the test system is immediately disconnected from the RPS. The instrumentation functions on the PCI eXtensions for Instrumentation (PXI) platform. Fig. 2 illustrates the hardware block diagram of the test system, which is comprised primarily of a power supply module, operator station (PXI platform-slot PXI chassis and monitor terminal), five data acquisition cards (DAQs; National Instruments), and five signal conditioning boards (SCBs).

Fig. 2Full-screen View

Hardware block diagram of the test system

The PXI platform provides powerful functions and high reliability that ensure higher precision and better stability than general control hardware [19], [20]. Moreover, the platform can also adapt to the environment of the reactor. With the help of PC client, edited programs can be installed to the internal of PXI automatically without user intervention. A PC monitoring program generated by LabVIEW runs on the PXI platform. The test program provides a human-machine interface (HMI), edits the test cases, manages the configuration files, transforms the program, analyzes and displays the test results, and controls the entire test system by means of the HMI device-keyboard, mouse, and displayer.

Conditioning, collection, and the input and output of analog and digital signals are realized by DAQs [21] and SCBs. The RPS employs industry standard I/O signals, such as standard 4–20 mA direct current and 0–24 V direct voltage signals, which are similar to NPP field signals. To provide universality and compatibility, SCBs were employed to convert DAQ signals to the type of signals required by the RPS. To facilitate operator evaluation of the real-time working condition, the SCBs include a failure indication modular. SCBs and DAQs are connected by standard cable, whereas the SCBs are joined to the RPS by an aviation connector and isolated by an optocoupler.

In addition, a self-detection unit was incorporated into the test system to achieve a self-detection functionality, and promote automatic system correction prior to testing. The results of the process variable transmitters are compared with set point values and logic conforms data of the RPS transfer through the serial communication way by an HUB port. The test system is set in a standard cabinet to protect the components and ensure ease of use. The system also allows for the expansion of the device interface in terms of both the circuit board and the physical design.

2.3 Testing procedure of the RPS test system

During the test procedure, the DAQs and SCBs receive test output and control signals, all of which derive from the primary computer system. The DAQs and SCBs isolate the status signal representative of the protection logic circuit response to the test injection signal, convert it into a test sampling signal that can be identified by a computer, and then send it to the computer for reprocessing.

However, all protection variables cannot be tested simultaneously, but must be tested one by one. For example, in testing the low power range fixed high neutron flux value, only the low power range fixed high neutron flux value disturbance is introduced, and all other variables are held constant. The associated variable is not tested randomly, but is tested according to a linear load change of 5% min−1 and a step load change of 10%.

2.4 Software and GUI

The software employed in the test system is an important factor, and should be the best and most widely used software available. In addition, numerous corresponding I/O models must be created to take into account cooperation with RPS. National Instruments' LabVIEW software and DAQ hardware are applied in the present testing system because, at present, this software [22], [23] and hardware are typically applied in NPPs for signal transfer. LabVIEW based on the graphical G language provides multi-process concurrent execution, and is capable of real-time collection of data, and is therefore convenient for collecting RPS shutdown logic data in real time. The software structure of the test system is illustrated in Fig. 3, which is mainly divided into primary and secondary computer systems. The test signals are entered by an operator, and the order is stored and parsed in the primary computer system. After that, the test signals are transmitted to the acquisition and analysis modules of the secondary computer system. Data acquisition and signal generation are conducted by the acquisition module. Data storage and data analysis of, for example, the real-time responses to operation instructions are all conducted by the analysis module. Data collected from the RPS is recorded and regularly output to a text file.

Fig. 3Full-screen View

Software architecture of the test system

The software algorithm was designed according to the producer/consumer model shown in Fig. 4. In the algorithm, the secondary computer system receives data or orders from the primary computer system in the first while cycle, and then performs data acquisition or generates signals according to the instruction execution, and finally stores the data in the queue awaiting processing. In the second while cycle, the algorithm successively performs a series of operations on the data such as remove, analysis, store, and display. The elements in the queue are assembled according to a first in, first out order.

Fig. 4Full-screen View

Software algorithm model

All monitoring and controlling in the proposed test system is supported by the GUI. The GUI monitors the test process and control parameters, for example, the manual/automatic control switch, set point adjustment, and configuration changes. According to requirements, additional special functions are provided in the GUI, such as signal processing and data display. The testing GUI for the low power range fixed high neutron flux value is shown in Fig. 5. In addition, the physical configuration of the I/O channels and its check are also performed in the GUI.

Fig. 5.Full-screen View

GUI of the low power range fixed high neutron flux value

3.1 Reliability demonstration

According to the testing defined in the V&V plan and GB/T 5204-2008, and as a mandatory testing item required and witnessed by the research team, a long period reliability demonstration testing of the RPS was performed. The RPS was operated continuously over a period of one month, and the protection signal was repeatedly triggered by the test system. During this process, the correctness of the triggering and the stability of triggering precision was recorded and verified by the test system for a number of triggering actions and corresponding overturns of the output modules approaching 105. This testing very convincingly demonstrated the reliability of the RPS in a manner more credible than other system reliability analyses that can be performed.

3.2 Function testing

In addition to white-box testing of the safety software source code, such as review, audit, analysis, unit testing, and simulations, black-box testing (function testing) was performed on the RPS in a laboratory setting. These functions cover all protection variables, their combinations, as well as the combination of these variables based on the guidance provided by simulated signals derived from the test system. The aim of function testing is to verify the following RPS functionality.

(a) Whether the sampling of signals and calculation of the protection variables are correct.

(b) Whether the RPS can accommodate the full ranges of all input signals.

(c) Whether all protection logics are implemented correctly and the precision of the trigger set point is within the required range for each protection variable.

(d) Whether all interlock logics and fail-safe mechanisms for internal and external failures, such as the opening of a circuit, the cutting of a circuit, and a failure of any components or processors, function correctly.

This is one part of the testing required for factory acceptance testing and site acceptance testing, as defined in the IEEE Std 7-4.3.2 standard. All of above RPS functionalities were verified to be properly implemented.

3.3 Performance testing

The performance of the RPS, such as the precision of the trigger set points, the stability of the sampling modules, and the response times, were tested.

The test results verified that the precision of the trigger set point for each protection variable was within the designed range, and the stability of the sampling modules was very high. This demonstrates the advantages of high precision and high stability in the information processing and information transmission of the RPS.

Both analog and digital protection variables were chosen to trigger the RPS repeatedly and periodically. The test system transmits the input signal to the RPS, and records the state of the protection signal. The response time is determined by comparing the time between when the protection variable rose and when the state of the output module changed. For a digital RPS component, the duration of each execution cycle will not be constant because of communication between sampling modules and the RPS and between different components of the RPS, and all functions, such as sampling, calculation, comparison with the set point, trigger logic, and output of protection signals, will be executed only once during each cycle. After recording the protection variable signals and the triggered status over a long period, providing, for example, 100 triggering events, the maximum and the minimum values of the response time can be determined, which are listed in Table 2.

According to statistical theory, the individual response time results follow a normal distribution. Therefore, the recorded response time data was evaluated according to the normal distribution fitting procedure in MATLAB software. Data histograms and the normal distribution curves were obtained, as shown in Fig. 6. According to the probability density function

Fig. 6.Full-screen View

Data histograms and normal distribution curves of the response time data for analog and digital protection variables.

the mean response time and standard deviation were respectively μ = 3.86 and σ = 1.27 for analog protection variables, and μ = 0.41 and σ = 0.06 for digital protection variables. As such, the analog response time within the 95% credibility range was 3.61 ms to 4.11 ms, and the digital response time within the 95% credibility range was 0.39 ms to 0.42 ms.

3.4 V&V of the test system

Guidelines or standards such as the IEEE7-4.3.2 (1993), IEC880 (1986), and JEAG4609 (1989) standards address issues involving the reliability of safety systems, and define various requirements such as for hardware/software design, manufacturing, V&V procedure documentation, and maintenance. The test system, as a non-nuclear safety system, must also undergo the V&V process according to the various regulatory standards and guidelines to verify that the test system responds correctly. To meet these standards and/or guidelines, the V&V procedure was well organized, as illustrated in Fig. 7. Accordingly, the following steps were taken.

Fig. 7Full-screen View

V&V procedure

Step 1: Quality assurance and software configuration were verified according to national and international standards. As such, an independent V&V team responsible for all V&V activities was established. An original version of documents related to requirements and specifications were formed at the beginning of the test system development. Refined and ameliorated versions of these documents were formed after review by the V&V team. The updated documents were also evaluated by all engineers engaged in developing the test system.

Step 2: The hardware and software design specifications, that is, the logic design specifications were verified. The logic designs were verified by confirming that the logic described in the interlock block diagram meets the system specification requirements.

Step 3: PXI and LabVIEW are widely employed in numerous applications, and fulfill the requirements of a test system, for example, system lifetime and environmental adaptability with respect to temperature. For verification of the LabVIEW system components, one component of the process involved reviewing the design documentation and design scheme, and to analyze and test the source code. These tests can be classified as white-box testing. Another component of the process involved black-box testing, where the software and the test system were analyzed and tested as a whole based on external responses. The assessment of the source code employed by the test system software was conducted manually, and testing concluded that the source code was verifiable, its behavior deterministic, its performance predictable, and the development process reviewable.

Step 4: The V&V team tested the system independently using standard testing instruments, and the results are summarized in Table 3. For example, the implementation of a 4–20 mA input in the test system by the GUI resulted in an equivalent value at the output interface of the system, which can be compared with the analog signal by means of a standard calibration instrument. Also, the standard signal source simulation was tested to calibrate the interval between two signals, and the test results matched well with the simulated interval of 40 ms.

The V&V results demonstrated the advantages of the high precision and high stability of the test system.