Automatic testing device and method for custom bus of DCS (Distributed Control System)

Abstract

The invention discloses an automatic testing device and method for a self-defined bus of a DCS, and belongs to the technical field of testing of industrial control systems.The device comprises a controller, an FPGA module, an adapter module, a main control case and a bus adapter card, the FPGA module serves as a lower computer to execute physical layer and data link layer processing of a communication protocol, and achieves electrical matching with a DCS custom bus through an adapter. A customized backboard and a bus adapter card are arranged in the main control case and are used for connecting a to-be-tested main control card, an I / O card and a communication card; the method is based on a layered protocol architecture, LVDS signal transmission and 4B / 5B coding are adopted in a physical layer, CRC32 verification and frame packaging are carried out in a data link layer, and node simulation, message framing, fault insertion and state monitoring are completed in an application layer. The method can effectively solve the problem that the private protocol bus lacks general testing means, and has high expandability and deep testing capability.

Description

Technical Field

[0001] This application relates to the field of testing industrial control systems, and in particular to an automated testing device and method for a custom bus of a DCS system. Background Technology

[0002] In the field of industrial automation control, distributed control systems (DCS) serve as the core control platform of critical infrastructure, and the reliability and stability of their communication buses directly affect the safe operation of the entire industrial process. However, most DCS manufacturers use custom proprietary communication bus protocols. While this design improves system security and specialization, it also presents significant testing challenges. Due to the non-public nature of these protocols, traditional standard bus-based testing equipment cannot be directly adapted, resulting in a lack of effective communication layer verification methods for DCS systems during the R&D, production, and maintenance phases. In summary, existing testing methods for DCS systems still have some shortcomings:

[0003] (1) Lack of testing methods for DCS system communication buses. Since most DCS system communication buses use unpublished proprietary protocols, existing general testing tools and standardized testing methods cannot be directly adapted, resulting in a lack of effective testing solutions.

[0004] (2) Insufficient testing depth and scalability. Currently, most testing systems for DCS products on the market provide standard digital and analog signal sources and then verify the system's output signals through measurement equipment. They lack methods for verifying the reliability of the DCS system's communication bus.

[0005] To address the above issues, this invention utilizes a mature hardware platform and bus architecture widely used in the industry, employing an FPGA (Field Programmable Gate Array) module and an adapter module to develop an automated testing device for a custom bus in a DCS system. This provides a testing method for the custom bus of a DCS system and solves the problems of insufficient testing depth and scalability. Summary of the Invention

[0006] The purpose of this application is to provide an automated testing device and method for a custom bus in a DCS system, which solves the problems of lack of effective testing methods, insufficient testing depth, and poor scalability in the prior art for private communication buses.

[0007] To achieve the above objectives, this application provides the following solution:

[0008] Firstly, this application provides an automated testing device for a DCS system custom bus, comprising:

[0009] The test chassis houses a controller, an FPGA module, and an adapter. The controller runs bus simulation software for managing the test process, configuring communication parameters, sending control commands, and displaying analysis results. The FPGA module communicates with the controller via a standard bus to implement the physical and data link layer functions of a custom bus communication protocol. The adapter connects the FPGA module and the DCS system under test (DUT) to achieve electrical signal matching of the DUT's communication bus. The FPGA module also simulates the main control card sending control messages to the I / O card or communication card, or simulates the I / O card transmitting collected data back to the main control card, based on commands from the controller, enabling bidirectional communication simulation. The received bus data is then parsed according to the protocol and uploaded to the controller for visualization.

[0010] The main control chassis of the DCS system under test has a built-in custom backplane and bus adapter card. The custom backplane provides the power interface, input / output channel interface and communication interface of the DCS system under test, and is used to install and power the main control card, I / O card and communication card of the DCS system under test. The bus adapter card is used to integrate the communication bus of the DCS system under test, and is also used to communicate with the adapter.

[0011] Optionally, the DCS system custom bus automated testing device further includes:

