A test system, method, and related apparatus

Abstract

The application provides a test system, a method and related equipment, and relates to the technical field of equipment testing. The test system comprises a test host, an operation simulation device and an image shooting device. The operation simulation device is used for sending and receiving signals to a safety control display device (SCID) to be tested under the control of the test host; the image shooting device is used for shooting a screen picture of the SCID under the control of the test host. The test host is used for controlling the operation simulation device to send and receive signals and controlling the image shooting device to shoot the screen picture of the SCID by running a test script, and automatically generating a test result according to the matching result of the signals and the image. In this way, the test system replaces manual operation and judgment with external hardware, does not need to install any program for testing on the SCID, and realizes closed-loop automatic testing of the complete functions of the SCID.

Description

Technical Field

[0001] This application relates to the field of equipment testing technology, and in particular to a testing system, method and related equipment. Background Technology

[0002] Safety control and information display (SCID) devices are critical equipment in nuclear power plant operations, facilitating interaction between operators and the digital nuclear safety control and protection system. They perform key functions such as monitoring safety parameters, controlling equipment operation, and processing alarm information; their reliability directly impacts the nuclear safety of the power plant. Therefore, these devices must undergo comprehensive and rigorous testing before commissioning and after maintenance to ensure functional correctness and reliability. However, SCIDs run on a dedicated operating system, maintaining physical isolation from external systems.

[0003] In practical applications, functional testing of SCID is usually completed manually. Under this method, a complete test case set may require weeks or even months of manual operation, resulting in low testing efficiency. Due to the long testing cycle, the testing process may be carried out by different testers, whose operating habits and judgment standards differ, leading to poor consistency of test results. Furthermore, manual testing cannot cover high-frequency, long-term stress testing scenarios.

[0004] Therefore, there is an urgent need for a solution that can eliminate manual testing in order to achieve closed-loop automated testing of the full functionality of SCID. Summary of the Invention

[0005] This application provides a testing system, method, and related equipment for achieving closed-loop automated testing of the complete functionality of a security control display device's SCID. Furthermore, this application also provides corresponding computing devices, computer-readable storage media, and computer program products.

[0006] In a first aspect, this application provides a testing system comprising a test host, an operation simulation device, and an image capturing device. The operation simulation device, under the control of the test host, sends signals to the physical interface of the Security Control Display Device (SCID) under test, and receives signals from the physical interface of the SCID under the control of the test host. The image capturing device, under the control of the test host, captures images of the SCID screen to obtain a first image and a second image including the screen image. The test host, by running a test script, controls the operation simulation device to send a first signal to the SCID's physical interface, controls the operation simulation device to receive a second signal from the SCID's physical interface, and controls the image capturing device to capture images of the SCID's screen, obtaining multiple images including the screen image. The test host is further configured to generate test results based on the multiple images, the first signal, and the second signal by running the test script. These test results indicate whether the screen content in the first image matches the reference screen content corresponding to the first signal, and whether the reference signal corresponding to the second image matches the second signal.

[0007] In this way, the test host controls the simulation device to send a first signal and receive a second signal to the SCID's physical interface by running test scripts, replacing manual signal simulation of various external physical interfaces of the SCID. Simultaneously, the test host controls an image capturing device to capture the SCID's screen, obtaining a first and second partial image, thus replacing manual observation of the SCID's screen display. Based on this, the test host automatically determines whether the SCID's interface display is correct when responding to the first signal by matching the screen content in the first partial image with the reference screen content corresponding to the first signal; and it automatically determines whether the signal returned by the SCID through the physical interface matches its interface display state by matching the reference signal corresponding to the second partial image with the second signal, replacing manual judgment of the SCID's screen display content. Thus, the test host can automatically complete signal sending and receiving, screen capture, matching verification, and test result generation based on the test script, without manual intervention. Therefore, this test system can achieve closed-loop automated testing of the SCID without installing testing software or drivers on the SCID, meeting the testing requirements of nuclear safety-grade equipment and overcoming the problems of low efficiency and poor consistency of manual testing.

[0008] In one possible implementation, the operation simulation device includes an interface adapter or a keyboard and mouse simulator. Specifically, when the operation simulation device includes an interface adapter, the interface adapter is used to send signals to or from the first or second physical interface of the SCID; wherein the first physical interface is an interface controlled based on electrical signal states, and the second physical interface is an interface for data interaction based on communication protocols; when the operation simulation device includes a keyboard and mouse simulator, the keyboard and mouse simulator is used to send signals to the SCID's universal serial bus (USB) interface. In this way, the interface adapter uniformly manages the signal interaction of hard-wired interfaces and communication protocol interfaces, and the keyboard and mouse simulator simulates human operation of the keyboard and mouse. The two work together to achieve coverage of multiple types of SCID interfaces, providing a hardware foundation for closed-loop automated testing.

[0009] In one possible implementation, the interface adapter device may include a field-programmable gate array (FPGA) chip, and at least one of an input circuit, an output circuit, an Ethernet circuit, and a time synchronization circuit. Specifically, when the interface adapter device includes an Ethernet circuit, the Ethernet circuit is used to send a first signal to the second physical interface of the SCID and to receive a second signal from the second physical interface of the SCID. When the interface adapter device includes an input circuit, the input circuit is used to receive the second signal from the first physical interface of the SCID. When the interface adapter device includes an output circuit, the output circuit is used to send the first signal to the first physical interface of the SCID. When the interface adapter device includes a time synchronization circuit, the time synchronization circuit is used to send a clock synchronization signal to the second physical interface of the SCID, and the clock synchronization signal is the first signal. In this way, the interface adapter device integrates the functions that were originally implemented by multiple discrete hardware modules, and the FPGA chip is used as a unified controller for management, avoiding hardware redundancy caused by discrete module design and simplifying the system architecture. Furthermore, multiple heterogeneous interfaces can be coordinated and controlled by the same FPGA chip, enabling precise timing synchronization between the interfaces. For example, it can trigger Ethernet communication simulation while outputting mode switching signals, thereby meeting the requirements of SCID multi-interface collaborative testing.

[0010] In one possible implementation, when the interface adapter device includes an Ethernet circuit, this Ethernet circuit may specifically include multiple connection links, each comprising a first connection link, a second connection link, and a third connection link. The FPGA chip communicates with the test host via the first connection link, connects to the SCID's communication Ethernet port via the second connection link, and connects to the SCID's maintenance Ethernet port via the third connection link. The communication Ethernet port is used to transmit service data, and the maintenance Ethernet port is used to transmit operation and maintenance data. Thus, by configuring multiple connection links, the interface adapter device can simultaneously cover both the SCID's communication Ethernet port and maintenance Ethernet port, improving the comprehensiveness of the test.

[0011] In one possible implementation, when the Ethernet circuit receives a second signal from the SCID and transmits it to the FPGA chip, the FPGA chip can parse the second signal based on the SCID communication protocol to obtain the data sent by the SCID. Simultaneously, the FPGA chip can also convert the data to be sent to the SCID into a first signal based on the SCID communication protocol and send the first signal to the SCID via the Ethernet circuit. The communication message indicated by the first signal is a communication message encapsulated based on the SCID communication protocol. In this way, the FPGA chip implements the parsing and encapsulation of the SCID custom communication protocol in hardware, solving the problem that general-purpose test equipment cannot support private custom protocols, and ensuring that the test system can perform real-time simulation and interaction of SCID communication data.

[0012] In one possible implementation, the test system may further include an external relay connected to the interface adapter device, which controls the power supply to the SCID via the external relay. This achieves complete closed-loop automated testing from device power-on, requiring no manual intervention and supporting fully automated execution of scenarios such as long-term stress testing, thus improving the automation level and reliability of the test.

[0013] In one possible implementation, the operation object description in the test script can be a semantic description of the SCID interface control. Specifically, the test script can include an operation action and an operation object description; the operation object description describes the target object of the operation and should use the accurate text displayed on the SCID interface or an industry-standard name. For example, when the "Main Pump" button on the SCID screen is clicked, the control type of the operation object should be "Button," the displayed text should be "Main Pump," and the corresponding operation object description is ""Main Pump" button. The corresponding test script is "Click the 'Main Pump' button," meaning the test script only needs to write the semantic description of the button and does not need to write the button's screen coordinates. When the test host runs the test script, based on the image captured by the image capturing device, it identifies the position coordinates of the interface control in the interface through a visual recognition model. The test host can then control the operation simulation device to execute the operation corresponding to that position coordinate. When the SCID interface layout or resolution changes, such as causing the "Main Pump" button to move to a new position on the screen, the visual recognition model can re-identify the button from the new screen and obtain its new coordinates, without needing to modify the test script itself. In this way, the test script is freed from its dependence on fixed coordinates, solving the problem that traditional coordinate-based test scripts become ineffective after interface changes, thus enhancing the script's robustness.

