Industrial protocol heterogeneous network p4 program verification method, device and equipment and medium

Abstract

This invention belongs to the field of software testing technology and discloses a method, apparatus, device, and medium for verifying P4 programs in heterogeneous industrial protocol networks. The method involves acquiring the program to be verified and its reference program, and deploying them on a programmable switch and a hardware platform respectively to construct a test environment; generating diverse test data packets based on industrial protocol conversion requirements and simultaneously sending them to the two test environments; adaptively matching differentiated comparison rules and fault-tolerance strategies based on the characteristics of different protocol layers using the data packets output by both parties; and finally generating a test report based on the layered comparison results. This method, by constructing a verification environment based on standard hardware and combining a layered comparison mechanism, can accurately identify program deviations at different data levels. Combined with comprehensive test cases for program error analysis, it significantly improves the sufficiency and reliability of verifying heterogeneous network programs in industrial scenarios, effectively ensuring their stable operation after deployment in critical industrial environments.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method, apparatus, equipment and medium for verifying P4 programs in heterogeneous industrial protocol networks. Background Technology

[0002] In the context of intelligent development in modern manufacturing, large production workshops integrate a large number of industrial devices from different manufacturers to achieve efficient collaborative operations, forming a complex and interconnected production system. However, because various devices typically use their own proprietary communication protocols, direct communication and collaboration between devices are impossible. To address this protocol heterogeneity issue, traditional solutions rely on deploying multiple dedicated hardware gateways, but these solutions suffer from limitations such as high cost and poor flexibility.

[0003] In recent years, the deepening of the software-defined networking concept, especially the emergence of programmable gateway switches based on the P4 (Programming Protocol-independent Packet Processors) language, has provided an innovative solution to this problem. P4-based programmable switches can serve as a general-purpose protocol conversion platform, dynamically defining their processing logic for various industrial protocol messages through software programming. This replaces a large number of dedicated gateways, achieving hardware-software decoupling and high flexibility of network functions. While P4 technology has a promising future, its core feature of software-based complex network functions also introduces new and serious challenges. The intelligent behavior of a P4 gateway is entirely defined by the program code written by engineers, and its correctness and reliability directly determine the stability of the underlying industrial network.

[0004] Therefore, how to conduct sufficient, efficient and reliable functional correctness verification of P4 programs before deploying them to actual production environments, and ensure that their behavior meets expectations, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, device, and medium for verifying P4 programs in heterogeneous industrial protocol networks. The aim is to solve the technical problem in the prior art of how to fully, efficiently, and reliably verify the functional correctness of P4 programs before deploying them to the actual production environment, and ensure that their behavior meets expectations.

[0006] To achieve the above objectives, this application proposes a method for verifying P4 programs in heterogeneous industrial protocol networks, the method comprising: Obtain the P4 program to be verified and the corresponding reference hardware description language program; The P4 program to be verified is loaded into the P4 programmable switch as the entity to be verified, and the hardware description language program is loaded into the FPGA hardware platform as the reference entity. Generate test stimulus data packets based on the industrial protocol conversion requirement information; The test stimulus data packet is synchronously sent to the entity to be verified and the reference entity to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity. Based on the actual data packet and the reference data packet, a hierarchical confidence comparison model is used to compare them to obtain the hierarchical comparison results. Based on the hierarchical comparison results, a test report for the P4 program to be verified is generated.

[0007] Optionally, generating a test stimulus data packet based on the industrial protocol conversion requirement information includes: The industrial protocol conversion requirement information is parsed to determine the industrial protocol involved in the P4 program to be verified; Based on the syntax structure of the industrial protocol involved in the P4 program to be verified, determine the protocol fields of the data packet to be constructed; Based on the test requirement information and the protocol fields, a test stimulus data packet is generated.

[0008] Optionally, generating a test stimulus data packet based on the test requirement information and the protocol fields includes: Based on the protocol fields, corresponding standardized message data packets are generated one by one for each industrial protocol involved in the P4 program to be verified; Based on the field boundary values ​​and length constraints in the industrial protocol conversion requirement information, generate a boundary test data packet; Based on the flow timing characteristics of the simulated industrial site in the industrial protocol conversion requirement information, a robust test data packet is generated. The standardized message data packet, the boundary test data packet, and the robustness test data packet are used as the test stimulus data packet.

[0009] Optionally, the step of comparing the actual data packet with the reference data packet using a hierarchical confidence comparison model to obtain the hierarchical comparison result includes: Based on the actual data packet and the reference data packet, the protocol stack is decoded to obtain the corresponding multi-layer protocol fields; Based on the predefined hierarchical comparison strategy, determine the field matching rules and fault tolerance parameters corresponding to each protocol level; Based on the matching rules and fault tolerance parameters, the fields of each protocol layer are compared and confidence is evaluated in sequence to obtain the hierarchical confidence. The stratified confidence scores are integrated to obtain the stratified comparison results.

[0010] Optionally, determining the field matching rules and fault tolerance parameters corresponding to each protocol layer according to a predefined hierarchical comparison strategy includes: if the protocol layer is a physical layer protocol field, then performing byte-by-byte verification according to strict bit-level comparison rules; If the protocol level is a data link layer protocol field, then the media access control address, Ethernet type, and virtual LAN label in the field are verified byte by byte using strict field-level comparison rules; If the protocol layer is a network layer and transport layer protocol field, then the checksum and time-to-live value in the field are checked byte by byte using the fault tolerance threshold comparison rule; If the protocol level is an application layer protocol field, then the protocol-specific command code and register address in the field are parsed and compared using semantic consistency comparison rules.

[0011] Optionally, generating a test report for the P4 program to be verified based on the hierarchical comparison results includes: The hierarchical comparison results are subjected to statistical processing of failed test cases to obtain a set of failed test cases and difference data. Based on predefined error types, the failed test case set and difference data are classified to obtain program error statistics. The error statistics of the program are processed to perform root cause analysis and optimization suggestions to obtain problem analysis and optimization guidance information. The failed test case set, classification error statistics, and problem analysis and optimization guidance information are processed into a report to obtain the test report of the P4 program to be verified.