[0012] External measurement tool interface, used to provide corresponding measurement tools according to requirements;

[0013] The measuring tools include: a multimeter and a signal generator.

[0014] Optionally, the FPGA module is further configured with a data encoding / decoding unit, a parallel-to-serial conversion module, a CRC32 check module, and a RAM cache unit, which are used to perform 4B / 5B encoding, NZRI encoding, and CRC check generation on application layer data during transmission, and to complete serial-to-parallel conversion, frame alignment, decoding, and CRC check during reception to ensure data integrity.

[0015] Optionally, the bus emulation software further includes:

[0016] The module includes an engineering management module, a message configuration module, a communication monitoring module, and a fault injection module.

[0017] The project management module is used to load or create project files that contain communication protocol parameters, node address mappings, and test scenarios;

[0018] The message configuration module is used to create test message frames, supporting zero-filling, manual framing, or template import;

[0019] The communication monitoring module is used to display the received message content, communication status, packet loss rate, packet error rate, and out-of-order statistics in real time.

[0020] The fault injection module is used to set error types at the application layer, including source address error, destination address error, data content error, checksum error, and length error, and injects error messages into the bus through the FPGA module.

[0021] Optionally, the custom bus is a proprietary communication protocol based on the LVDS physical layer, and its protocol structure consists of three layers:

[0022] Physical layer: LVDS differential signal transmission is adopted, and 4B / 5B encoding is used to improve the signal anti-interference capability. The parallel-to-serial conversion and clock recovery are completed by the FPGA module.

[0023] Data link layer: Defines the frame format, including start flag, address field, data length, data field and CRC check field. Frame encapsulation, CRC32 calculation and verification are implemented by FPGA module.

[0024] Application layer: Processed by the bus emulation software in the controller, including device configuration initialization check, variable forcing, parameter tuning, diagnostic information reading and quality identification transmission.

[0025] Optionally, the FPGA module is reconfigurable, allowing it to adapt to different types of custom bus protocols by updating its internal logic program.

[0026] Secondly, this application provides an automated testing method for a custom bus in a DCS system, comprising the following steps:

[0027] S1: Start the controller and run the bus simulation software, load the preset project file, which contains the node configuration, communication cycle, protocol parameters and test mode of the system under test;

[0028] S2: Configure the test message to be sent through the bus simulation software, select the simulation role as "master control card", "communication card" or "I / O card", and set the communication cycle and message type;

[0029] S3: The controller sends the test message to be sent to the FPGA module. The FPGA module performs 4B / 5B encoding and NZRI encoding at the physical layer, adds CRC check at the data link layer and encapsulates it into a frame, and sends it to the custom bus through the adapter.

[0030] S4: Receive the response message from the card under test. The FPGA module completes serial-to-parallel conversion and decoding at the physical layer, performs CRC check and frame parsing at the data link layer, and uploads the valid data to the controller.

[0031] S5: The controller parses the received messages at the application layer, determines whether there are packet loss, out-of-order delivery or incorrect packets, and displays the communication status in real time in the graphical interface;

[0032] S6: During the test, a specific error type is set through the fault injection module, and the controller generates an exception message and injects it into the bus through the FPGA module to verify the fault tolerance capability and error handling mechanism of the card under test.

[0033] Optionally, the process may further include the following steps between S2 and S3:

[0034] Frames are segmented according to the line rate, and data blocks to be sent are temporarily stored in RAM and sent sequentially according to time slices to simulate real communication timing.

[0035] Optionally, if the FPGA module detects a CRC check failure or a frame format error in step S4, it records the error type and timestamp, and decides whether to retransmit or discard the frame according to the link management policy. At the same time, the error information is reported to the controller for statistical analysis.

[0036] Optionally, the fault injection in step S6 includes at least one of the following methods:

[0037] Modify the source or destination address in the message to an illegal value;

[0038] Change the content of any byte in the data field;

[0039] Deliberately tamper with the CRC checksum to make it mismatched;