[0014] In one possible implementation, when the visual recognition model fails to identify the target interface control in the image, the test host can control the image capturing device to re-capture the SCID screen. Through this retry mechanism, the test system can automatically handle recognition failures caused by accidental factors such as SCID interface loading delays or image transmission delays, avoiding misjudgments due to a single recognition failure and improving the reliability and stability of the test.

[0015] In one possible implementation, the operation object description in the test script can also be a semantic description of the SCID's physical interface. Specifically, for interface operation-type actions, the operation object description includes the interface type and its channel identifier or target state. For example, when the test switches the SCID to running mode, the interface type of the operation object in the test script is the working mode interface, the target state is running mode, and the corresponding operation object description is "running mode." The corresponding test script is "switch to running mode," meaning the test script does not need to write the hardware register address or pin number corresponding to this mode. When the test host runs the test script, for interface operation-type actions, it sends or receives signals to the corresponding physical interface of the SCID by controlling the operation simulation device. Thus, for SCID physical interface operations, the operation target is also located using a semantic description. When the SCID's interface pin allocation or hardware configuration changes, only the channel mapping relationship of the interface adapter device needs to be updated; the test script itself does not need to be modified, enhancing the test script's adaptability and stability to hardware configuration changes.

[0016] In one possible implementation, after the test host identifies the position coordinates of interface controls on the interface using a visual recognition model, it can also determine the coordinates of the operation point based on the type of interface control and the corresponding operation point calculation rules. For example, for confirm or cancel buttons, the operation point is the coordinates offset inward by a preset number of pixels from the button's geometric center to avoid clicking the button's border; for text input box controls, the operation point is the coordinates at a preset ratio on the left side of the input area to avoid clicking the clear button or dropdown button on the right side of the input box. Thus, by employing differentiated operation point positioning strategies for different types of controls, the problem of click failures or accidental touches on adjacent controls caused by simply taking the geometric center is avoided, improving the accuracy and reliability of the operation.

[0017] In one possible implementation, when the test host identifies interface controls using a visual recognition model, it can use a combination of text matching and feature matching to determine the target interface control. The features used for feature matching include element category and positional context. Specifically, when multiple controls with identical or similar text exist on the interface, the test host determines the operation context based on the preceding operation steps described in the test script, and then identifies the target interface control from among the multiple controls with identical text based on the operation context. For example, in the SCID trend display interface, there might be both a "Confirm" button for setting the start time and a "Confirm" button for setting the range. The test host distinguishes which button should be clicked based on whether the preceding steps include the operations of "setting the start time" or "setting the range." This resolves the matching ambiguity problem when multiple controls with the same name exist on the interface, improving the accuracy of visual recognition and the reliability of test execution.

[0018] In one possible implementation, the test host may further include an operation log module. Specifically, this operation log module is used to record operation logs during the test process in chronological order, and to generate log verification values ​​based on adjacent operation logs, storing these verification values ​​in the next operation log entry. The operation logs may include operation time, operation type, device interface identifier, control command, and execution result fields. Thus, by generating log verification values ​​based on adjacent operation logs, a chain-like verification structure can be formed. Tampering with a recorded operation log will cause the verification value to mismatch with the verification value stored in the next log entry, thereby ensuring the immutability and integrity of the operation logs and meeting the audit and traceability requirements of nuclear safety-grade equipment testing.

[0019] In one possible implementation, the test host may further include a script generation module for generating test scripts. The script generation module supports a recording mode. In recording mode, the test host displays the SCID screen image captured in real-time by an image capturing device, and an interface control panel for simulating operations on the SCID interface. Testers perform keyboard and mouse operations in the window displaying the SCID screen image, and simulate operations on the SCID interface on the interface control panel. The script generation module captures these operations, converts the captured interface operations into interface operation scripts containing operation actions and operation object descriptions, and converts the captured interface operations into interface operation scripts containing operation actions and operation object descriptions. It then integrates the interface operation scripts and interface operation scripts into a unified test script according to the chronological order of the operations. Thus, a complete test script containing both interface and interface operations can be generated with a single recording, eliminating the need for testers to record and manually integrate the two types of operations separately. This solves the problem that existing recording tools can only record a single type of operation, improving the efficiency and completeness of test script generation.

[0020] Secondly, this application provides a testing method applied to a test host in a testing system, which further includes an operation simulation device and an image capturing device. Specifically, the test host controls the operation simulation device to send a first signal to the physical interface of the SCID under test by running a test script, and controls the operation simulation device to receive a second signal from the physical interface of the SCID; then, the test host controls the image capturing device to capture the screen image of the SCID, obtaining a first part image and a second part image including the screen image; thereby, the test host generates a test result based on the first part image, the second part image, the first signal, and the second signal by running the test script; wherein, the test result is used to indicate whether the screen image content in the first part image matches the reference screen image content corresponding to the first signal, and the test result is used to indicate whether the reference signal corresponding to the second part image matches the second signal.

[0021] Since the testing method provided in the second aspect corresponds to the testing system provided in the first aspect, the technical effects of this method can be seen from the technical effects of the corresponding implementation method in the first aspect above, and will not be repeated here.

[0022] Thirdly, this application provides a testing system comprising a testing host and an operation simulation device. The operation simulation device, under the control of the testing host, sends signals to and receives signals from the physical interface of the SCID under test. The testing host, by running a test script, controls the operation simulation device to send a first signal to the physical interface of the SCID, to receive a second signal from the physical interface of the SCID, and to acquire the display screen of the SCID through its video output interface to obtain multiple images including the display screen, the multiple images including a first portion image and a second portion image. The testing host is further configured to generate test results by running the test script based on the first portion image, the second portion image, the first signal, and the second signal. These test results indicate whether the content of the display screen in the first portion image matches the content of a reference display screen corresponding to the first signal, and whether the test results indicate whether the reference signal corresponding to the second portion image matches the second signal.

[0023] Thus, when the SCID has a video output interface, such as a High Definition Multimedia Interface (HDMI), the test host can directly acquire the display image through this interface without the need for additional image capture equipment, thereby simplifying the hardware configuration of the test system. Simultaneously, all test operations can be executed externally by the test host through simulated devices, eliminating the need to install testing software within the SCID. This achieves closed-loop automated testing of the SCID while adhering to nuclear safety level equipment safety constraints.

[0024] Fourthly, this application provides a computing device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the testing method as described in the second aspect above.

[0025] Fifthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the test method as described in the second aspect above.

[0026] In a sixth aspect, this application provides a computer program product comprising a computer program or computer instructions, which, when executed by a processor, implements the test method as described in the second aspect above.

[0027] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments provided in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0029] Figure 1 This application provides an environmental schematic diagram of a testing system according to an embodiment of the present application. Figure 2 This application provides a schematic diagram of the overall architecture of a testing system. Figure 3 A schematic diagram of the structure of an interface adapter device provided in an embodiment of this application; Figure 4 An interface allocation diagram of an interface adapter device provided in an embodiment of this application; Figure 5A flowchart illustrating a testing method provided in an embodiment of this application; Figure 6 A flowchart illustrating a dynamic coordinate mapping method provided in an embodiment of this application; Figure 7 This application provides a schematic diagram of operation point calculation rules for different types of interface controls. Figure 8 A schematic diagram of the interface layout for a recording mode provided in an embodiment of this application; Figure 9 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0030] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a method of distinction used in describing objects with the same attributes in the embodiments of this application.