[0012] Optionally, the step of performing error classification processing on the failed test case set and difference data based on predefined error types to obtain program error statistics results includes: Based on the predefined error types and the difference data, attribute discrimination is performed on the differences in the data packets to obtain a set of difference information labeled with error types; Based on the set of failed test cases and the set of difference information, perform an association mapping between test cases and error types to obtain the error classification results corresponding to each test case; Based on the error classification results, the frequency and distribution of each type of error in the test cases are statistically analyzed to obtain test error statistics. Based on the test error statistics, a summary of program error statistics results, including details of the error type distribution, is generated.

[0013] Furthermore, to achieve the above objectives, this application also proposes an industrial protocol heterogeneous network P4 program verification device, which includes: The program acquisition module is used to acquire the P4 program to be verified and the corresponding reference hardware description language program. The environment deployment module is used to load the P4 program to be verified onto the P4 programmable switch as the entity to be verified, and to load the hardware description language program onto the FPGA hardware platform as the reference entity. The test case generation module is used to convert requirement information according to industry protocols and generate test stimulus data packages. The test execution module is used to synchronously send the test stimulus data packet to the entity to be verified and the reference entity, so as to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity. The result comparison module is used to compare the actual data packet with the reference data packet using a hierarchical confidence comparison model to obtain the hierarchical comparison result. The report generation module is used to generate a test report for the P4 program to be verified based on the hierarchical comparison results.

[0014] Furthermore, to achieve the above objectives, this application also proposes an industrial protocol heterogeneous network P4 program verification device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the industrial protocol heterogeneous network P4 program verification method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the industrial protocol heterogeneous network P4 program verification method described above.

[0016] The technical solution of this application includes: acquiring the P4 program to be verified and the corresponding reference hardware description language program; loading the P4 program to be verified onto a P4 programmable switch as the entity to be verified, and loading the hardware description language program onto an FPGA hardware platform as a reference entity; generating test stimulus data packets according to industrial protocol conversion requirement information; synchronously sending the test stimulus data packets to the entity to be verified and the reference entity to obtain the actual data packets output by the entity to be verified and the reference data packets output by the reference entity; comparing the actual data packets and the reference data packets using a hierarchical confidence comparison model to obtain hierarchical comparison results; and generating a test report for the P4 program to be verified based on the hierarchical comparison results.

[0017] The present application proposes one or more technical solutions, which have at least the following technical effects: This invention fundamentally guarantees the accuracy of verification results by using a hardware-verified reference program as a comparison benchmark. By analyzing protocol conversion requirements and constructing diverse test stimuli covering standardization, boundary conditions, and robustness, it ensures the comprehensiveness of the test. Its core hierarchical confidence comparison model can apply differentiated rules such as bit-level strict verification, fault tolerance threshold comparison, or semantic consistency parsing to the field characteristics of different protocol layers, including the physical layer, data link layer, network transport layer, and application layer. This enables precise location and evaluation of program behavior deviations, avoiding misjudgments. Combined with automatic classification and root cause analysis of failed test cases, this method significantly improves the depth and automation of verification, providing strong assurance for the functional correctness of the P4 program in industrial networks and reducing deployment risks. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 A flowchart illustrating the first embodiment of the industrial protocol heterogeneous network P4 program verification method of this application; Figure 2 This is a flowchart illustrating Embodiment 2 of the industrial protocol heterogeneous network P4 program verification method of this application; Figure 3 A schematic diagram of the hardware simulation system provided for the P4 program verification method for industrial protocol heterogeneous networks in this application; Figure 4 This is a schematic diagram of the module structure of the P4 program verification device for industrial protocol heterogeneous networks, as described in an embodiment of this application. Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the P4 program verification method for industrial protocol heterogeneous networks in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] Currently, in the context of the Industrial Internet and intelligent manufacturing, production workshops integrate a large number of devices using various communication protocols, forming complex heterogeneous networks. The P4 language, due to its highly programmable data plane, provides a new technical path for achieving flexible and efficient industrial protocol conversion. However, the correctness of a P4 program depends entirely on its code logic. Any potential programming oversight or logical deviation, once deployed to the industrial field, could lead to serious consequences such as communication interruptions and control command errors, threatening production safety and stability.

[0025] Traditional P4 program verification methods have inherent limitations: First, they rely heavily on software simulation or formal verification, which struggle to fully simulate the asynchronous and concurrent processing characteristics of data packets in real network environments and the subtle differences in their interaction with hardware, resulting in insufficient verification sufficiency. Second, they lack a universally accepted and credible standard as a benchmark for behavioral comparison, casting doubt on the authority and credibility of the verification results. Third, even if tests are passed, traditional comparison methods often remain at the overall packet level, failing to accurately pinpoint which specific layer of the protocol stack's processing logic has deviated, making program debugging and optimization difficult. Therefore, establishing a verification method that can fully simulate the real environment, possess a credible benchmark, and perform in-depth fault diagnosis before P4 programs are put into actual operation is a pressing technical problem in this field.

[0026] This application provides a solution aimed at addressing the technical problem of the lack of a method in the prior art that can combine the reliability of hardware-in-the-loop testing with hierarchical and refined comparison capabilities to perform comprehensive and in-depth verification of P4 programs in heterogeneous industrial protocol networks.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an industrial protocol heterogeneous network P4 program verification device capable of performing the above functions. The following description uses an industrial protocol heterogeneous network P4 program verification device as the executing entity to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a method for verifying P4 programs in heterogeneous industrial protocol networks, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the P4 program verification method for heterogeneous industrial protocol networks in this application.

[0029] In this embodiment, for ease of description, the following description uses the P4 program verification device for heterogeneous industrial protocol networks as the execution subject.

[0030] In this embodiment, the industrial protocol heterogeneous network P4 program verification method includes steps S10 to S50: Step S10: Obtain the P4 program to be verified and the corresponding reference hardware description language program.