[0040] The message length field does not match the actual data length.

[0041] Custom-construct illegal message frames and force them to be sent.

[0042] According to the specific embodiments provided in this application, this application has the following technical effects:

[0043] This application provides an automated testing device and method for a custom bus in a DCS system, which has the following advantages:

[0044] Filling a testing gap: For the first time, it provides a complete communication layer testing method for DCS private bus, supporting protocol conformance verification and data reliability analysis;

[0045] High testing depth: It not only supports positive verification of bus communication, but also enables various types of fault injection (such as error source, error destination address, type error, data content error, verification error, length error and other fault insertion tests).

[0046] High degree of automation: Complex testing processes can be completed through software configuration, reducing manual intervention and making it suitable for R&D debugging and small-batch production testing;

[0047] High scalability: Based on the reconfigurable characteristics of FPGA, it can be adapted to different protocols by only modifying the software, without changing the hardware platform;

[0048] Integrated design: Supports integration with external metrology tools to build a comprehensive testing system and improve test coverage. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a general block diagram of a DCS system custom bus automated testing device according to an embodiment of this application;

[0051] Figure 2 This is a schematic diagram of the control chassis of a test device provided in one embodiment of this application;

[0052] Figure 3 This is a bus data flow diagram of a test apparatus provided in an embodiment of this application;

[0053] Figure 4 This is a schematic diagram of the engineering interface of a test device according to an embodiment of this application;

[0054] Figure 5 This is a schematic diagram of the communication bus test interface of a test device according to an embodiment of this application. Detailed Implementation

[0055] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

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

[0057] Example 1

[0058] Figure 1This is a general block diagram of a DCS system custom bus automated testing device according to one embodiment of this application. See also: Figure 1 This application proposes an automated testing device that includes a test chassis and a main control chassis of the DCS system under test.

[0059] The test chassis houses the controller, FPGA module, and adapter.

[0060] The controller runs bus simulation software, which is used to manage the test process, configure communication parameters, send control commands, and display the analysis results.

[0061] The FPGA module communicates with the controller via a standard bus to implement the physical layer and data link layer functions of a custom bus communication protocol.

[0062] The adapter is connected between the FPGA module and the DCS system under test to achieve electrical signal matching of the communication bus of the DCS system under test;

[0063] The FPGA module also simulates the main control card sending control messages to the I / O card or communication card, or simulates the I / O card sending collected data back to the main control card, according to the instructions issued by the controller, to realize bidirectional communication simulation, and uploads the received bus data to the controller for visualization display after protocol parsing;

[0064] like Figure 2 As shown, the main control chassis of the DCS system under test has a built-in custom backplane and bus adapter card.

[0065] The customized backplane provides the power interface, input / output channel interface, and communication interface for the device under test (DUT), and is used to install and power the main control card, I / O card, and communication card of the DUT; the bus adapter card is used to integrate the communication bus of the DUT and also to communicate with the adapter.

[0066] Among them, FPGA module refers to Field Programmable Gate Array chip, whose logic functions are written using hardware description language, and the protocol processing unit can be dynamically reconfigured. Adapter refers to electrical signal conversion module, which can employ impedance matching circuits and level conversion chips. Custom backplane refers to dedicated interface board, enabling quick insertion and removal of the board under test. Bus adapter card refers to communication line integration module, specifically using PCB traces to aggregate dispersed RS-485, LVDS, C-BUS, R-BUS, L-BUS, and M-BUS signals to the bus adapter card.

[0067] Specifically, the test chassis establishes a test project and configures the communication cycle and protocol parameters using bus simulation software running on the controller. After receiving commands from the controller, the FPGA module generates differential signals conforming to the characteristics of the custom bus physical layer and simultaneously performs frame encapsulation and verification calculations at the data link layer. The adapter converts the standard LVDS signals output by the FPGA into the electrical characteristics required by the system under test (SUT). The SUT's main control chassis provides DC power to the SUT via a custom backplane, and the bus adapter card integrates the dispersed communication lines into a single interface, connecting to the adapter via shielded twisted-pair cable. During testing, the FPGA module can simulate the main control card sending control commands and simultaneously receive acquired data returned from the I / O card, achieving bidirectional communication verification.