[0031] To make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0032] See Figure 1 , Figure 1 This is a schematic diagram of the environment of a testing system provided in an embodiment of this application. For example... Figure 1As shown, the test system includes a test host 101, an interface adapter 102, a keyboard and mouse simulator 103, and an image capturing device 104. The test host 101 is connected to the interface adapter 102, the keyboard and mouse simulator 103, and the image capturing device 104. The test host 101 and the interface adapter 102 can be connected via Ethernet; the test host 101 and the keyboard and mouse simulator 103 can be connected via a virtual serial port; and the test host 101 and the image capturing device 104 can be connected via a USB interface. The virtual serial port can be implemented using, for example, a USB interface or other types of interfaces. The interface adapter 102 can be a circuit board integrating input circuits, output circuits, Ethernet circuits, and time synchronization circuits, used to connect the hard-wired interface, Ethernet interface, and 485 time synchronization interface of the SCID under test. The keyboard and mouse simulator 103 can be a signal conversion device connected between the test host 101 and the SCID. It is used to convert operation commands sent by the test host 101 through a virtual serial port into USB keyboard and mouse signals, and send them to the SCID through a USB interface, so that the SCID can recognize them as real keyboard and mouse operations. The image capturing device 104 can be a digital camera aimed at the SCID display screen, used to capture the SCID screen image and transmit it to the test host 101 through a USB interface.

[0033] In actual testing, SCID, as a nuclear safety-grade device, runs a dedicated operating system and is physically isolated from external systems. Due to this safety constraint, functional testing of SCID cannot be achieved by installing test programs within the SCID. Currently, the simulation of some hard-wired interface signals can be implemented using industrial hardware modules, but the SCID's interface operation and test result judgment still require manual processing, making testing primarily reliant on manual intervention. Under manual testing methods, a complete test case set often requires weeks or even months of manual operation, resulting in low testing efficiency. Furthermore, due to the long testing cycle, multiple testers typically need to take turns executing the tests, and differences in operating habits and judgment standards among different testers lead to poor consistency and difficulty in reproducing test results.

[0034] Based on this, in the testing system provided in this embodiment, the test host 101 sends and receives signals from the external physical interface of the SCID through the interface adapter device 102, replacing manual signal simulation of various physical interfaces of the SCID; it injects keyboard and mouse operations from the USB interface of the SCID through the keyboard and mouse simulator 103, replacing manual operation of the keyboard and mouse; and it captures images of the SCID through the image capturing device 104, realizing the acquisition of the SCID screen image from the outside, replacing manual visual observation of the screen. The test host 101 automatically identifies and matches the acquired screen image, replacing manual judgment of the test results. Thus, all test operations can be executed through external hardware, without installing testing programs on the SCID or modifying its system configuration, thereby realizing closed-loop automated testing of the SCID.

[0035] As an implementation example, this embodiment divides the test system into a three-layer architecture: "hardware layer - adaptation layer - software layer". See also Figure 2 , Figure 2 This is a schematic diagram of the overall architecture of a testing system provided in an embodiment of this application. The hardware layer includes the SCID to be tested, whose external interfaces include hard-wired interfaces, Ethernet interfaces, RS-485 time synchronization interfaces, and USB interfaces. The adaptation layer includes hardware such as an interface adapter device 102, a keyboard and mouse simulator 103, and an image capturing device 104, used to achieve signal adaptation and conversion and human-computer interaction simulation between the test host 101 and the SCID. The software layer is a testing software platform running on the test host 101. This testing software platform mainly includes a device control subsystem, a custom protocol simulation subsystem, a test script integrated development environment, an AI vision engine, a test execution and result judgment subsystem, and a data management and report generation subsystem. The device control subsystem includes IO drivers, interface adapter card drivers, keyboard and mouse converter drivers, and camera drivers, responsible for communication and control with the various hardware devices in the adaptation layer.

[0036] Before the automated test is officially executed, the test host 101 can perform initial configuration of the test system. The initial configuration may include: configuring the channel mapping relationship of the interface adapter device 102, training and deploying the AI ​​vision model and semantic parsing engine, obtaining the test script, and calibrating the coordinate system of the image capturing device 104.

[0037] First, the test host 101 configures the channel mapping relationship of the interface adapter device 102. Based on the interface type of the SCID and the test requirements, the test host 101 connects and maps each digital input / output channel of the interface adapter device 102 to the corresponding physical interfaces of the SCID. The specific channel allocation scheme will be discussed in detail below. Figure 4 Please provide a detailed explanation.

[0038] Secondly, the test host 101 trains and deploys an AI vision model and a semantic parsing engine. The AI ​​vision model, built and trained by the test host 101 based on a deep learning framework, is used to recognize SCID screen images captured by the image capturing device 104. After model training, the test host 101 calls the AI ​​vision model for analysis via an API interface. The semantic parsing engine can be configured by the test host 101 as a hybrid architecture of "rules + deep learning + post-processing verification," used to parse test cases written in natural language into a structured sequence of operation steps, which the test host 101 then executes sequentially. The recognition capabilities of the AI ​​vision model and the specific parsing process of the semantic parsing engine will be explained below in conjunction with the test flow.

[0039] Then, the test host 101 obtains the test script. This embodiment supports three methods for obtaining the test script. The first is the natural language writing method, where testers write test cases according to preset syntax specifications, and the semantic parsing engine automatically converts the test cases into executable test scripts. The second is the recording and generation method, where testers operate on the test host 101, and the script generation module automatically captures the operations and generates the test script. The specific recording process will be described in detail below. Figure 8 A detailed explanation follows. The third method is direct writing, where testers directly write Python scripts that conform to the correct syntax, and the test host 101 loads and executes the script.

[0040] Finally, the test host 101 calibrates the coordinate system of the image capturing device 104. After the image capturing device 104 is initially installed or its location is changed, the test host 101 executes the coordinate system calibration process. The test host 101 establishes the mapping relationship between image pixel coordinates and SCID screen physical coordinates through the calibration process. The specific calibration process will be described in detail below. Figure 6 Please provide a detailed explanation.

[0041] After completing the above initialization configuration, the test system can automatically execute the test process. Before executing the test process, the specific implementation methods of each hardware module constituting the physical foundation of this test system are explained below. The test system achieves non-intrusive operation on the SCID through three external hardware components: the interface adapter device 102 is responsible for signal transmission and reception, the keyboard and mouse simulator 103 is responsible for keyboard and mouse simulation at the human-computer interaction level, and the image capturing device 104 is responsible for capturing the SCID screen image. All three can be uniformly scheduled through the test host 101, replacing manual operation and observation from outside the SCID, without the need to install test programs on the SCID. The specific design of each hardware module is described below.

[0042] SCID offers various external interfaces, including hardwired interfaces, Ethernet interfaces, and RS-485 time synchronization interfaces. Hardwired interfaces are controlled via level signals; SCID operating mode switching, application mode switching, output enable / disable, and general input / output signals are all transmitted through hardwired interfaces. Ethernet interfaces are used for SCID communication and maintenance data exchange. RS-485 time synchronization interfaces are used to receive clock synchronization signals. Traditionally, each interface requires a separate hardware module, such as a digital input module, a digital output module, an Ethernet communication module, and a RS-485 time synchronization module. Each module has its own independent controller and interface circuitry, resulting in complex and redundant system hardware.

[0043] Therefore, this embodiment integrates at least one of the input circuit, output circuit, Ethernet circuit, and time synchronization circuit onto a single circuit board, with the FPGA chip acting as a unified controller. In a preferred embodiment, the interface adapter device 102 integrates all four types of circuits. See also Figure 3 , Figure 3 This is a schematic diagram of an interface adapter device provided in an embodiment of this application. The interface adapter device 102 includes an FPGA chip 1021, as well as an input circuit 1022, an output circuit 1023, an Ethernet circuit 1024, and a time synchronization circuit 1025.

[0044] Input circuit 1022 is used to implement isolated digital input functionality. For example, input circuit 1022 may include eight isolated digital input channels, employing two four-channel digital isolators to achieve electrical signal isolation, with an isolation voltage of 2500 volts alternating current (VAC). Each input of input circuit 1022 supports a 24-volt DC level input, is compatible with SCID hardwired signal standards, and is equipped with overvoltage and reverse connection protection circuits. Input circuit 1022 is used to receive signals from SCID's physical interface for control based on electrical signal states, such as acquiring SCID general purpose digital output (GPDO) signals.

[0045] Output circuit 1023 is used to implement isolated digital output functionality. For example, output circuit 1023 may include eight isolated digital output channels, employing two four-channel digital isolators for signal isolation and one eight-channel Darlington transistor array to enhance drive capability. Each channel has a maximum output current of 500 mA. Each output channel of output circuit 1023 can output a 24-volt DC level, compatible with SCID hardwired signal standards. Output circuit 1023 is used to send signals to SCID physical interfaces that control based on electrical signal states, such as sending control signals to SCID's general purpose digital input (GPDI) interface, operating mode interface, or application mode interface.