[0031] It should be noted that, in practical implementation, the P4 program to be verified refers to the source code written by the user to implement specific industrial protocol conversion functions. P4 (Programming Protocol-independent Packet Processors) is a high-level programming language used to program and control the behavior of network data plane devices (such as switches, routers, and network interface cards). Its core idea is that network administrators or developers can define how network devices process data packets, rather than passively accepting the fixed functions preset by the device manufacturer.

[0032] Understandably, the P4 language itself is abstract, describing the "logic" of packet processing (parsing, modification, and forwarding). This logic can be compiled and deployed to various types of hardware targets. For example, software switches (such as BMV2) are often used for rapid prototyping and testing; FPGAs (Field-Programmable Gate Arrays) are often used for customized needs; and dedicated integrated circuits are often used in data centers or high-performance networks. This target independence allows the same P4 program code to run on platforms with different performance and cost profiles, greatly enhancing portability. In this application, the core objective is to verify whether the behavior of a user-written P4 program meets expectations through hardware simulation verification (using FPGA hardware-in-the-loop testing).

[0033] It should be understood that the selection or development of the reference hardware description language program (such as Verilog or VHDL code) must precisely implement the same industrial protocol conversion function specification as the P4 program to be verified. For example, if the goal of the P4 program is to map the cyclic service data unit of a Profinet IO data frame to the implicit connection transmission data of EtherNet / IP, then the reference program must also implement the exact same semantic mapping logic on the FPGA using a hardware description language. In a real-world scenario, this program should be a trustworthy design whose behavior has been verified to conform to industrial protocol standards on the target FPGA platform through other reliable means (such as detailed simulation and hardware test bench testing).

[0034] In a preferred embodiment, the P4 program to be verified and the reference hardware description language program can originate from different implementations of the same high-level functional specification. The development process can begin with developing a P4 implementation (for programmable switches) and an HDL implementation (for FPGAs) independently, based on the same detailed design document. Initially, the relatively easier-to-verify HDL implementation can be used as a reference to verify the more flexible but potentially soft-fault-inducing P4 implementation. This cross-implementation comparison approach can effectively identify logical errors caused by differences in programming models, compilers, or developer misunderstandings.

[0035] Step S20: Load the P4 program to be verified onto the P4 programmable switch as the entity to be verified, and load the hardware description language program onto the FPGA hardware platform as the reference entity.

[0036] It should be noted that, in practice, this step involves two core actions: First, the P4 program to be verified is compiled using the appropriate software toolchain and loaded into a physical switch that supports P4 programming, making it the entity to be verified. Then, the hardware description language program serving as the reference standard is synthesized and placed and routed to generate a bitstream file, which is then ported to the FPGA hardware platform, making it the reference entity.

[0037] Understandably, the core principle behind this approach lies in constructing a controlled hardware-in-the-loop test environment. Since the reference entity is a hardware design running on an FPGA, its packet processing timing, parallelism, and determinism more closely resemble the final deployment scenario, making it far more realistic than software simulators based on general-purpose processors. By feeding the same network traffic to both entities through a stimulus generator and comparing their output responses, the approach essentially uses verified hardware behavior as a benchmark to measure the correctness of the P4 program under real network stress. This direct benchmarking of hardware behavior effectively exposes deep-seated concurrency and timing-related errors that are difficult to detect through software simulation.

[0038] It should be understood that choosing FPGA as the hardware-in-the-loop verification platform is based on its comprehensive advantages in performance, determinism, and reconfigurability. Compared to software simulation, FPGA can provide line-rate packet processing capabilities, precise timing behavior, and physical interface characteristics in a real hardware environment, which is crucial for verifying the real-time performance and correctness of P4 data plane programs. Simultaneously, the programmability of FPGA allows for the flexible implementation of specific industrial protocol stacks, making it suitable as a rigorously validated reference model. Compared to application-specific integrated circuits (ASICs), FPGA ensures hardware-level realism while avoiding the inherent limitations caused by differences in protocol standards or customization requirements. Therefore, using FPGA is an effective technical path for verifying P4 programs in high-reliability industrial network environments.

[0039] Step S30: Generate a test stimulus data packet based on the industrial protocol conversion requirement information.

[0040] It should be noted that the industrial protocol conversion requirement information refers to the complete technical specifications that clearly define the protocol types, data formats, state transition logic, and expected functions that the P4 program to be verified needs to handle. In practice, a dedicated test case generator can be used to construct raw protocol data frames covering different scenarios such as normal operation, boundary conditions, abnormal situations, and error injection based on this requirement information. For example, to verify a program that converts Modbus TCP packets into Profinet IO frames, the generator needs to create standard Modbus request packets containing valid function codes, register addresses, and data, as well as invalid data packets such as those with incorrect formats or excessive lengths, as the stimulus source.

[0041] In one embodiment, generating a test stimulus data packet based on industrial protocol conversion requirement information includes: parsing the industrial protocol conversion requirement information to determine the industrial protocol involved in the P4 program to be verified; determining the protocol fields of the data packet to be constructed based on the syntax structure of the industrial protocol involved in the P4 program to be verified; and generating a test stimulus data packet based on the test requirement information and the protocol fields.

[0042] Understandably, the sufficiency and realism of test stimuli are crucial to the validity of verification. Stimulus packets must comprehensively and accurately reflect possible inputs in an industrial environment, and their generation logic must strictly adhere to the official standard specifications of the target industrial protocol. This includes not only constructing syntactically correct packets but, more importantly, simulating the protocol's state machine behavior and semantic logic, such as timing-related sequences like connection establishment, periodic data exchange, and diagnostic message interaction. High-quality test stimuli force the P4 program to be verified and the reference entity to execute their core logic paths, thereby exposing potential functional deviations. This step aims to create a high-fidelity simulated network environment, ensuring the high reliability of subsequent comparison results.