[0068] In some implementations, this application further proposes an external measurement tool interface for providing corresponding measurement tools as needed, including multimeters and signal generators.

[0069] Among them, the external metrology tool interface refers to the standardized physical port used to connect external testing equipment, adapting to the electrical connection requirements of different metrology tools. A multimeter is a portable digital measuring instrument capable of measuring voltage, current, and impedance parameters; specifically, a 6.5-digit high-precision digital multimeter can be used to quantitatively evaluate bus signal quality. A signal generator is a programmable waveform output device; specifically, an arbitrary waveform generator can be used to generate sine waves, square waves, or noise signals to simulate abnormal operating conditions.

[0070] Specifically, the external metrology tool interface is integrated into the test chassis panel, forming a controllable connection with the bus under test (DUT) via a pre-set electrical isolation circuit. During bus communication testing, when verifying physical layer signal integrity, a multimeter connects to the bus differential signal line via the interface to measure signal amplitude, common-mode voltage, and impedance parameters in real time. When simulating electromagnetic interference or signal distortion scenarios, a signal generator injects a noise signal or distorted waveform of preset amplitude into the bus via the interface, triggering the DUT's response under abnormal electrical conditions. Both tools can be used individually or in combination depending on the test requirements; for example, high-frequency interference signals can be injected synchronously during protocol communication to verify the DUT's anti-interference capabilities.

[0071] In some embodiments, this application further proposes that the FPGA module in the DCS system custom bus automated testing device is configured with a data encoding / decoding unit, a parallel-to-serial conversion module, a CRC32 check module, and a RAM cache unit, which are used to perform 4B / 5B encoding, NZRI encoding, and CRC check generation on application layer data during transmission, and to complete serial-to-parallel conversion, frame alignment, decoding, and CRC check during reception to ensure data integrity.

[0072] In summary, the FPGA module simulates the communication bus through a program. The program design includes functions such as data stream encoding, decoding, CRC32 verification, data stream transmission, data stream acquisition, and data flow control. The bus simulation data is transmitted through the backplane communication bus, and the data stream transmission process is as follows: Figure 3 As shown.

[0073] The data encoding / decoding unit refers to the hardware logic unit that performs signal conversion on the raw data. Specifically, it can use 4B / 5B encoding to convert 4-bit data into 5-bit symbols, such as converting the hexadecimal value 0x0A into the binary symbol 10101. Adding redundant bits improves the signal's anti-interference capability. NZRI (Non-Return-to-Zero Inverted Code) encoding refers to a non-return-to-zero inverse encoding method, such as converting a logic "1" into a level transition while "0" remains unchanged. Level switching helps the receiver detect signal changes, reduces bit errors, and improves signal transmission stability. The parallel-to-serial conversion module is a circuit that converts parallel data streams to serial data streams. Specifically, it can use a shift register structure, for example, outputting 32-bit parallel data as a 1-bit serial output, matching the bus physical layer transmission rate and reducing the number of physical connection lines. The CRC32 check module is a widely used check algorithm for detecting errors during data transmission or storage. Specifically, it can use a polynomial algorithm to generate a 32-bit check code. RAM cache units refer to buffers composed of random access memory. Specifically, dual-port RAM can be used to implement asynchronous data read and write operations. For example, data blocks to be processed can be cached at the sending end to ensure that data is sent accurately according to the communication timing.

[0074] In some embodiments, this application further proposes that the bus simulation software also includes a project management module, a message configuration module, a communication monitoring module, and a fault injection module. The project management module is used to load or create project files containing communication protocol parameters, node address mappings, and test scenarios; the message configuration module is used to create test message frames, supporting zero-filling, manual framing, or template import; the communication monitoring module is used to display the received message content, communication status, packet loss rate, error rate, and out-of-order statistics in real time; the fault injection module is used to set error types at the application layer, including source address error, destination address error, data content error, checksum error, and length error, and injects the error messages into the bus through the FPGA module.