[0046] Ethernet circuit 1024 provides multiple Ethernet connection links. For example, Ethernet circuit 1024 can provide six connection links, where one connection link communicates with the test host 101 via a first part of the connection link, four connection links connect to the four communication Ethernet ports of the SCID via a second part of the connection link, and the remaining connection link connects to the maintenance Ethernet port of the SCID via a third part of the connection link. The communication Ethernet port is used to transmit service data, and the maintenance Ethernet port is used to transmit operation and maintenance data. Thus, by configuring multiple connection links, a single interface adapter device 102 can simultaneously access both the communication Ethernet port and the maintenance Ethernet port of the SCID, supporting service data simulation and operation and maintenance simulation, thereby improving the comprehensiveness of the test.

[0047] The time synchronization circuit 1025 is used to send a clock synchronization signal to the SCID's time synchronization interface. For example, the time synchronization circuit 1025 may employ an isolated RS-485 (recommended standard 485) transceiver with an isolation voltage of 2500VAC, used to simulate a Global Positioning System (GPS) time synchronization signal and send the clock synchronization signal to the SCID's 485 time synchronization interface.

[0048] In practical applications, SCID uses a proprietary frame format as its communication protocol, which general-purpose test equipment cannot directly support. To address this, the FPGA chip 1021 is equipped with parsing logic for the SCID proprietary communication protocol. This logic enables hardware-level parsing of communication data received from SCID via the Ethernet circuit 1024 to obtain the data sent by SCID. Furthermore, it can convert data to be sent from the test host 101 to SCID into signals according to this communication protocol and send them to SCID via the Ethernet circuit 1024. The communication message indicated by this signal is a communication message encapsulated based on the SCID communication protocol. In this way, the FPGA chip 1021 implements the parsing and encapsulation of the SCID custom communication protocol in hardware, solving the problem that general-purpose test equipment cannot support proprietary custom protocols and ensuring that the test system can perform real-time simulation and interaction with SCID communication data.

[0049] When testing the synchronous execution of hardwired interface operations and Ethernet interface operations, for example, while sending a mode switching level signal to the SCID's operating mode interface, a data packet is simultaneously sent to the SCID via the communication Ethernet port. The same FPGA chip 1021 can coordinate the output circuit 1023 and the Ethernet circuit 1024 to perform these two operations within the same clock cycle, ensuring timing synchronization of multiple interface operations. In this way, the interface adapter device 102 integrates functions that were originally implemented by multiple discrete hardware modules onto a single circuit board, avoiding hardware redundancy caused by discrete module design and simplifying the system architecture.

[0050] In the channel allocation of interface adapter device 102, this embodiment has made unified plans based on the interface type of SCID. See [link / reference] Figure 4 , Figure 4This is a schematic diagram of interface allocation for an interface adapter device provided in an embodiment of this application. Exemplarily, digital input channel 1 is connected to SCID's GPDO1, and digital input channel 2 is connected to SCID's GPDO2, for acquiring SCID's general output signals; digital output channel 1 is connected to SCID's GPDI1, and digital output channel 2 is connected to SCID's GPDI2, for sending general input signals to SCID; digital output channel 3 is connected to SCID's output disable / enable interface; digital output channel 4 is connected to SCID's working mode interface, for switching between download mode and running mode; digital output channels 5 and 6 are connected together to SCID's application mode interface, jointly used to switch between operator mode, supervisor mode, or engineer mode; digital output channel 7 is connected to the control terminal of external relay 105, and the interface adapter device 102 controls the power supply of SCID through this external relay 105. Thus, the power supply control of SCID is incorporated into the automated testing process, enabling fully automated execution of testing scenarios requiring repeated power-on and power-off cycles, such as long-term stress testing. The remaining channels serve as backup and expansion channels.

[0051] In addition to controlling the hardwired interface and communication interface of the SCID, the test system can also simulate the keyboard and mouse operations performed by the tester on the SCID. For this purpose, this embodiment uses a keyboard and mouse simulator 103 to achieve this function. One end of the keyboard and mouse simulator 103 is connected to the test host 101 via a virtual serial port to receive operation commands sent by the test host 101, and the other end is connected to the SCID via a USB interface. The keyboard and mouse simulator 103 includes a USB device simulation circuit for simulating a standard USB keyboard and USB mouse device to the SCID. The operation commands sent by the test host 101 can be converted into USB human interface device (HID) messages by the keyboard and mouse simulator 103 and then sent to the SCID. The SCID can recognize these as real keyboard key presses, mouse movements, mouse clicks, mouse wheel movements, and other operations.

[0052] In this way, the interface adapter device 102 can uniformly handle the signal transmission and reception of hard-wired interfaces and communication protocol interfaces, and the keyboard and mouse simulator 103 can simulate the operation of the keyboard and mouse. The two types of devices work together to cover various physical interfaces of SCID, so that the testing operation of SCID does not require manual intervention.

[0053] This embodiment employs an image capturing device 104 to externally capture images of the SCID screen, enabling the acquisition of its screen display content without reading the internal display data of the SCID. For example, the image capturing device 104 can be a global shutter digital camera, connected to the test host 101 via a USB interface, transmitting the captured SCID screen image to the test host 101 in real time. The test host 101 acquires the SCID screen image through the image capturing device 104, ensuring that no display data needs to be read from within the SCID during the test, thus meeting the security requirement of physical isolation between the SCID and external systems.

[0054] The test host 101 is the core computing device that executes the test logic. The aforementioned interface adapter 102, keyboard and mouse simulator 103, and image capturing device 104 are all connected to the test host 101 and are uniformly scheduled by the test host 101. Specifically, the test host 101 has the graphics processing capabilities required to run the AI ​​vision model, the storage space required to store test data and operation logs, and various communication interfaces required to connect the various hardware devices, such as an Ethernet interface for communicating with the interface adapter 102, a virtual serial port for communicating with the keyboard and mouse simulator 103, and a USB interface for communicating with the image capturing device 104.

[0055] Based on the hardware architecture described above, the following explains how the test host 101 uses a software platform to schedule various hardware modules to complete automated testing. The test software platform mainly includes a device control subsystem, a custom protocol simulation subsystem, a test script integrated development environment, an AI vision engine, a test execution and result judgment subsystem, and a data management and report generation subsystem.

[0056] The device control subsystem is responsible for communication and control with various hardware modules. Specifically, this subsystem may include an I / O driver, an interface adapter card driver, a keyboard / mouse converter driver, and a camera driver, providing a unified device abstraction interface for upper-layer software. The I / O driver is responsible for unified reading and writing of the various digital input and output channels of the interface adapter device 102. The interface adapter card driver communicates with the interface adapter device 102 via Transmission Control Protocol / Internet Protocol (TCP / IP), responsible for sending and receiving custom protocol data, sending clock synchronization signals, and controlling power supply. The keyboard / mouse converter driver communicates with the keyboard / mouse emulator 103 via a virtual serial port, responsible for converting upper-layer software operation commands into keyboard / mouse operation signals and sending them to the keyboard / mouse emulator 103. The camera driver is responsible for parameter configuration, real-time image acquisition, frame rate control, and image preprocessing of the image capturing device 104, and supports hardware-triggered acquisition mode, enabling the test host 101 to trigger the image capturing device 104 to capture the SCID screen image while sending operation commands through the keyboard / mouse emulator 103, ensuring timing synchronization between operation and image acquisition.

[0057] A custom protocol simulation subsystem is used to simulate SCID's proprietary communication protocol data. This subsystem includes a data simulation engine and a command parsing module. The data simulation engine supports the generation of various data types: static data, used to simulate constant field device parameters; dynamically changing data, used to simulate field device parameters that change over time; boundary value data, used to simulate the extreme values ​​of field device parameters; and abnormal data, used to simulate data output under field device failure conditions. The command parsing module receives and parses device operation commands sent by SCID through the Ethernet interface, and generates response data conforming to the SCID proprietary communication protocol format according to preset rules, realizing closed-loop data interaction with SCID.