[0043] In one embodiment, generating test stimulus data packets based on test requirement information and the protocol fields includes: generating corresponding standardized message data packets for each industrial protocol involved in the P4 program to be verified, according to the protocol fields; generating boundary test data packets according to the field boundary values ​​and length constraints in the industrial protocol conversion requirement information; generating robustness test data packets according to the traffic timing characteristics of the simulated industrial site in the industrial protocol conversion requirement information; and using the standardized message data packets, boundary test data packets, and robustness test data packets as the test stimulus data packets.

[0044] It should be understood that test stimulus generation is a configurable and scalable process. To ensure the rigor of verification, the stimulus packet set needs to systematically cover equivalence class partitioning and boundary value analysis to avoid test blind spots. In a preferred embodiment, a template-based generation method can be used, abstracting the protocol format into a populateable template, and quickly generating a large number of variant test cases through parameterization. Simultaneously, stimulus generation should consider its connection with subsequent steps, such as adding a unique identifier sequence number or timestamp to each packet to facilitate accurate correlation and correspondence during response comparison, ensuring accurate tracking of each request-response pair even under high-speed data flow.

[0045] Step S40: The test stimulus data packet is synchronously sent to the entity to be verified and the reference entity to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity.

[0046] It's important to note that synchronous transmission refers to ensuring, through a precise timing control mechanism, that identical test stimulus data packets are delivered simultaneously to the input ports of both the entity to be verified and the reference entity. This process is typically executed by a high-performance test instrument or a precisely programmed controller, which employs hardware-level synchronization signals or high-precision clocks to eliminate timing deviations caused by software scheduling or other system delays. For example, the two ports of the test instrument can be configured to be controlled by the same trigger signal, thus mirroring each data packet copy and simultaneously injecting it into both the program to be verified and the hardware design serving as the gold standard.

[0047] Understandably, industrial network protocols, especially those involving real-time control, are extremely sensitive to timing. Even a tiny difference in transmission time can cause the internal state machines of two entities to run at inconsistent paces, resulting in different outputs. This difference does not stem from functional errors but from interference introduced by the testing method. Therefore, the goal of the synchronization mechanism is to ensure that the two entities are in the same relative time environment and data flow pressure when processing each frame of data, thereby ensuring that any subsequently observed output differences can be accurately attributed to functional deviations in the logical implementation of the entity being verified.

[0048] Step S50: Based on the actual data packet and the reference data packet, a hierarchical confidence comparison model is used to compare them to obtain the hierarchical comparison result.

[0049] It should be noted that the hierarchical confidence comparison model used in this step is the core judgment mechanism of this verification method, and its design stems from the strict hierarchical structure of industrial protocols. This model refers to a structured, multi-granular analysis framework. Specifically, it first performs strict bit-level and field-level comparisons at the most basic physical and data link layers to ensure complete consistency of the original format and basic addressing information of the data frames. At the network and transport layers, a fault-tolerance threshold mechanism is introduced to tolerate fields such as time-to-live or checksums that may undergo minor changes due to legitimate reasons. Finally, at the application layer, the focus is on the consistency judgment of protocol semantics, parsing and comparing key business information such as industrial instructions, register addresses, and function codes. Each level of comparison generates a quantified confidence score to accurately characterize the degree of conformity between the actual data packet and the reference data packet at that level.

[0050] Understandably, the purpose of employing this layered comparison strategy is to achieve a refined and contextualized assessment of the correctness of protocol conversion functions. The reliability of industrial protocols not only requires the accuracy of data content but also emphasizes strict adherence to protocol timing, state, and semantics in complex field environments. For example, an industrial message carrying an emergency stop command, even if its payload data bytes are perfectly accurate, will fail to detect a significant performance defect if its transmission delay exceeds the maximum response time specified by the protocol through simple full-text comparison. A layered confidence model, however, can accurately capture and label this problem in the timing analysis at the network or application layer. This capability greatly enhances the depth and engineering practical value of the verification results.

[0051] It should be understood that the final hierarchical comparison results are key diagnostic information guiding design optimization. This result is a structured, weighted diagnostic report.

[0052] In a preferred embodiment, the system comprehensively calculates the confidence scores of each layer based on a preset weighting strategy (e.g., requiring 100% bit matching at the lower layer and allowing a semantic matching score of 99.5% or higher at the higher layer) to arrive at an overall verification conclusion. This detailed report not only indicates whether the functionality meets the standards but also precisely locates the protocol layer, specific field, and type and severity of the deviation, such as "application layer EtherCAT command code response timeout." This provides developers with clear and efficient guidance for quickly diagnosing P4 program defects and making targeted optimizations, forming a closed-loop feedback loop from verification to optimization.

[0053] Step S60: Based on the hierarchical comparison results, generate a test report for the P4 program to be verified.

[0054] It's important to note that the test report is a decision-making process involving in-depth analysis and structured integration of layered confidence data. This report is a comprehensive document containing a test overview, detailed results, error analysis, and optimization suggestions. The generation process first automatically assesses the layered results obtained in the previous steps based on a preset confidence threshold strategy. For example, it explicitly requires 100% matching between the physical layer and data link layer, while allowing for a preset range of error tolerance for layers such as the network layer. The system then tallies key metrics such as the total number of test cases and the pass rate. Based on an error classification engine, it categorizes and counts discovered deviations according to predefined types such as data tampering, response timeouts, and protocol semantic errors, thus forming a comprehensive summary of the testing activities.

[0055] Understandably, the core value of this test report lies in its powerful diagnostic and guidance capabilities. The report not only presents the "what" results but also delves into the "why" and "how to improve." For example, when the report points out a large number of semantic consistency errors in the application layer, it further connects these errors to specific test stimulus scenarios, analyzing that these errors may be concentrated in the control command conversion process of a particular industrial protocol, and speculating that this is due to incomplete state machine logic in the program under test.

[0056] It should be understood that this root cause analysis transforms vague failure results into clear diagnostic opinions, allowing developers to skip the tedious data analysis process and directly focus on optimizing the code modules most likely to malfunction, greatly improving debugging efficiency.