[0075] In some implementations, this application further proposes a three-layer architecture for a proprietary communication protocol based on the LVDS physical layer, the protocol structure of which is divided into a physical layer, a data link layer, and an application layer.

[0076] (1) Physical layer: The bus level matching is achieved by an adapter. The FPGA module is responsible for data encoding and decoding, and parallel-to-serial conversion, namely 4B / 5B and NZRI (Non-Return-to-Zero Inverted Code) encoding and decoding. When transmitting, the data is retrieved from RAM, and the frame is segmented and encoded according to constraints such as line rate. Then, the parallel-to-serial conversion is performed and the data is sent to the physical line. When receiving, the data and clock are recovered from the line and aligned for acquisition and serial-to-parallel conversion. The frame is decoded and merged according to the processing of the transmitting end, and written into RAM for transmission to the data link layer.

[0077] (2) Data Link Layer: Responsible for link management, including link establishment and data verification. The data link layer manages the link, including data verification and transmission control. During transmission, data is retrieved from RAM for CRC encoding calculation. After calculation, the data is encapsulated according to the frame format requirements and then transmitted to the physical layer via RAM. During reception, data transmitted from the physical layer to RAM is retrieved, and frame format verification, CRC decoding verification, and arbitration are performed. If correct, the data is transmitted to the application layer via RAM; if errors occur, the link management layer determines how to handle them.

[0078] (3) Application layer: The design of the application layer includes functions such as simulation node selection, message framing, message parsing, message sending, fault injection, and fault monitoring. The application layer data consists of remote control data sent by the controller to the main control card, I / O card and communication card or data collected by I / O and status information of each node, and includes data quality information.

[0079] Specifically, the physical layer uses LVDS communication, improves signal anti-interference capability through 4B / 5B encoding, and the FPGA module completes parallel-to-serial conversion and clock recovery; the data link layer defines the frame format including start flag, address field, data length, data field and CRC check field, and the FPGA module implements frame encapsulation, CRC32 calculation and verification; the application layer is handled by the bus simulation software in the controller, including device configuration initialization check, variable forcing, parameter tuning, diagnostic information reading and quality mark transmission.

[0080] In some implementations, this application further proposes that the FPGA module has reconfigurable characteristics, and can be adapted to different types of custom bus protocols by updating its internal logic program.

[0081] The reconfigurability feature refers to the ability of an FPGA's hardware logic circuits to be dynamically reconfigured according to requirements. Specifically, this can be achieved by reconfiguring the logic gate array using hardware description languages, and by loading different hardware logic programs to change the signal processing flow. This feature enables the same hardware platform to be compatible with the physical layer and data link layer functions of multiple bus protocols.

[0082] Specifically, when adapting to a new type of custom bus protocol is required, a new logic program is generated by rewriting the FPGA's hardware description language code. For example, a new 4B / 5B encoding rule or CRC check algorithm can be defined using VHDL. The updated logic program is downloaded to the FPGA chip via a programming interface, reconstructing its internal data processing path. The reconstructed FPGA module can parse the frame start flag, address field structure, and data field length defined by the new protocol, and generate differential signals that conform to the electrical characteristics of the target protocol. After level matching is completed through the adapter module, the test device can establish communication with the bus node using the new protocol. This dynamic reconstructing mechanism avoids the hardware replacement requirements of traditional test tools due to protocol changes.

[0083] Example 2

[0084] Based on the automated testing device for the custom bus of the DCS system in Embodiment 1, this application further proposes an automated testing method for the custom bus of the DCS system, including the following steps:

[0085] S1: Start the controller and run the bus simulation software, load the preset project file, which contains the node configuration, communication cycle, protocol parameters and test mode of the system under test.