[0058] The test script integrated development environment (IDE) provides testers with a graphical interface for writing and managing test scripts. This subsystem specifically includes a natural language script editor, an automatic script conversion engine, a recording mode module, and a script debugger. The natural language script editor allows testers to write test cases in a near-natural language style according to preset syntax rules; the automatic script conversion engine can automatically convert natural language test cases into executable test scripts; the recording mode module supports automatically generating test scripts by recording manual operations, and the specific recording process will be described below. Figure 8 Detailed explanation provided; the script debugger supports single-step execution, breakpoint setting, variable viewing, and real-time image preview, facilitating the development of test scripts and problem localization.

[0059] The AI ​​vision engine, based on deep learning technology, is the core module of the testing system for automatically recognizing SCID screen images. The AI ​​vision engine calls the AI ​​vision model deployed in the initial configuration to analyze the SCID screen images captured by the image capturing device 104, identify the interface controls in the image, and output information such as the element category, bounding box coordinates, text content, and element status of each interface control.

[0060] The test execution and result determination subsystem is responsible for the automatic execution of test scripts and the intelligent determination of test results. This subsystem specifically includes a script execution engine, an operation coordinate mapping module, an intelligent result determination module, and an exception handling module. The script execution engine employs a multi-threaded architecture to execute device control, image acquisition, and result determination tasks in parallel. The operation coordinate mapping module dynamically calculates the precise coordinates of keyboard and mouse operations based on the positions of interface controls identified by the AI ​​vision engine. The intelligent result determination module supports multiple verification methods, including interface control existence verification, text content verification, control state verification, numerical range verification, and trend verification. The exception handling module automatically retryes, records screenshots, and generates exception reports when exceptions occur during testing.

[0061] The data management and report generation subsystem is responsible for storing, managing, and generating test data and reports. This subsystem may specifically include a test database, an operation log system, and a report generation engine. For example, the test database may be an SQLite database used to store test scripts, test cases, test results, operation logs, and screenshots. The report generation engine automatically generates test reports that conform to nuclear power industry standards, supporting formats such as Word, PDF, and HTML. The report content may include a test overview, test case execution status, pass / fail statistics, failure reason analysis, and screenshots of key steps.

[0062] Based on the aforementioned hardware architecture and software platform, the following section combines... Figure 5 This document describes a complete testing process to illustrate how various hardware modules and software subsystems work together to achieve closed-loop automated testing of SCID. See also... Figure 5 , Figure 5 This is a flowchart illustrating a testing method provided in an embodiment of this application. The testing method is applied to the test host 101 in the aforementioned testing system, which also includes an interface adapter 102, a keyboard and mouse simulator 103, and an image capturing device 104. The method includes the following steps.

[0063] S501: The test host 101 controls the interface adapter device 102 to power on SCID via an external relay 105.

[0064] The test host 101 sends a power-on command to the interface adapter device 102 via Ethernet. Upon receiving this command, the FPGA chip 1021 of the interface adapter device 102 sends an activation signal to the external relay 105 through its digital output channel. Once the external relay 105 is activated, the power supply circuit for the SCID is turned on, and the SCID begins power-on and startup. In this way, the power on / off control of the SCID is incorporated into the automated testing process, enabling fully automated execution of test scenarios requiring repeated power-on and power-off cycles, such as long-term stress testing.

[0065] S502: Test host 101 is waiting for SCID to complete startup.

[0066] After powering on, the SCID requires a certain amount of time to complete the loading of the operating system and the startup of applications. The test host 101 can determine whether the SCID has completed startup in one of the following ways: First, preset the waiting time, such as a preset waiting time of 30 seconds; second, continuously capture the SCID screen image through the image capturing device 104, and analyze the image through the AI ​​vision engine. When the preset startup completion indicator is recognized, such as the characteristic layout of the system main interface, it is determined that the SCID has started up successfully.

[0067] S503: The test host 101 controls the operation simulation device to send the first signal to the physical interface of SCID by running the test script.

[0068] Depending on the test case, the first signal can be of various types. For example, when the test case verifies the SCID's operating mode switching function, the first signal is a mode switching level signal sent by the test host 101 to the SCID's operating mode interface through the output circuit 1023 of the interface adapter device 102, used to switch the SCID from download mode to running mode. When the test case verifies the SCID's function of displaying field device data, the first signal is a data packet conforming to the SCID's proprietary communication protocol format sent by the test host 101 to the SCID's communication Ethernet port through the Ethernet circuit 1024 of the interface adapter device 102. This data packet contains simulated field device data, such as the primary coolant temperature value. When the test case verifies the SCID's clock synchronization function, the first signal is a clock synchronization signal sent by the test host 101 to the SCID's 485 time synchronization interface through the time synchronization circuit 1025 of the interface adapter device 102.

[0069] S504: The test host 101 controls the image capturing device 104 to capture the screen image of SCID and obtain the first part of the image.

[0070] After the test host 101 controls the operation simulation device to send the first signal to the SCID, it controls the image capturing device 104 to capture the screen image after the SCID responds to the first signal, and uses the image captured at this time as the first part of the image.

[0071] S505: The test host 101 matches the screen content in the first part of the image with the reference screen content corresponding to the first signal to generate a test result.

[0072] The test host 101 analyzes the first part of the image using an AI vision engine to extract interface control information from the image. After the AI ​​vision analysis is completed, the test host 101 enters two parallel processing branches: the result judgment branch and the human factor verification branch.

[0073] In the result judgment branch, the test host 101 automatically compares the extracted screen content with the reference screen content corresponding to the first signal to generate a test result. For example, when the first signal is a mode switching level signal, the reference screen content is the system main interface layout that should be displayed after the SCID successfully switches to the running mode. The test host 101 determines whether the first part of the image contains a combination of characteristic controls of the system main interface; if so, the mode switching function test is deemed successful. When the first signal is a simulated primary coolant temperature of 300℃, the reference screen content is that the temperature value displayed on the SCID screen should be 300℃. The test host 101 uses an AI vision engine to identify the temperature value area displayed in the first part of the image and compares the identified value with 300℃; if they match, the data display function test is deemed successful.

[0074] In the human factors verification branch, the test host 101 performs compliance verification on the SCID's human-machine interface, such as checking whether the layout of interface controls, character size, color coding, and alarm information display conform to human factors engineering standards. The test host 101 can push screenshots and analysis results related to human factors verification to the operation log system and mark it as pending human factors verification evaluation.

[0075] When executing the above test process, the operation object description in the test script uses semantic description rather than fixed coordinates to locate the operation target. Traditional test scripts usually locate the operation target based on absolute screen coordinates. When the SCID interface layout, resolution, or control position changes, all coordinate information in the script becomes invalid. To address this issue, this embodiment defines a test script syntax specification for the nuclear power instrumentation and control testing field. The basic syntax structure of this specification is: "[Step Number]. [Operation Action] [Operation Object Description] [Operation Parameters] [Verification Conditions]". Here, the operation action is a verb selected from a predefined set of operation actions, and the operation object description is a string enclosed in double quotes, which should use the accurate text displayed on the SCID interface or an industry-standard name. The predefined set of operation actions includes interface operation classes, interface operation classes, and control and verification classes. Interface operation classes include, for example, "click" and "input"; interface operation classes include, for example, "power on" and "switch to"; and control and verification classes include, for example, "wait" and "verify".

[0076] The descriptions of operation objects follow a unified standard based on the control type. For example, buttons are written as "Login Button," input boxes as "Username Input Box," and device symbols as "Main Pump Symbol." Taking SCID startup and login testing as an example, a complete test case includes: "1. Power on the SCID device," "2. Wait 30 seconds to verify system startup completion," "3. Switch to running mode," "4. Click the "Login" button," "5. Enter 'admin' in the "Username" input box," "6. Enter '123456' in the "Password" input box," "7. Click the "Confirm" button," and "8. Verify entry into the "System Main Interface." In the above test cases, the descriptions of operation objects for interface operation steps use the text displayed on the control and the control type to locate the operation target, without needing to write screen coordinates. The descriptions of operation objects for interface operation steps use the device name or mode name to locate the operation target, without needing to write hardware register addresses or pin numbers.