[0057] This embodiment constructs a collaborative verification environment consisting of a programmable switch loaded with the P4 program to be verified and an FPGA platform loaded with a reference hardware description language program. The method generates high-fidelity test stimulus data packets and synchronously injects them into the two entities. Subsequently, a hierarchical confidence comparison model is used to perform multi-granular analysis on the output data of both entities, from physical layer bits to application layer semantics. Finally, a test report containing detailed diagnostic information is generated based on the comparison results.

[0058] In summary, by employing an FPGA-based hardware platform for in-loop verification, the timing determinism of data processing closely matches that of the real hardware environment, effectively overcoming the limitations of pure software simulation in terms of performance and timing accuracy, thereby enhancing the credibility of the verification results. Furthermore, the hierarchical confidence comparison strategy can precisely pinpoint the protocol level and specific cause of deviations, rather than simply providing a general pass or fail conclusion. This allows developers to quickly diagnose and optimize program defects, significantly improving debugging efficiency. The entire process automates from test stimulus generation to result analysis reporting, reducing manual intervention, ensuring the consistency and repeatability of the verification process, and overall improving the reliability and efficiency of industrial protocol conversion function development.

[0059] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S50 in the industrial protocol heterogeneous network P4 program verification method includes steps S501 to S504: Step S501: Decode the protocol stack according to the actual data packet and the reference data packet to obtain the corresponding multi-layer protocol fields.

[0060] It should be noted that this step involves structurally separating the mixed binary data stream in the original data packet according to the hierarchical relationship of the standard network communication model. The decoder will, according to the preset protocol specifications, start from the physical layer signal characteristics, and sequentially identify and peel off the data link layer frame header, network layer header, transport layer segment header, and finally reach the application layer payload, thereby parsing a single data packet into a series of protocol fields belonging to different logical layers and with clear meanings.

[0061] Understandably, this process is crucial in employing a completely consistent decoding procedure for both the actual and reference data packets. This ensures that subsequent comparisons are performed between two structurally identical objects with equivalent field definitions, laying the foundation for a fair and accurate comparison. For example, when parsing an industrial control message conforming to the Modbus TCP protocol, this step ensures that the data packets on both sides are correctly parsed to obtain fields such as the Ethernet MAC address, IP address, TCP port number, and ultimately, the Modbus function code and register address. Any inconsistency in the decoding logic could artificially introduce differences, leading to erroneous conclusions in subsequent comparisons; therefore, the decoding process must possess a high degree of reliability and repeatability.

[0062] Step S502: Determine the field matching rules and fault tolerance parameters corresponding to each protocol layer according to the predefined hierarchical comparison strategy.

[0063] It's important to note that the layered comparison strategy is a pre-configured set of strategies that defines matching rules and tolerance parameters for key fields at each layer of the protocol stack. Matching rules refer to the specific criteria for determining whether two fields are considered identical, and their strictness varies depending on the semantic importance of the field. For example, for the destination address field at the network layer, an exact match is typically required, meaning that the bits must be completely identical; while for fields like Time to Live (TTL), which decreases with each hop, reasonable differences in values ​​are allowed. Tolerance parameters, on the other hand, set acceptable deviation ranges or ignore conditions for fields where differences are permitted; they are a quantified tolerance metric.

[0064] Understandably, the differentiated matching strategy is necessary because fields at different protocol layers have fundamental functional differences. Lower-level protocol fields often focus more on the physical reliability and network reachability of data transmission; instantaneous changes in some of these fields are normal manifestations of network behavior and should not be considered conversion errors. However, higher-level protocol fields, especially industrial control commands and data values ​​in application layer payloads, directly reflect the semantic correctness of protocol conversion, thus requiring extremely rigorous comparison.

[0065] It should be understood that, based on this strategy, the system can automatically assign appropriate comparison algorithms and thresholds to each field at each level, without requiring manual intervention on a package-by-package basis. This ensures that the final confidence assessment results have a clear calculation basis and interpretability. When the comparison report indicates that the confidence level of a certain level is low, developers can clearly trace which field violated which matching rule, thus providing a basis for quickly locating and fixing program defects.

[0066] In one embodiment, determining the field matching rules and fault tolerance parameters corresponding to each protocol layer according to a predefined layered comparison strategy includes: if the protocol layer is a physical layer protocol field, then performing byte-by-byte verification according to strict bit-level comparison rules; if the protocol layer is a data link layer protocol field, then performing byte-by-byte verification of the media access control address, Ethernet type, and virtual LAN tag in the field using strict field-level comparison rules; if the protocol layer is a network layer and transport layer protocol field, then performing byte-by-byte verification of the checksum and time-to-live values ​​in the field using fault tolerance threshold comparison rules; if the protocol layer is an application layer protocol field, then performing parsing and comparison of the protocol-specific command code and register address in the field using semantic consistency comparison rules.

[0067] Step S503: Based on the matching rules and fault tolerance parameters, perform field comparison and confidence assessment at each protocol level in sequence to obtain the hierarchical confidence level.

[0068] It should be noted that the field comparison and confidence assessment performed in this step is a calculation process executed layer by layer according to a predetermined strategy. Specifically, for each layer's decoded protocol fields, the system calls the pre-defined matching rules and fault tolerance parameters for that layer, verifying the consistency between the actual data packet fields and the corresponding fields in the reference data packet. The matching rules define the judgment criteria for that layer; for example, precise matching is required for critical application layer function codes, while dynamic fields such as Time-to-Live (TTL) are allowed to fluctuate within a certain range. The confidence assessment quantifies the comparison results of one or more fields into a score characterizing the overall correctness of the conversion at that layer; this score is the layered confidence score.

[0069] Understandably, this layered evaluation approach can accurately reflect the fidelity of protocol conversion at different functional layers. The confidence levels of the data link layer and network layer mainly measure the correctness of network adaptation functions such as address translation and routing encapsulation; the confidence level of the transport layer focuses on the reliability of connection management and data segmentation; while the confidence level of the application layer directly relates to whether core business semantics such as industrial control commands and process parameters are transmitted losslessly.