[0086] S2: Configure the test message to be sent through the bus simulation software, select the simulation role as "master control card", "communication card" or "I / O card", and set the communication cycle and message type.

[0087] S3: The controller sends the test message to be sent to the FPGA module. The FPGA module performs 4B / 5B encoding and NZRI encoding at the physical layer, adds CRC check at the data link layer and encapsulates it into a frame, and sends it to the custom bus through the adapter.

[0088] S4: Receive the response message from the card under test. The FPGA module completes serial-to-parallel conversion and decoding at the physical layer, performs CRC check and frame parsing at the data link layer, and uploads the valid data to the controller.

[0089] S5: The controller parses the received messages at the application layer, determines whether there are packet losses, out-of-order packets, or incorrect packets, and displays the communication status in real time in the graphical interface.

[0090] S6: During the test, a specific error type is set through the fault injection module, and the controller generates an exception message and injects it into the bus through the FPGA module to verify the fault tolerance capability and error handling mechanism of the card under test.

[0091] Compared to existing technologies, traditional testing methods rely on manually setting up the test environment and cannot adapt to proprietary protocols. For example, when using a general-purpose protocol analyzer, parsing scripts need to be written manually, and there is a lack of physical layer signal adaptation capabilities. This solution, however, achieves flexible configuration of the protocol stack through a reconfigurable FPGA module. For instance, different encoding methods can be supported simply by updating the hardware description language code. Existing technologies require external signal interference devices for fault simulation, such as physical layer signal injectors, which increases testing costs. This solution, however, constructs abnormal messages directly at the application layer using a software-defined approach. For example, after modifying the data field byte content, the FPGA module completes the protocol encapsulation.

[0092] Through the above technical solutions, this application achieves full-stack automated testing capabilities for custom bus protocols. Regarding protocol adaptation, the challenge of private protocol parsing is solved through physical layer processing of the FPGA module and parameter configuration of the software layer. For communication reliability verification, bus transmission quality can be accurately assessed by real-time statistics of packet loss and error rates. For fault tolerance testing, a software-defined fault injection mechanism can systematically verify the handling logic of the device under test for various abnormal situations such as address errors and checksum errors. The testing process requires no manual intervention; for example, after loading the project file, the system automatically completes the entire process of message sending, response receiving, and result analysis.

[0093] In some implementations, this application further proposes to perform frame segmentation based on the line rate, temporarily store data blocks to be sent in RAM, and send them sequentially according to time slices to simulate real communication timing.

[0094] Line rate refers to the physical layer transmission capacity of the communication link, which can be quantified using link bandwidth and clock frequency parameters. The data segmentation granularity is dynamically adjusted by monitoring the bus load status in real time. Frame segmentation involves splitting the continuous data stream from the application layer into discrete data units that conform to the physical layer transmission capacity. The maximum effective payload length is calculated based on the current line rate, and data is then segmented. RAM caching temporarily stores the segmented data blocks using random access memory. A double buffering mechanism can be used to implement asynchronous writing and synchronous reading, ensuring continuous access and transmission timing control of data blocks. Time-slice transmission divides the communication cycle into discrete time units and schedules data block transmission sequentially. This can be implemented using timer interrupt triggering, with the transmission order managed by configuring the time-slice length and priority queues.

[0095] Specifically, the test data generated by the application layer is first dynamically segmented according to the real-time line rate parameters, forming data blocks that match the transmission capacity of the physical layer. The segmented data blocks are written to the RAM buffer, and a double-buffering mechanism enables asynchronous data writing and reading operations, avoiding data blocking during transmission. The time-slice scheduler divides the communication cycle into multiple equally spaced time units. Within each time slice, a specified number of data blocks are extracted from RAM and sent to the bus in a preset order. The time slice length can be dynamically adjusted according to the test scenario requirements; for example, shortening the time slice to increase the transmission frequency in a high-load scenario and lengthening the time slice to reduce the transmission density in a low-load scenario. This mechanism precisely controls the message interval through discretized time units, replicating the timing fluctuation characteristics caused by node contention and data bursts in a real bus environment.