[0077] Before the test script is executed, the semantic parsing engine can parse the aforementioned test cases. The parsing process is as follows: First, the semantic parsing engine uses an extended nuclear power domain dictionary to segment and identify terms in the test case text. This domain dictionary includes nuclear power professional terms such as SCID equipment names, operation terms, interface terms, and status terms. Second, the semantic parsing engine categorizes the identified operations into two types based on operation type: interface operations and API operations. For example, "clicking the 'login' button" is classified as an interface operation, and "switching to running mode" is classified as an API operation. Then, the semantic parsing engine uses a deep learning model to perform semantic parsing on the test case text, generating a unified semantic tree structure. The root node of the semantic tree represents the test case, and the child nodes represent the test steps. Each step node contains the operation type, operation object description, operation parameters, and verification conditions. Finally, based on predefined syntax and logic rules, the semantic parsing engine performs post-processing verification and correction on the generated semantic tree to ensure that the parsing results conform to the syntax specifications. Among them, the grammatical rules are the rules defined in the aforementioned grammatical specifications, such as the continuity of step numbers, the legality of operation actions, and the format of operation object descriptions. The logical rules are used to verify the logical consistency between test steps, such as verifying whether a condition is related to the previous operation step. After the above processing, the test cases are converted into a structured sequence of operation steps, which the test host 101 executes sequentially.

[0078] When the test host 101 runs the test script, for interface operation actions, based on the SCID screen image captured in real time by the image capturing device 104, the AI ​​vision engine identifies the interface control in the screen that matches the description of the operation object, obtains the position coordinates of the control in the current screen, and then controls the keyboard and mouse simulator 103 to perform the corresponding operation at those coordinates. When the SCID interface layout or resolution changes, causing the target control to move to a new position in the screen, the AI ​​vision engine re-identifies the control from the new screen image and obtains its new coordinates, without requiring modification to the test script itself.

[0079] In practical applications, the SCID interface may not display the target control in the initial image captured by the image capturing device 104 due to loading or image transmission delays. To address this issue, when the AI ​​vision engine fails to recognize the target interface control in the image, the test host 101 controls the image capturing device 104 to recapture the SCID screen and performs recognition again based on the recaptured image. For example, the test host 101 can automatically retry three times, with a 500-millisecond interval between each retry, recapture the SCID screen and re-recognize it each time. If the target control is still not recognized after three retries, the test host 101 determines that the current test step has failed, records an exception log, and captures the current screen image to save in the test report. Through this retry mechanism, the test system can automatically handle recognition failures caused by accidental factors such as SCID interface loading delays or image transmission delays, avoiding misjudgments due to a single recognition failure and improving the reliability and stability of the test.

[0080] After the test host 101 identifies the target interface control and obtains its position coordinates through the AI ​​vision engine, these coordinates can be converted into physical coordinates executable by the keyboard and mouse simulator 103. Simply taking the geometric center of the bounding box as the operation point for all types of interface controls may result in click failures or accidental touches on adjacent controls. For example, text input boxes often have a clear button or drop-down arrow on the right; clicking the geometric center directly might accidentally touch these controls. Confirm buttons have their geometric center close to the border, so clicking might land on the border and have no effect.

[0081] To address the aforementioned issues, this embodiment employs a four-step dynamic coordinate mapping scheme: calibration, calculation, transformation, and correction. See also... Figure 6 , Figure 6 This is a flowchart illustrating a dynamic coordinate mapping method provided in an embodiment of this application. The method includes the following steps.

[0082] S601: Test host 101 performs coordinate system calibration.

[0083] After the image capturing device 104 is initially installed or its location is changed, the test host 101 executes a coordinate system calibration process. This calibration process may specifically include: the test host 101 controlling the SCID to display a calibration image, which includes multiple calibration points with known physical coordinates. For example, the calibration points may be markers displayed at nine positions on the SCID screen: upper left corner, upper center, upper right corner, left center, center, right center, lower left corner, lower center, and lower right corner, where the physical coordinates of each marker point on the SCID screen are known. The test host 101 controls the image capturing device 104 to capture calibration images. The Hough circle transformation algorithm is used to detect the pixel coordinates of each marker point in the image. Then, the homography transformation algorithm is used to calculate a 3×3 transformation matrix from the image coordinate system to the SCID screen physical coordinate system based on the correspondence between nine sets of pixel coordinates and physical coordinates. Simultaneously, the radial and tangential distortion parameters of the lens of the image capturing device 104 are calculated, and the transformation matrix and distortion parameters are stored in the test system configuration file for subsequent coordinate transformations. In this way, a precise mapping relationship between image coordinates and physical coordinates is established through the calibration process, ensuring the accuracy of coordinates in subsequent operations.

[0084] S602: Test host 101 calculates the coordinates of the operation point according to the type of interface control.

[0085] The test host 101 determines the coordinates of the operation point in the image based on the type of interface control identified by the AI ​​vision engine, using the corresponding operation point calculation rules. (See also...) Figure 7 , Figure 7 This diagram illustrates the operation point calculation rules for different types of interface controls provided in this application. Different control types correspond to different operation point calculation methods. For ordinary button controls, the operation point is the geometric center coordinates of the button. For text input box controls, the operation point is the coordinates of a preset proportion on the left side of the input area, such as 1 / 3, to avoid clicking on a clear button or drop-down button that may exist on the right side of the input box. For checkbox or radio button controls, the operation point is the center coordinates of the box area itself, excluding the label text area. When multiple controls overlap in the interface, the visible area of ​​the topmost control is selected to calculate the operation point; when the target control is only partially visible, the geometric center of the visible part is calculated as the operation point. In this way, adopting a differentiated operation point positioning strategy for different types of controls can avoid the problem of click failure or accidental touch of adjacent controls caused by simply taking the geometric center, thus improving the accuracy and reliability of the operation.

[0086] During the process of AI vision engine recognizing interface controls, situations may arise where multiple controls with identical or similar text exist simultaneously on the interface. For example, in the SCID trend display interface, there might be a "Confirm" button for setting the start time and an "OK" button for setting the range. To address this issue, the test host 101 employs a combination of text matching and feature matching to determine the target interface control. Text matching compares the description text of the operation object in the test script with the control text recognized by the AI ​​vision engine; feature matching is based on features including control category and position context. When multiple controls with identical or similar text exist simultaneously on the interface, the test host 101 can determine the operation context based on the operation steps preceding the operation object description in the test script: if the preceding steps include setting the start time, the target of the current operation is the "Confirm" button corresponding to the start time; if the preceding steps include setting the range, the target of the current operation is the "OK" button corresponding to the range. This resolves the matching ambiguity problem when multiple controls with the same name exist on the interface, improving the accuracy of visual recognition and the reliability of test execution.

[0087] S603: The test host 101 converts the image coordinates into the physical coordinates of the keyboard and mouse simulator 103.

[0088] The test host 101 first uses the calibrated distortion parameters to correct the distortion of the bounding box coordinates of the controls identified by the AI ​​vision engine, eliminating errors caused by lens distortion. Then, it uses the calibrated transformation matrix to convert the corrected image pixel coordinates into physical coordinates of the SCID screen. Finally, it converts the SCID screen physical coordinates into operation coordinates executable by the keyboard and mouse emulator 103. The absolute coordinate range of the keyboard and mouse emulator 103 is 0 to 65535, corresponding to the top left to bottom right corner of the screen. The conversion formula is as follows: mouse_x = (X / screen_width) × 65535; mouse_y = (Y / screen_height) × 65535; Where (mouse_x, mouse_y) are the operation coordinates of the converted keyboard and mouse emulator 103, (X, Y) are the physical coordinates of the SCID screen, and screen_width and screen_height are the physical resolution width and height of the SCID screen.

[0089] S604: Test host 101 performs anti-accidental touch verification and correction on the coordinates of the operation point.

[0090] After calculating the coordinates of the operation point, the test host 101 can also perform the following checks: calculate the minimum distance from the operation point to the boundary of the adjacent control; if the minimum distance is less than a preset threshold (e.g., 5 pixels), the operation point is automatically shifted away from the adjacent control; verify whether the operation point is within the bounding box of the target control; detect whether the target control is occluded by other controls by more than a preset proportion (e.g., 50%); if so, wait for the occluding control to disappear before performing the operation; if the wait times out, record an exception log and skip the current step; check whether the converted keyboard and mouse operation coordinates are within the valid range of 0 to 65535; if they exceed the limit, record an exception log and terminate the current operation. Through the above verification mechanism, erroneous operations caused by coordinate deviations in automated operations can be avoided, improving the stability and reliability of test execution.

[0091] The above verification mechanism avoids erroneous operations caused by coordinate deviations in automated operations, thereby improving the stability and reliability of test execution.