[0070] Step S504: Integrate the stratified confidence scores to obtain the stratified comparison results.

[0071] It's important to note that the integration process refers to combining independently calculated layered confidence scores from different protocol layers using specific data fusion methods into a single quantitative indicator or structured result that globally and holistically reflects the correctness of protocol conversion. This process is not a simple arithmetic average, but a weighted aggregation that comprehensively considers the different importance of each protocol layer in industrial communication. For example, the application layer carries core control commands and process parameters, and its confidence score is often assigned a higher weight; while the data link layer is mainly responsible for physical addressing, and its weight may be relatively lower. This focused integration ensures that the final result accurately reflects the primary concern of business logic correctness in industrial scenarios.

[0072] This technical solution provides a method for verifying heterogeneous network programs using industrial protocols. Its core lies in layered decoding and comparison of the protocol conversion process. The solution first parses the actual and reference data packets into multi-layered protocol fields. Then, based on pre-defined matching rules and fault-tolerance parameters for each protocol layer, it compares the fields layer by layer and calculates the layered confidence score. Finally, by weighted fusion of these layered confidence scores, a comprehensive layered comparison result reflecting the correctness of the conversion is generated.

[0073] In summary, this scheme achieves refined verification from the data link to the application layer through layered parsing and differentiated comparison strategies. By setting strict, precise matching or reasonable fault tolerance ranges for the characteristics of different protocol layers, the verification process can capture errors in the conversion of key semantics while tolerating unavoidable non-essential differences in network transmission. This meticulous evaluation mechanism effectively improves the accuracy and reliability of verification results, accurately identifies weaknesses in the conversion process, and provides clear guidance for program optimization, thus contributing to ensuring the reliability and security of industrial communications.

[0074] like Figure 3 As shown, Figure 3 This is a schematic diagram of the hardware simulation system for the P4 program verification method for heterogeneous industrial protocol networks of the present invention.

[0075] Reference Figure 3 Its core lies in constructing a parallel comparison mechanism between the "entity to be verified" and the "reference entity," combined with a hierarchical confidence assessment model, to achieve accurate verification of the correctness of the P4 program's functionality. The entire process begins with the input of user scenario descriptions and design requirements, clarifying the industrial protocol conversion requirements that the P4 program to be verified needs to implement. Based on this, on the one hand, the design requirements are transformed into specific test stimulus generation strategies through a translation process; on the other hand, the P4 program code to be verified and the "Verilog code" serving as the gold standard reference are prepared.

[0076] In building the verification environment, the P4 program code is compiled and loaded, ultimately deployed on the NetFPGA hardware platform to form the design to be verified. The reference Verilog code is also loaded onto the FPGA hardware and runs as a reference design. Test stimulus generation is based on industrial protocol conversion requirements. The system generates standardized message data packets conforming to the protocol syntax structure, constructs "boundary test data packets" according to field boundary values ​​and length constraints, and generates "robustness test data packets" simulating the flow timing characteristics of an industrial environment. These diverse test stimulus data packets are simultaneously injected into the entity to be verified and the reference entity, thereby collecting "actual data packets" and "reference data packets" for comparison. The subsequent information analysis module performs in-depth protocol stack decoding on the collected actual and reference data packets, extracting multi-layered protocol fields from the physical layer to the application layer. Subsequently, based on a refined layered comparison strategy, differentiated matching rules are applied to different protocol layers: strict bit-level or field-level verification is used for key fields (such as MAC addresses and VLAN tags) in the physical and data link layers; fault tolerance threshold comparison is introduced for fields in the network and transport layers that allow dynamic changes (such as checksums and TTL values); and semantic consistency comparison is used for parsing and verification of industry-specific command codes and register addresses in the application layer. Through this layer-by-layer, differentiated comparison and confidence assessment, finally, in the "test report" stage, the method will count all failed test cases, classify the discrepancies in the data, and mark the specific error types (such as field value errors, semantic parsing errors, etc.). Furthermore, through root cause analysis, the system can associate the classified errors with specific logical defects in the P4 program, generating a comprehensive test report that includes error distribution statistics, problem analysis, and optimization suggestions, and presenting it intuitively in a visual format. This closed-loop process not only completed the functional verification of the P4 program, but also provided developers with precise debugging directions, thereby effectively ensuring the high reliability and high determinism of the P4 program in heterogeneous industrial protocol networks.

[0077] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the P4 program verification method for heterogeneous industrial protocol networks in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0078] This application also provides an industrial protocol heterogeneous network P4 program verification device, please refer to... Figure 4 The industrial protocol heterogeneous network P4 program verification device includes: The program acquisition module 10 is used to acquire the P4 program to be verified and the corresponding reference hardware description language program. Environment deployment module 20 is used to load the P4 program to be verified onto the P4 programmable switch as the entity to be verified, and to load the hardware description language program onto the FPGA hardware platform as the reference entity. The test case generation module 30 is used to convert requirement information according to industrial protocols and generate test stimulus data packets. The test execution module 40 is used to synchronously send the test stimulus data packet to the entity to be verified and the reference entity, so as to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity. The result comparison module 50 is used to compare the actual data packet with the reference data packet using a hierarchical confidence comparison model to obtain the hierarchical comparison result. The report generation module 60 is used to generate a test report for the P4 program to be verified based on the hierarchical comparison results.

[0079] In one embodiment, the use case generation module 30 is further configured to parse the industrial protocol conversion requirement information to determine the industrial protocol involved in the P4 program to be verified; determine the protocol fields of the data packet to be constructed based on the syntax structure of the industrial protocol involved in the P4 program to be verified; and generate a test stimulus data packet based on the test requirement information and the protocol fields.

[0080] In one embodiment, the use case generation module 30 is further configured to generate corresponding standardized message data packets for each industrial protocol involved in the P4 program to be verified, based on the protocol fields; generate boundary test data packets based on the field boundary values ​​and length constraints in the industrial protocol conversion requirement information; generate robustness test data packets based on the traffic timing characteristics of the simulated industrial site in the industrial protocol conversion requirement information; and use the standardized message data packets, boundary test data packets, and robustness test data packets as the test stimulus data packets.