[0096] In some implementations, this application further proposes that if the FPGA module detects a CRC check failure or a frame format error in step S4, it records the error type and timestamp, and decides whether to retransmit or discard the frame according to the link management policy, while reporting the error information to the controller for statistical analysis.

[0097] Among them, CRC check failure refers to the inconsistency between the cyclic redundancy check code of the received data frame and the calculated value. Specifically, it can be implemented using the CRC32 check module built into the FPGA to verify the integrity of data transmission. The link management strategy refers to the preset retransmission number threshold or error tolerance rules. Specifically, it can be implemented by the controller sending configuration parameters to the FPGA to simulate the error handling mechanism under different communication scenarios.

[0098] In some implementations, this application further proposes setting specific error types through a fault injection module during testing, with the controller generating abnormal messages and injecting them into the bus via the FPGA module to verify the fault tolerance and error handling mechanism of the card under test. Fault injection includes at least one of the following methods: modifying the source or destination address in the message to an illegal value; changing the content of arbitrary bytes in the data field; artificially disrupting the CRC checksum to make it mismatched; adjusting the message length field to be inconsistent with the actual data length; and custom-constructing an illegal message frame and forcibly sending it.

[0099] During practical operation, the testing device software runs normally after logging in. Clicking "Project" in the menu bar and then "Open Project" will bring up the "Open Project" interface, which includes functions such as project name, project path, server IP, server port number, test type, and working mode. See the software interface for details. Figure 4 In the pop-up dialog box prompting for the input file path, select the existing project file, click OK, and then click the Import button to open the project. After successfully importing the project (creating a new project is also supported), a pop-up window will appear. Figure 5The test device's communication bus test interface. Clicking the "Add" button brings up the "Add Message" dialog box, which supports operations such as generating all-zero data messages, data framing, and data clearing, ultimately creating a test message data frame.

[0100] The automated test device for the custom bus of the DCS system has developed a variety of test options, realizing functions such as monitoring communication data of the DCS system main control card, I / O card and communication card, sending control messages, receiving and parsing message information, and detecting communication fault insertion. It provides a test method for effectively evaluating and verifying the reliability of the custom bus communication of the DCS system, and can be applied to product testing and production testing of DCS system main control card, I / O card and communication card.

[0101] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0102] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An automated testing device for a DCS system custom bus, characterized in that, The DCS system custom bus automated testing device includes: The test chassis houses a controller, an FPGA module, and an adapter. The controller runs bus simulation software for managing the test process, configuring communication parameters, sending control commands, and displaying analysis results. The FPGA module communicates with the controller via a standard bus to implement the physical and data link layer functions of a custom bus communication protocol. The adapter connects the FPGA module and the DCS system under test (DUT) to achieve electrical signal matching of the DUT's communication bus. The FPGA module also simulates the main control card sending control messages to the I / O card or communication card, or simulates the I / O card transmitting collected data back to the main control card, based on commands from the controller, enabling bidirectional communication simulation. The received bus data is then parsed according to the protocol and uploaded to the controller for visualization. The main control chassis of the DCS system under test has a built-in custom backplane and bus adapter card. The custom backplane provides the power interface, input / output channel interface and communication interface of the DCS system under test, and is used to install and power the main control card, I / O card and communication card of the DCS system under test. The bus adapter card is used to integrate the communication bus of the DCS system under test, and is also used to communicate with the adapter.

2. The automated testing device for a custom bus in a DCS system according to claim 1, characterized in that, The DCS system custom bus automated testing device also includes: External measurement tool interface, used to provide corresponding measurement tools according to requirements; The measuring tools include: a multimeter and a signal generator.

3. The DCS system custom bus automated testing device according to claim 1, characterized in that, The FPGA module is also equipped with a data encoding / decoding unit, a parallel-to-serial conversion module, a CRC32 check module, and a RAM cache unit. These are used to perform 4B / 5B encoding, NZRI encoding, and CRC check generation on application layer data during transmission, and to complete serial-to-parallel conversion, frame alignment, decoding, and CRC check during reception to ensure data integrity.