[0092] The above steps S503 to S505 describe the process by which the test host 101 sends a first signal to the SCID and verifies whether the SCID's response to the first signal is correct by capturing and recognizing the screen image. In addition, the test host 101 can also verify whether the signal returned by the SCID through its physical interface is correct. This verification process is independent of the aforementioned verification process of sending the first signal and can be executed individually or in combination, depending on the test case. The following steps describe the process of receiving and verifying the second signal.

[0093] S506: The test host 101 controls the operation simulation device to receive the second signal from the physical interface of SCID.

[0094] After sending the first signal, the test host 101 can also control the simulation device to receive the second signal returned by the SCID from the corresponding physical interface of the SCID. For example, the second signal can be a level signal acquired by the test host 101 from the SCID's GPDO interface through the input circuit 1022 of the interface adapter device 102, used to verify whether the SCID correctly triggered the corresponding output action after responding to the first signal. Alternatively, the second signal can be a data packet received by the test host 101 from the SCID's communication Ethernet port through the Ethernet circuit 1024 of the interface adapter device 102, used to verify whether the SCID correctly returned a data reception acknowledgment message after receiving the simulated data.

[0095] S507: The test host 101 matches the second signal with the reference signal to generate test results.

[0096] The test host 101 can compare the received second signal with a preset reference signal to automatically determine whether the signal returned by SCID through the physical interface is correct. For example, when the test host 101 sends simulated data to SCID, the reference signal is the data reception confirmation message that SCID should return. The test host 101 parses the received second signal through the FPGA chip 1021, compares the parsed data with the reference signal, and if they match, the communication function test is deemed to have passed.

[0097] For interface operation actions, the description of the operation object in the test script can also adopt a semantic description approach. For example, when the test switches the SCID to running mode, the test script can simply write "switch to running mode," without needing to specify the corresponding hardware register address or pin number. When the SCID's interface pin assignment or hardware configuration changes, only the channel mapping relationship of the interface adapter device 102 needs to be updated; the test script itself does not need to be modified. Thus, for SCID physical interface operations, the operation target is also located using semantic description, enhancing the test script's adaptability and stability to hardware configuration changes.

[0098] S508: After the test is completed, the test host 101 controls the interface adapter 102 to disconnect the SCID power supply through the external relay 105 and automatically generate a test report.

[0099] Test host 101 can automatically generate test reports through the data management and report generation subsystem. The report content can include a test overview, execution status of each test case, pass / fail statistics, failure reason analysis, screenshots of key steps, and human factor verification results. In this way, the entire process from device power-on to report generation can be completed automatically by test host 101 without manual intervention, realizing closed-loop automated testing of SCID.

[0100] During test execution, the test host 101 records the entire test process through the operation log module. Nuclear safety-grade equipment testing has strict requirements for traceability; the test log must completely record all operations and cannot be tampered with. The operation log module records each operation log entry in chronological order during the test. Each operation log entry can specifically include the following fields: Operation Time field, used to record the timestamp of the operation execution; Operation Type field, used to record whether this operation is a UI / UX operation or an API operation; Device Interface Identifier field, used to record the physical interface number or control name corresponding to this operation; Control Command field, used to record the specific command content sent by the test host 101 to the operation simulation device; Execution Result field, used to record the result status after the operation execution.

[0101] When generating the current operation log, the operation log module can take the complete content of the previous operation log as input, calculate the log checksum using a hash algorithm, and write the checksum into a predetermined field in the current operation log. When verifying whether a historical operation log has been tampered with, the checksum of that log is recalculated and compared with the checksum stored in the next log entry. If they do not match, the log is determined to have been tampered with. In this way, a chain-like checksum structure can be formed through the associated storage of chained checksums. Tampering with a recorded operation log will cause the checksum to mismatch with the checksum stored in the next log entry, thus ensuring the immutability and integrity of the test log and meeting the traceability requirements of nuclear safety-grade equipment testing.

[0102] The above describes the automated execution process based on semantic scripts in the testing workflow. In practical applications, test scripts can be generated not only through natural language writing but also automatically by recording manual operations. Traditional recording tools typically can only record a single type of operation. Interface operation recording tools can only record keyboard and mouse operations on the screen, while interface operation recording tools can only record control operations of the hardware interface. However, in the SCID testing scenario, interface operations and interface operations alternate. For example, first powering on the SCID, waiting for startup to complete, clicking the login button on the interface, then switching to run mode, and finally entering the username and password. If traditional recording tools are used, testers need to record interface operations and interface operations separately and then manually integrate the two scripts, which is inefficient and prone to errors.

[0103] To address this issue, this embodiment provides cross-device recording functionality. See also... Figure 8 , Figure 8 This is a schematic diagram of the interface layout for a recording mode provided in an embodiment of this application. To implement the recording function, the test host 101 may be configured with a script generation module. In recording mode, two windows are simultaneously displayed on the screen of the test host 101: one is a real-time monitoring window displaying the SCID screen image captured in real time by the image capturing device 104, and the other is an interface control panel for simulating operations on the SCID interface. The interface control panel includes operation controls corresponding to each physical interface of the SCID, such as a working mode switching button, an application mode switching button, and digital output channel status setting controls.

[0104] Testers perform keyboard and mouse operations in the real-time monitoring window, such as clicking buttons on the SCID interface and entering text in input boxes; simultaneously, they perform interface simulation operations on the interface control panel, such as clicking the "Switch to Run Mode" button and setting the status of digital output channels. The script generation module captures both types of operations simultaneously, converting the captured interface operations into interface operation scripts containing operation actions and operation object descriptions, and converting the captured interface operations into interface operation scripts containing operation actions and operation object descriptions. Finally, the interface operation scripts and interface operation scripts are integrated into a unified test script according to the chronological order of the operations.

[0105] In this way, a complete test script containing both interface operations and API operations can be generated with a single recording, eliminating the need for testers to record and manually integrate the two types of operations separately. This solves the problem that existing recording tools can only record a single type of operation, and improves the efficiency and completeness of test script generation.

[0106] The recording mode described above can solve the problem of test script generation efficiency, while the execution of the test script depends on the AI ​​vision model's accurate recognition of SCID interface controls. With the long-term operation of the testing system, the SCID interface may add new control types or introduce new technical terms due to software upgrades. To maintain the recognition accuracy of the AI ​​vision model, it can be fine-tuned using a small number of labeled samples, and the newly learned knowledge can be integrated into the original model through knowledge distillation to avoid catastrophic forgetting and eliminate the need to retrain the entire model. Simultaneously, the testing system supports model version management, allowing rollback to historical versions at any time, ensuring the stability of the testing system.

[0107] Regarding the adaptability of the hardware solution, the above embodiment uses an image capturing device 104 as the means to acquire the SCID screen image. In one possible implementation, when the SCID has a video output interface, the test host 101 can directly capture the SCID's display image through the video output interface without the need for additional image capturing device 104. For example, the SCID may have a video output interface such as HDMI. The test host 101 receives the digital video signal output from the SCID's HDMI interface through a video capture card to obtain the SCID's display image. The subsequent AI visual recognition, coordinate mapping, and result determination processes are the same as when using the image capturing device 104. Thus, when the SCID has a video output interface, the test host 101 can directly acquire the display image through the video output interface, simplifying the hardware configuration of the test system.

[0108] In one possible implementation, the interface adapter device 102 can also be implemented using an industrial-grade programmable logic controller (PLC) in conjunction with an Ethernet communication module and a digital input / output module. The advantages of this alternative are high hardware stability and a short development cycle; the disadvantages are relatively high cost and poor support for SCID proprietary custom protocols.

[0109] In one possible implementation, the power control function can also be implemented using a separate intelligent power module, which can be directly controlled by the test host 101 via a network or serial port. The advantage of this alternative is its comprehensive power protection function; the disadvantage is that it increases the number of hardware components in the test system and makes precise timing synchronization impossible when operating with other interfaces through the same controller.

[0110] The following section uses a specific nuclear power plant testing scenario to further illustrate the complete application process of this embodiment.

[0111] Taking the SCID startup and login function test as an example, testers first write test cases according to the syntax specifications, or generate test scripts through recording mode. The test script includes steps such as "Power on the SCID device", "Wait 30 seconds", "Switch to running mode", "Click the 'Login' button", "Enter 'admin' in the 'Username' input box", "Enter '123456' in the 'Password' input box", "Click the 'Confirm' button", and "Verify and enter the 'System Main Interface'".