[0081] In one embodiment, the result comparison module 50 is further configured to perform protocol stack decoding based on the actual data packet and the reference data packet respectively to obtain the corresponding multi-level protocol fields; determine the field matching rules and fault tolerance parameters corresponding to each protocol level according to a predefined layered comparison strategy; perform field comparison and confidence evaluation of each protocol level in sequence according to the matching rules and fault tolerance parameters to obtain the layered confidence; and integrate the layered confidence to obtain the layered comparison result.

[0082] In one embodiment, the result comparison module 50 is further configured to: if the protocol level is a data link layer protocol field, perform byte-by-byte verification of the media access control address, Ethernet type, and virtual LAN tag in the field using strict field-level comparison rules; if the protocol level is a network layer and transport layer protocol field, perform byte-by-byte verification of the checksum and time-to-live value in the field using fault tolerance threshold comparison rules; and if the protocol level is an application layer protocol field, perform parsing and comparison of the protocol-specific command code and register address in the field using semantic consistency comparison rules.

[0083] In one embodiment, the report generation module 60 is further configured to perform failed test case statistical processing on the hierarchical comparison results to obtain a set of failed test cases and difference data; perform error classification processing on the set of failed test cases and difference data based on predefined error types to obtain program error statistical results; perform failure root cause analysis and optimization suggestion generation processing on the program error statistical results to obtain problem analysis and optimization guidance information; and perform report synthesis processing on the set of failed test cases, classification error statistical results, and problem analysis and optimization guidance information to obtain a test report of the P4 program to be verified.

[0084] In one embodiment, the report generation module 60 is further configured to: perform attribute discrimination on the data packet comparison differences according to the predefined error types and the difference data to obtain a difference information set labeled with error types; perform association mapping between test cases and error types according to the failed test case set and the difference information set to obtain error classification results corresponding to each test case; statistically analyze the frequency and distribution of various types of errors in the test cases according to the error classification results to obtain test error statistics; and summarize and generate the program error statistics containing details of error type distribution according to the test error statistics.

[0085] The industrial protocol heterogeneous network P4 program verification device provided in this application employs the industrial protocol heterogeneous network P4 program verification method in the above embodiments. It can solve the technical problem in the prior art of how to fully, efficiently, and reliably verify the functional correctness of a P4 program before deploying it to an actual production environment, ensuring that its behavior meets expectations. Compared with the prior art, the beneficial effects of the industrial protocol heterogeneous network P4 program verification device provided in this application are the same as those of the industrial protocol heterogeneous network P4 program verification method provided in the above embodiments, and other technical features in the industrial protocol heterogeneous network P4 program verification device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0086] This application provides an industrial protocol heterogeneous network P4 program verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the industrial protocol heterogeneous network P4 program verification method in the above embodiment 1.

[0087] The following is for reference. Figure 5 This document illustrates a structural schematic diagram of an industrial protocol heterogeneous network P4 program verification device suitable for implementing embodiments of this application. The industrial protocol heterogeneous network P4 program verification device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The industrial protocol heterogeneous network P4 program verification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0088] like Figure 5As shown, the P4 program verification device for the industrial protocol heterogeneous network may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the P4 program verification device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the industrial protocol heterogeneous network P4 program verification device to exchange data wirelessly or via wired communication with other devices. Although the figure shows an industrial protocol heterogeneous network P4 program verification device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0089] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0090] The industrial protocol heterogeneous network P4 program verification device provided in this application, employing the industrial protocol heterogeneous network P4 program verification method in the above embodiments, can solve the technical problem in the prior art of how to fully, efficiently, and reliably verify the functional correctness of P4 programs before deploying them to the actual production environment, ensuring that their behavior meets expectations. Compared with the prior art, the beneficial effects of the industrial protocol heterogeneous network P4 program verification device provided in this application are the same as the beneficial effects of the industrial protocol heterogeneous network P4 program verification method provided in the above embodiments, and other technical features in this industrial protocol heterogeneous network P4 program verification device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0091] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0093] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the industrial protocol heterogeneous network P4 program verification method in the above embodiments.

[0094] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), or any suitable combination thereof.

[0095] The aforementioned computer-readable storage medium may be included in the industrial protocol heterogeneous network P4 program verification device; or it may exist independently and not be assembled into the industrial protocol heterogeneous network P4 program verification device.

[0096] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the P4 program verification device for heterogeneous industrial protocols, the P4 program verification device performs the following actions: acquires the P4 program to be verified and its corresponding reference hardware description language program; loads the P4 program to be verified onto a P4 programmable switch as the entity to be verified, and loads the hardware description language program onto an FPGA hardware platform as a reference entity; generates test stimulus data packets based on industrial protocol conversion requirements; synchronously sends the test stimulus data packets to the entity to be verified and the reference entity to obtain the actual data packets output by the entity to be verified and the reference data packets output by the reference entity; compares the actual data packets and the reference data packets using a hierarchical confidence comparison model to obtain hierarchical comparison results; and generates a test report for the P4 program to be verified based on the hierarchical comparison results.

[0097] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0100] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described industrial protocol heterogeneous network P4 program verification method. This solves the technical problem in the prior art of how to fully, efficiently, and reliably verify the functional correctness of a P4 program before deploying it to an actual production environment, ensuring that its behavior meets expectations. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the industrial protocol heterogeneous network P4 program verification method provided in the above embodiments, and will not be repeated here.

[0101] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the industrial protocol heterogeneous network P4 program verification method described above.

[0102] The computer program product provided in this application solves the technical problem in the prior art of how to fully, efficiently, and reliably verify the functional correctness of a P4 program before deploying it to a real production environment, ensuring that its behavior meets expectations. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the P4 program verification method for heterogeneous industrial protocol networks provided in the above embodiments, and will not be repeated here.