4. The automated testing device for a custom bus in a DCS system according to claim 1, characterized in that, The bus emulation software also includes: The module includes an engineering management module, a message configuration module, a communication monitoring module, and a fault injection module. The project management module is used to load or create project files that contain communication protocol parameters, node address mappings, and test scenarios; The message configuration module is used to create test message frames, supporting zero-filling, manual framing, or template import; The communication monitoring module is used to display the received message content, communication status, packet loss rate, packet error rate, and out-of-order statistics in real time. The fault injection module is used to set error types at the application layer, including source address error, destination address error, data content error, checksum error, and length error, and injects error messages into the bus through the FPGA module.

5. The automated testing device for a custom bus in a DCS system according to claim 1, characterized in that, The custom bus is a proprietary communication protocol based on the LVDS physical layer, and its protocol structure consists of three layers: Physical layer: LVDS differential signal transmission is adopted, and 4B / 5B encoding is used to improve the signal anti-interference capability. The parallel-to-serial conversion and clock recovery are completed by the FPGA module. Data link layer: Defines the frame format, including start flag, address field, data length, data field and CRC check field. Frame encapsulation, CRC32 calculation and verification are implemented by FPGA module. Application layer: Processed by the bus emulation software in the controller, including device configuration initialization check, variable forcing, parameter tuning, diagnostic information reading and quality identification transmission.

6. The automated testing device for a custom bus in a DCS system according to claim 1, characterized in that, The FPGA module is reconfigurable, and can be adapted to different types of custom bus protocols by updating its internal logic program.

7. An automated testing method for a custom bus in a DCS system, characterized in that, The DCS system custom bus automated testing method is applied to the DCS system custom bus automated testing device as described in any one of claims 1-5, and the DCS system custom bus automated testing method includes the following steps: S1: Start the controller and run the bus simulation software, load the preset project file, which contains the node configuration, communication cycle, protocol parameters and test mode of the system under test; S2: Configure the test message to be sent through the bus simulation software, select the simulation role as "master control card", "communication card" or "I / O card", and set the communication cycle and message type; S3: The controller sends the test message to be sent to the FPGA module. The FPGA module performs 4B / 5B encoding and NZRI encoding at the physical layer, adds CRC check at the data link layer and encapsulates it into a frame, and sends it to the custom bus through the adapter. S4: Receive the response message from the card under test. The FPGA module completes serial-to-parallel conversion and decoding at the physical layer, performs CRC check and frame parsing at the data link layer, and uploads the valid data to the controller. S5: The controller parses the received messages at the application layer, determines whether there are packet loss, out-of-order delivery or incorrect packets, and displays the communication status in real time in the graphical interface; S6: During the test, a specific error type is set through the fault injection module, and the controller generates an exception message and injects it into the bus through the FPGA module to verify the fault tolerance capability and error handling mechanism of the card under test.

8. The automated testing method for a custom bus in a DCS system according to claim 7, characterized in that, Between step S2 and step S3, the following is also included: Frames are segmented according to the line rate, and data blocks to be sent are temporarily stored in RAM and sent sequentially according to time slices to simulate real communication timing.

9. The automated testing method for a custom bus in a DCS system according to claim 7, characterized in that, If the FPGA module detects a CRC check failure or a frame format error in step S4, it records the error type and timestamp, and decides whether to retransmit or discard the frame according to the link management policy. At the same time, the error information is reported to the controller for statistical analysis.

10. The automated testing method for a custom bus in a DCS system according to claim 7, characterized in that, The fault injection in step S6 includes at least one of the following methods: Modify the source or destination address in the message to an illegal value; Change the content of any byte in the data field; Deliberately tamper with the CRC checksum to make it mismatched; The message length field does not match the actual data length. Custom-construct illegal message frames and force them to be sent.

Images