[0112] After the test begins, the test host 101 executes S501, which sends an activation signal to the external relay 105 through the digital output channel 7 of the interface adapter device 102, and the SCID is powered on and started.

[0113] The test host 101 executes S502, waits for 30 seconds, and then controls the image capturing device 104 to capture the SCID screen image. The AI ​​vision engine identifies whether the characteristic layout of the system main interface appears in the image. If it is identified, the startup is determined to be complete.

[0114] The test host 101 executes S503, which sends the level signal corresponding to the operating mode to the SCID working mode interface through digital output channel 4, switching SCID from download mode to operating mode.

[0115] Then, the test host 101 executes the interface operation steps sequentially. The test host 101 uses its AI vision engine to identify the coordinates of the "Login" button. After coordinate mapping and anti-mistouch verification via S601 to S604, it controls the keyboard and mouse simulator 103 to click at the correct operation point. In the same way, the test host 101 completes the input of the username and password and the clicking of the confirmation button. After each interface operation, the test host 101 controls the image capturing device 104 to capture the screen image after the SCID response as the first part of the image. The AI ​​vision engine analyzes the image content and compares it with the reference screen image content to verify the correctness of the operation result.

[0116] In the final step, "Verification to enter the system main interface", the AI ​​vision engine performs an overall layout analysis on the first part of the image to determine whether it matches the system main interface features learned during training.

[0117] After all steps are completed, the test host 101 automatically generates a test report and disconnects the SCID power supply through the interface adapter device 102.

[0118] See Figure 9 The diagram shows a hardware structure schematic of a computing device provided in an embodiment of this application. Figure 9 The computing device 900 shown can be used to implement the test host 101 mentioned in the above embodiments. For example... Figure 9 As shown, the computing device 900 includes a bus 901, a processor 902, a memory 903, and a communication interface 904. The processor 902, memory 903, and communication interface 904 communicate via the bus 901. The bus 901 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 901 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus. The communication interface 904 is used to communicate with external devices, such as the interface adapter 102, the keyboard and mouse simulator 103, and the image capturing device 104, to exchange data.

[0119] The processor 902 may be a central processing unit (CPU). The memory 903 may include volatile memory, such as random access memory (RAM); it may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD). The memory 903 stores executable code, which the processor 902 executes to implement the steps performed by the test host 101 in the above-described test method.

[0120] This application also provides a computer-readable storage medium storing instructions that, when executed on a computing device, cause the computing device to perform the steps performed by the test host 101 in the above-described test method.

[0121] This application also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the steps performed by the test host 101 in the above-described test method.

[0122] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A testing system, characterized in that, The testing system includes a testing host, an operation simulation device, and an image capturing device; The operation simulation device is used to send signals to the physical interface of the security control display device SCID under the control of the test host, and is also used to receive signals from the physical interface of the SCID under the control of the test host. The image capturing device is used to capture the screen image of the SCID under the control of the test host, and obtain multiple images including the screen image, the multiple images including a first part image and a second part image; The test host is used to control the operation simulation device to send a first signal to the physical interface of the SCID, control the operation simulation device to receive a second signal from the physical interface of the SCID, and control the image capturing device to capture the screen image of the SCID by running a test script, thereby obtaining multiple images including the screen image. The test host is further configured to generate test results by running test scripts based on the plurality of images, the first signal, and the second signal. The test results are used to indicate whether the screen content in the first part of the images matches the reference screen content corresponding to the first signal, and whether the reference signal corresponding to the second part of the images matches the second signal.

2. The system according to claim 1, characterized in that, The operation simulation device includes an interface adapter or a keyboard and mouse simulator; The interface adapter device is used to send signals to the first physical interface or the second physical interface of the SCID under the control of the test host, and is also used to receive signals from the first physical interface or the second physical interface of the SCID under the control of the test host; wherein, the first physical interface is an interface controlled based on electrical signal status, and the second physical interface is an interface for data interaction based on communication protocol. The keyboard and mouse emulator is used to send signals to the SCID's Universal Serial Bus (USB) interface under the control of the test host.

3. The system according to claim 2, characterized in that, The interface adapter device includes a field-programmable gate array (FPGA) chip, and the interface adapter device also includes at least one of an input circuit, an output circuit, an Ethernet circuit, and a time synchronization circuit; The Ethernet circuit is a circuit for performing Ethernet communication, and the Ethernet circuit is used to send the first signal to the second physical interface of the SCID and to receive the second signal from the second physical interface of the SCID. The input circuit is used to receive the second signal from the first physical interface of the SCID; The output circuit is used to send the first signal to the first physical interface of the SCID; The time synchronization circuit is used to send a clock synchronization signal to the second physical interface of the SCID, and the clock synchronization signal is the first signal.

4. The system according to claim 3, characterized in that, The interface adapter device includes the Ethernet circuit, which includes multiple connection links, including a first part connection link, a second part connection link, and a third part connection link. The FPGA chip communicates with the test host through the first part of the connection link, the FPGA chip is connected to the communication Ethernet port of the SCID through the second part of the connection link, and the FPGA chip is connected to the maintenance Ethernet port of the SCID through the third part of the connection link; wherein, the communication Ethernet port is used to transmit service data, and the maintenance Ethernet port is used to transmit operation and maintenance data.

5. The system according to claim 4, characterized in that, The Ethernet circuit is used to receive a second signal from the SCID and transmit the second signal to the FPGA chip; The FPGA chip is used to parse the second signal based on the communication protocol of the SCID to obtain the data sent by the SCID; The FPGA chip is also used to convert the data to be sent to the SCID into a first signal based on the SCID's communication protocol, and send the first signal to the SCID through the Ethernet circuit.

6. The system according to claim 2, characterized in that, It also includes an external relay connected to the interface adapter, the interface adapter being used to control the power supply to the SCID via the external relay.

7. The system according to any one of claims 1 to 6, characterized in that, The operation object description in the test script is a semantic description of the interface control of the SCID; the test host is also used for: When running the test script, based on the image captured by the image capturing device, the position coordinates of the interface control in the interface are identified by the visual recognition model, and the operation simulation device is controlled to perform the operation corresponding to the position coordinates.

8. The system according to claim 7, characterized in that, The test host is also used for: When the visual recognition model fails to recognize the target interface control in the image, it controls the image capturing device to recapture the screen image of the SCID.

9. The system according to claim 7, characterized in that, The test host also includes an operation log module, which is used to record the operation logs during the test in chronological order, generate log verification values ​​based on adjacent operation logs, and store the log verification values ​​in the next operation log. The operation log includes fields for operation time, operation type, device interface identifier, control command, and execution result.

10. A testing method, characterized in that, The testing method is applied to the test host in the testing system, which also includes an operation simulation device and an image capturing device. The method includes: The test host controls the operation simulation device to send a first signal to the physical interface of the security control display device SCID under test by running a test script; The test host controls the operation simulation device to receive a second signal from the physical interface of the SCID by running the test script; The test host controls the image capturing device to capture the screen image of the SCID by running the test script, and obtains multiple images including the screen image, the multiple images including a first part image and a second part image; The test host generates test results by running the test script based on the first part of the image, the second part of the image, the first signal, and the second signal. The test results are used to indicate whether the screen content in the first part of the image matches the reference screen content corresponding to the first signal, and whether the reference signal corresponding to the second part of the image matches the second signal.

11. A testing system, characterized in that, The testing system includes a testing host and an operation simulation device; The operation simulation device is used to send signals to the physical interface of the security control display device SCID under the control of the test host, and is also used to receive signals from the physical interface of the SCID under the control of the test host. The test host is used to control the operation simulation device to send a first signal to the physical interface of the SCID, control the operation simulation device to receive a second signal from the physical interface of the SCID, and acquire the display screen of the SCID through the video output interface of the SCID to obtain multiple images including the display screen, the multiple images including a first part image and a second part image; The test host is further configured to generate test results by running test scripts based on the plurality of images, the first signal, and the second signal. The test results are used to indicate whether the display content in the first part of the images matches the reference display content corresponding to the first signal, and whether the reference signal corresponding to the second part of the images matches the second signal.

12. A computing device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of claim 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in claim 10.

14. A computer program product, characterized in that, It includes a computer program or computer instructions that, when executed by a processor, implement the method of claim 10.

Images