[0103] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for verifying P4 programs in heterogeneous industrial protocol networks, characterized in that, The industrial protocol heterogeneous network P4 program verification method includes: Obtain the P4 program to be verified and the corresponding reference hardware description language program; The P4 program to be verified is loaded into the P4 programmable switch as the entity to be verified, and the hardware description language program is loaded into the FPGA hardware platform as the reference entity. Generate test stimulus data packets based on the industrial protocol conversion requirement information; The test stimulus data packet is synchronously sent to the entity to be verified and the reference entity to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity. Based on the actual data packet and the reference data packet, a hierarchical confidence comparison model is used to compare them to obtain the hierarchical comparison results. Based on the hierarchical comparison results, a test report for the P4 program to be verified is generated.

2. The P4 program verification method for heterogeneous industrial protocol networks according to claim 1, characterized in that, The step of generating a test stimulus data packet based on the industrial protocol conversion requirement information includes: The industrial protocol conversion requirement information is parsed to determine the industrial protocol involved in the P4 program to be verified; Based on the syntax structure of the industrial protocol involved in the P4 program to be verified, determine the protocol fields of the data packet to be constructed; Based on the test requirement information and the protocol fields, a test stimulus data packet is generated.

3. The P4 program verification method for heterogeneous industrial protocol networks according to claim 2, characterized in that, The process of generating a test stimulus data packet based on the test requirement information and the protocol fields includes: Based on the protocol fields, corresponding standardized message data packets are generated one by one for each industrial protocol involved in the P4 program to be verified; Based on the field boundary values ​​and length constraints in the industrial protocol conversion requirement information, generate a boundary test data packet; Based on the flow timing characteristics of the simulated industrial site in the industrial protocol conversion requirement information, a robust test data packet is generated. The standardized message data packet, the boundary test data packet, and the robustness test data packet are used as the test stimulus data packet.

4. The P4 program verification method for heterogeneous industrial protocol networks according to claim 1, characterized in that, The step of comparing the actual data packet with the reference data packet using a hierarchical confidence comparison model to obtain the hierarchical comparison result includes: Based on the actual data packet and the reference data packet, the protocol stack is decoded to obtain the corresponding multi-layer protocol fields; Based on the predefined hierarchical comparison strategy, determine the field matching rules and fault tolerance parameters corresponding to each protocol level; Based on the matching rules and fault tolerance parameters, the fields of each protocol layer are compared and confidence is evaluated in sequence to obtain the hierarchical confidence. The stratified confidence scores are integrated to obtain the stratified comparison results.

5. The P4 program verification method for heterogeneous industrial protocol networks according to claim 4, characterized in that, The step of determining the field matching rules and fault tolerance parameters corresponding to each protocol layer according to the predefined hierarchical comparison strategy includes: if the protocol layer is a physical layer protocol field, then perform byte-by-byte verification according to strict bit-level comparison rules; If the protocol level is a data link layer protocol field, then the media access control address, Ethernet type, and virtual LAN label in the field are verified byte by byte using strict field-level comparison rules; If the protocol layer is a network layer and transport layer protocol field, then the checksum and time-to-live value in the field are checked byte by byte using the fault tolerance threshold comparison rule; If the protocol level is an application layer protocol field, then the protocol-specific command code and register address in the field are parsed and compared using semantic consistency comparison rules.

6. The P4 program verification method for heterogeneous industrial protocol networks according to claim 1, characterized in that, The step of generating a test report for the P4 program to be verified based on the hierarchical comparison results includes: The hierarchical comparison results are subjected to statistical processing of failed test cases to obtain a set of failed test cases and difference data. Based on predefined error types, the failed test case set and difference data are classified to obtain program error statistics. The error statistics of the program are processed to perform root cause analysis and optimization suggestions to obtain problem analysis and optimization guidance information. The failed test case set, classification error statistics, and problem analysis and optimization guidance information are processed into a report to obtain the test report of the P4 program to be verified.

7. The P4 program verification method for heterogeneous industrial protocol networks according to claim 6, characterized in that, The method involves classifying the failed test case set and variance data based on predefined error types to obtain program error statistics, including: Based on the predefined error types and the difference data, attribute discrimination is performed on the differences in the data packets to obtain a set of difference information labeled with error types; Based on the set of failed test cases and the set of difference information, perform an association mapping between test cases and error types to obtain the error classification results corresponding to each test case; Based on the error classification results, the frequency and distribution of each type of error in the test cases are statistically analyzed to obtain test error statistics. Based on the test error statistics, a summary of program error statistics results, including details of the error type distribution, is generated.

8. A P4 program verification device for heterogeneous industrial protocol networks, characterized in that, The device includes: The program acquisition module is used to acquire the P4 program to be verified and the corresponding reference hardware description language program. The environment deployment module is used to load the P4 program to be verified onto the P4 programmable switch as the entity to be verified, and to load the hardware description language program onto the FPGA hardware platform as the reference entity. The test case generation module is used to convert requirement information according to industry protocols and generate test stimulus data packages. The test execution module is used to synchronously send the test stimulus data packet to the entity to be verified and the reference entity, so as to obtain the actual data packet output by the entity to be verified and the reference data packet output by the reference entity. The result comparison module is used to compare the actual data packet with the reference data packet using a hierarchical confidence comparison model to obtain the hierarchical comparison result. The report generation module is used to generate a test report for the P4 program to be verified based on the hierarchical comparison results.

9. A P4 program verification device for heterogeneous industrial protocol networks, characterized in that, The industrial protocol heterogeneous network P4 program verification device includes: a memory, a processor, and an industrial protocol heterogeneous network P4 program verification program stored in the memory and executable on the processor, wherein the industrial protocol heterogeneous network P4 program verification program is configured to implement the steps of the industrial protocol heterogeneous network P4 program verification method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores an industrial protocol heterogeneous network P4 program verification program, which, when executed by a processor, implements the steps of the industrial protocol heterogeneous network P4 program verification method as described in any one of claims 1 to 7.

Images