Method and system for autonomous running of an interoperability verification task based on a process engine

Abstract

The application provides a process engine-based autonomous operation method and system for an interoperability verification task, a virtual-real combined simulation environment is constructed by including field equipment operation data, laboratory scaled component state information and a software simulation model, an actual operation scene of a road electromechanical equipment interoperability mechanism is simulated, an interoperability verification task is generated according to a preset verification requirement parameter set, a process engine is called to analyze the task and plan an execution process, the task is executed in the virtual-real combined simulation environment according to the execution process, message transmission data, state response data and time synchronization data in the equipment interaction process are collected in real time, interoperability verification results including interaction message integrity description, state response consistency record and time synchronization accuracy description are generated based on the message transmission data, the state response data and the time synchronization data, so that the verification task can be autonomously planned, and a comprehensive and real test environment is provided.

Description

Technical Field

[0001] This invention relates to the field of virtual-real combined testing technology, and more specifically, to a method and system for autonomous operation of interoperability verification tasks based on a process engine. Background Technology

[0002] In the field of highway electromechanical equipment, interoperability between different devices is crucial for ensuring the normal operation of highway systems and improving traffic efficiency and safety. Currently, the verification of interoperability of highway electromechanical equipment mainly relies on traditional manual testing methods and simple simulation software. Manual testing methods require a significant investment of manpower; testers need to manually operate the equipment and record data, which is not only inefficient but also prone to human error, making it difficult to guarantee the accuracy and reliability of test results. While simple simulation software can simulate the operating states of some equipment, it often can only simulate a single type of equipment or simple interaction scenarios, failing to comprehensively and realistically simulate the complex interoperability mechanisms of highway electromechanical equipment in actual operating environments. Furthermore, existing verification methods lack the ability to autonomously plan and manage verification tasks, and cannot flexibly adjust the verification process according to different verification needs, making it difficult to meet the growing demand for interoperability verification of highway electromechanical equipment. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for autonomous execution of interoperability verification tasks based on a process engine, the method comprising:

[0004] A virtual-real simulation environment is constructed, which includes field equipment operation data, laboratory scale-down component status information and software simulation model. The virtual-real simulation environment is used to simulate the actual operation scenario of the interoperability mechanism of highway electromechanical equipment.

[0005] An interoperability verification task is generated based on a preset set of verification requirement parameters. The interoperability verification task includes the device interaction object to be verified, the interaction protocol type, and the interaction triggering conditions.

[0006] The process engine is invoked to parse the interoperability verification task, and the execution flow of the interoperability verification task is planned based on the communication interface specification and interaction protocol type of the device interaction object. The execution flow includes a task start node, an interaction execution node, and a task termination node.

[0007] According to the execution process, the interoperability verification task is performed in the virtual-real combined simulation environment, and message transmission data, status response data and time synchronization data are collected in real time during the device interaction process.

[0008] Interoperability verification results are generated based on the message transmission data, status response data, and time synchronization data. The interoperability verification results include a description of the integrity of the interaction messages, a record of the consistency of the status response, and a description of the accuracy of the time synchronization.

[0009] In another aspect, embodiments of the present invention also provide an autonomous operation system for interoperability verification tasks based on a process engine, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0010] Based on the above, this embodiment of the invention constructs a virtual-real combined simulation environment that includes field equipment operation data, laboratory scale-down component status information, and software simulation models. This environment can highly realistically simulate the actual operation scenario of the interoperability mechanism of highway electromechanical equipment, providing a comprehensive and realistic testing environment for interoperability verification. It ensures the reliability of verification results from the source. Interoperability verification tasks are generated according to a preset set of verification requirement parameters, and the process engine is invoked to parse the tasks. The execution process is planned based on the communication interface specifications and interaction protocol types of the device interaction objects, realizing autonomous planning and management of verification tasks. The verification process can be flexibly adjusted according to different verification requirements, improving the efficiency and flexibility of verification. Interoperability verification tasks are executed in the virtual-real combined simulation environment according to the execution process, and various data during the device interaction process are collected in real time. Finally, based on the collected data, interoperability verification results are generated, including descriptions of the integrity of interaction messages, records of consistency in status responses, and descriptions of the accuracy of time synchronization. This comprehensively and accurately reflects the interoperability of highway electromechanical equipment and effectively improves the level of interoperability verification for highway electromechanical equipment. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the execution flow of the autonomous operation method for interoperability verification tasks based on a process engine provided in an embodiment of the present invention.

[0012] Figure 2 This is a schematic diagram of exemplary hardware and software components of the autonomous operation system for interoperability verification tasks based on a process engine provided in an embodiment of the present invention. Detailed Implementation

[0013] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating an embodiment of the autonomous operation method for interoperability verification tasks based on a process engine provided by the present invention. The following is a detailed description of this autonomous operation method for interoperability verification tasks based on a process engine.

[0014] Step S110: Construct a virtual-real combined simulation environment that includes field equipment operation data, laboratory scaled-down component status information, and software simulation model. The virtual-real combined simulation environment is used to simulate the actual operation scenario of the interoperability mechanism of highway electromechanical equipment.

[0015] In this embodiment, during the research and development and testing of highway electromechanical equipment, a virtual-real hybrid simulation environment needs to be constructed to accurately simulate the actual operating scenarios of its interoperability mechanism. This simulation environment integrates field equipment operation data, laboratory scale-down component status information, and software simulation models to achieve a high degree of fidelity to the real-world scenario.

[0016] Step S111: Obtain historical operation log data of the field equipment. The historical operation log data includes equipment communication message records, status change timestamps, and abnormal event trigger records.

[0017] In this embodiment, the field equipment generates a large amount of historical operation log data during long-term operation. This historical operation log data is a true record of the actual operating status of the equipment. The equipment communication message record details the content of messages transmitted during communication between devices, including message format, data fields, and transmission time sequence. The status change timestamp precisely records the specific time points when the equipment status changes, such as the time when the equipment switches from a normal operating state to a fault state, or recovers from a fault state to a normal operating state. The abnormal event trigger record records relevant information about abnormal events that occur during equipment operation, such as the type of abnormal event, triggering conditions, and impact. By collecting and analyzing this historical operation log data, various situations of the field equipment during actual operation can be determined.

[0018] Step S112: Collect the current operating status parameters of the laboratory scale-down component. The operating status parameters include the component's input and output interface voltage values, signal transmission delay, and protocol conversion power.

[0019] The laboratory-scale simulation module is a scaled-down version of highway electromechanical equipment, and its operating parameters can reflect some characteristics of the actual equipment. The input and output interface voltage values ​​are important indicators of the module's electrical performance; normal voltage ranges ensure stable operation. Signal transmission delay reflects the time it takes for a signal to travel within the module; excessive delay may affect communication efficiency and data transmission accuracy between devices. Protocol conversion power indicates the success rate of the module when converting between different communication protocols; high protocol conversion power ensures compatibility and interoperability under different protocol environments. By collecting these current operating parameters, the real-time operating status of the laboratory-scale simulation module can be determined.

[0020] Step S113: Load the pre-configured software simulation model, which includes a communication protocol stack module, a state machine transition rule module, and an exception injection control module for highway electromechanical equipment.

[0021] Software simulation models are a crucial component of the virtual environment, capable of simulating various behaviors and characteristics of highway electromechanical equipment. The communication protocol stack module simulates the various protocols followed when highway electromechanical equipment communicates, including physical layer protocols, data link layer protocols, and network layer protocols, ensuring correct data transmission and interaction between devices. The state machine transition rule module defines the transition rules for device states under different conditions, such as how the state changes when the device receives a specific instruction or experiences a specific event. The anomaly injection control module simulates various abnormal situations, such as communication failures, data loss, and equipment malfunctions, to test the equipment's ability to cope with and its stability under abnormal conditions. By loading pre-configured software simulation models, various operating scenarios of highway electromechanical equipment can be simulated in a virtual environment.

[0022] Step S114: Perform unified data format processing on the historical operation log data, current working status parameters and software simulation model to generate a multi-source data set with spatiotemporal alignment characteristics.

[0023] Because historical operation log data, current operating status parameters, and software simulation models come from different sources, their data formats may differ. To effectively integrate these data, a unified data format processing is required. This process must consider the temporal and spatial characteristics of the data, ensuring spatiotemporal alignment between them. For example, the timestamps of historical operation log data and current operating status parameters need to be unified to allow for analysis and comparison along the same time dimension. Similarly, the simulated data of the software simulation model needs to be matched with the actually collected data to ensure spatial consistency. Through this unified data format processing, a multi-source dataset with spatiotemporal alignment can be generated.

[0024] Step S115: Based on the multi-source data set, construct a three-layer simulation environment structure including a physical device layer, a simulation layer, and a data mapping layer. The physical device layer is used to connect field equipment and laboratory scale-down components. The simulation layer is used to run software simulation models. The data mapping layer is used to realize state synchronization between the physical device layer and the simulation layer.

[0025] The physical equipment layer serves as the interface between the simulated environment and the real world, connecting field equipment and scaled-down laboratory components. Through this layer, real-time operational data from field equipment and working status parameters of scaled-down laboratory components can be acquired, providing a realistic data source for the simulated environment. The simulation layer is the core of the virtual environment, running software simulation models to simulate various behaviors and characteristics of highway electromechanical equipment. In the simulation layer, different parameters and scenarios can be set according to different testing needs to simulate various actual operating conditions. The data mapping layer acts as a bridge, responsible for synchronizing the states between the physical equipment layer and the simulation layer. Through the data mapping layer, actual data collected by the physical equipment layer can be mapped to the simulation layer, allowing the simulation model to dynamically adjust according to actual conditions; simultaneously, virtual data generated by the simulation layer can be fed back to the physical equipment layer, achieving interaction between the virtual and real worlds. By constructing a three-layer simulated environment structure, a high degree of simulation of the actual operating scenarios of highway electromechanical equipment interoperability mechanisms can be achieved.

[0026] Step S120: Generate an interoperability verification task based on a preset set of verification requirement parameters. The interoperability verification task includes the device interaction object to be verified, the interaction protocol type, and the interaction triggering conditions.

[0027] After constructing the virtual-real hybrid simulation environment, interoperability verification tasks need to be generated based on a pre-defined set of verification requirement parameters. These interoperability verification tasks will be used to comprehensively verify the interoperability mechanisms of highway electromechanical equipment.

[0028] Step S121: Parse the preset set of verification requirement parameters and extract the verification target type parameter. The verification target type parameter is used to indicate whether the device communication protocol compatibility, state synchronization reliability or anomaly handling robustness needs to be verified.

[0029] The pre-defined set of verification requirement parameters contains various verification-related parameters, among which the verification target type parameter is a key piece of information. This parameter clarifies the specific objective of the verification task, namely, whether it's verifying inter-device communication protocol compatibility, state synchronization reliability, or anomaly handling robustness. For example, if the parameter indicates verifying inter-device communication protocol compatibility, subsequent verification tasks will primarily focus on the interaction between devices under different communication protocols; if it indicates verifying state synchronization reliability, the focus will be on the synchronization of state information between devices; and if it indicates verifying anomaly handling robustness, various anomaly scenarios need to be simulated to test the device's ability to handle these situations.

[0030] Step S122: Select the device interaction objects to be verified from the predefined device resource library according to the verification target type parameter. The device interaction objects include field equipment instances, laboratory scaled-down component instances, and software simulation model instances.

[0031] The predefined equipment resource library contains various field equipment instances, laboratory scale-down component instances, and software simulation model instances. Based on the verification target type parameter, suitable equipment interaction objects can be selected from the resource library to participate in the verification task. For example, if the verification target is the compatibility of communication protocols between devices, it may be necessary to select field equipment instances and laboratory scale-down component instances of different brands and models, as well as software simulation model instances capable of simulating different communication protocols, to comprehensively test the compatibility of the equipment under different protocol environments.

[0032] Step S123: Determine the interaction protocol type between the device interaction objects. The interaction protocol type includes basic communication protocol, service data protocol and exception handling protocol.

[0033] After identifying the devices that need to interact, it's necessary to further define the types of interaction protocols between them. Basic communication protocols define the rules and methods for basic communication between devices, such as data transmission formats and baud rates. Business data protocols, on the other hand, specify the transmission and processing methods for business data based on specific business needs, such as the toll data transmission protocol in a highway toll system. Anomaly handling protocols are used to handle abnormal situations that occur during device operation, such as communication failures and data errors. Clearly defining the types of interaction protocols between devices helps in accurately performing verification tasks and ensuring that devices can interact normally under different protocols.

[0034] Step S124: Set interaction trigger conditions based on the verification target type parameter and interaction protocol type. The interaction trigger conditions include normal operation trigger conditions, exception injection trigger conditions and boundary state trigger conditions.

[0035] Interaction trigger conditions are crucial factors controlling device interaction behavior, and they are set based on the verification target type parameter and the interaction protocol type. Normal operation trigger conditions are used to trigger the device's interaction behavior under normal conditions, such as initiating normal communication interaction when the device is in an initial ready state. Anomaly injection trigger conditions are used to simulate various abnormal situations, such as randomly inserting error check codes or missing fields during message interaction to test the device's handling capabilities under abnormal conditions. Boundary state trigger conditions are used to test the device's performance under near-limit conditions, such as triggering corresponding interaction operations when the device's load rate reaches a preset load threshold.

[0036] Step S1241: When the verification target type parameter indicates that the compatibility of the communication protocol between devices is verified, the normal operation trigger condition is set to the device interaction object being in the initial ready state, the exception injection trigger condition is the random insertion of error check codes or missing fields during message interaction, and the boundary state trigger condition is the load rate of the device interaction object reaching the preset load threshold.

[0037] If the verification target is the compatibility of communication protocols between devices, then the normal operation trigger condition is set to the device interaction object being in an initial ready state. This ensures that the device begins communication interaction after normal startup, testing its protocol compatibility under normal conditions. The exception injection trigger condition is set to randomly insert error check codes or missing fields during message interaction. By simulating these abnormal situations, the device's handling capability under protocol error conditions is tested. The boundary state trigger condition is set to the load rate of the device interaction object reaching a preset load threshold. When the device load is too high, it may affect the normal operation of its communication protocol. Setting this trigger condition can test the device's protocol compatibility under high load conditions.

[0038] Step S1242: When the verification target type parameter indicates the verification state synchronization reliability, set the normal operation trigger condition to the completion of the device interaction object initialization synchronization, the exception injection trigger condition to the interruption of the communication connection during the state change process, and the boundary state trigger condition to the state change frequency of the device interaction object reaching the preset frequency threshold.

[0039] When the verification objective is state synchronization reliability, the normal operation trigger condition is set to the device interaction object completing initial synchronization. This is a prerequisite for subsequent verification based on state synchronization. The exception injection trigger condition is set to interrupt the communication connection during a state change, simulating a communication failure and testing the device's state synchronization capability during communication interruption. The boundary state trigger condition is set to the frequency of state changes of the device interaction object reaching a preset frequency threshold. When state changes are too frequent, it may affect the state synchronization between devices. By setting this trigger condition, the synchronization reliability of the device under high-frequency state change conditions can be tested.

[0040] Step S1243: When the verification target type parameter indicates the robustness of verification exception handling, set the normal operation trigger condition to the device interaction object receiving a legitimate request message, the exception injection trigger condition to the device interaction object sending an illegal format message or a message with an excessively large amount of data, and the boundary state trigger condition to the device interaction object accumulating an exception event count that reaches a preset critical threshold.

[0041] If the verification objective is robustness in handling exceptions, the normal operation trigger condition is set to the device interaction object receiving a legitimate request message, which is a fundamental condition for the device's normal operation. The exception injection trigger condition is set to send an invalid message or an excessively large data volume message to the device interaction object. By simulating these abnormal situations, the device's ability to handle illegal input is tested. The boundary state trigger condition is set to the cumulative number of exception events of the device interaction object reaching a preset critical threshold. When the number of exception events accumulates to a certain level, the device's ability to maintain stable operation and correctly handle these abnormal situations is tested.

[0042] Step S1244: Perform conflict detection on the triggering conditions corresponding to different verification target type parameters so that mutually exclusive triggering conditions are not triggered at the same time point.

[0043] Triggering conditions for different verification target type parameters may conflict. If mutually exclusive triggering conditions are triggered simultaneously at the same time, it may lead to inaccurate verification results. Therefore, conflict detection is required for these triggering conditions. For example, the exception injection triggering condition set when verifying the compatibility of communication protocols between devices may conflict with the exception injection triggering condition set when verifying the reliability of state synchronization. Conflict detection can avoid this situation and ensure the smooth progress of the verification task.

[0044] Step S1245: Set a corresponding trigger action for each trigger condition. The trigger action includes starting an exception injection program, adjusting the device load state, or recording interactive data under boundary conditions.

[0045] Each trigger condition requires a corresponding trigger action to achieve the desired verification purpose. When the trigger condition is met, the corresponding trigger action is executed. For example, when the exception injection trigger condition is met, the exception injection program is started to simulate an abnormal situation; when the boundary state trigger condition is met, the device load state is adjusted or the interaction data under the boundary state is recorded for subsequent analysis of the device's performance under special conditions.

[0046] Step S125: Encapsulate the device interaction object, interaction protocol type, and interaction triggering condition into a structured task description file. The task description file includes a task identifier field, an object list field, a protocol description field, and a triggering condition field.

[0047] To facilitate the management and execution of interoperability verification tasks, the device interaction objects, interaction protocol types, and interaction trigger conditions need to be encapsulated into a structured task description file. The task identifier field uniquely identifies the verification task, facilitating subsequent querying and management. The object list field lists the device interaction objects participating in the verification task, including field device instances, laboratory scale-down component instances, and software simulation model instances. The protocol description field details the interaction protocol types between device interaction objects, including basic communication protocols, business data protocols, and exception handling protocols. The trigger condition field records various interaction trigger conditions, including normal operation trigger conditions, exception injection trigger conditions, and boundary state trigger conditions. By encapsulating this into a task description file, relevant information for the verification task can be managed uniformly, improving the execution efficiency of the verification task.

[0048] Step S130: Call the process engine to parse the interoperability verification task, and plan the execution flow of the interoperability verification task based on the communication interface specification and interaction protocol type of the device interaction object. The execution flow includes a task start node, an interaction execution node, and a task termination node.

[0049] After generating the interoperability verification task, the process engine needs to be invoked to parse it and plan the execution flow of the verification task. The process engine can reasonably arrange each step of the verification task according to the communication interface specifications and interaction protocol types of the device interaction objects, ensuring the smooth execution of the verification task.

[0050] Step S131: Read the task identifier field, object list field, protocol description field and trigger condition field from the task description file of the interoperability verification task, and generate a task metadata set.

[0051] The workflow engine first reads the task description file of the interoperability verification task, extracting key information such as the task identifier field, object list field, protocol description field, and trigger condition field. This information constitutes the task metadata set, which contains the basic information and execution requirements of the verification task. The task identifier field uniquely identifies the verification task, the object list field specifies the device interaction objects participating in the verification, the protocol description field describes the type of interaction protocol between the devices, and the trigger condition field specifies the various trigger conditions during the verification process. By generating the task metadata set, the workflow engine can comprehensively determine the specific content of the verification task.

[0052] Step S132: Obtain the communication interface specification document for each device interaction object based on the object list field. The communication interface specification document includes the protocol version supported by the interface, message format definition, and handshake process description.

[0053] Based on the object list fields in the task metadata collection, the process engine can obtain the communication interface specification document for each device interaction object. These documents detail various characteristics of the device interface, including supported protocol versions, message format definitions, and handshake process descriptions. Supported protocol versions specify the specific versions of communication protocols the device can support; different protocol versions may differ in functionality and performance. Message format definitions clarify the specific format of messages during communication between devices, including message headers, data fields, and checksums. The handshake process descriptions the interaction process when devices establish a communication connection, such as sending a handshake request and receiving a handshake response. By obtaining the communication interface specification document, the process engine can determine the communication capabilities and interaction methods of the device interaction objects.

[0054] Step S133: Determine the message interaction order between device interaction objects based on the protocol description fields and communication interface specification document. The message interaction order includes the order of sending request messages, the order of receiving response messages, and the order of responding confirmation messages.

[0055] By combining the protocol description fields in the task metadata set and the communication interface specification documents of the device interaction objects, the process engine can determine the message exchange order between device interaction objects. The order in which request messages are sent specifies the order in which devices initiate communication requests, the order in which response messages are received specifies the order in which devices receive response messages, and the order in which acknowledgment messages are sent describes the order in which devices send acknowledgment messages after receiving response messages. For example, in a verification task for a highway toll system, the toll collection device might first send a request message to the monitoring device, the monitoring device would then send a response message to the toll collection device, and the toll collection device would then send an acknowledgment message to the monitoring device. By determining the message exchange order, the process engine can ensure that communication between devices proceeds in the correct order, avoiding message confusion or loss.

[0056] Step S134: Combining the normal operation trigger condition, the exception injection trigger condition, and the boundary state trigger condition in the trigger condition field, insert a condition judgment node in the message interaction sequence. The condition judgment node is used to control the execution timing of the exception injection operation and the boundary state switching operation.

[0057] After determining the message interaction order, the workflow engine needs to insert condition judgment nodes into the message interaction order, based on the various trigger conditions in the trigger condition field. These condition judgment nodes can monitor various status information during the verification process in real time and execute corresponding operations when specific trigger conditions are met. For example, when an exception injection trigger condition is met, the condition judgment node will trigger an exception injection operation, such as randomly inserting an error checksum or missing field during message interaction; when a boundary state trigger condition is met, the condition judgment node will trigger a boundary state switching operation, such as adjusting the device's load status. By inserting condition judgment nodes, the injection of exceptions and the switching of boundary states can be flexibly controlled during the verification process, improving the comprehensiveness and accuracy of the verification task.

[0058] Step S135: Arrange the task metadata set, message interaction sequence and condition judgment node into process nodes to generate a verification task execution flow including task start node, interaction execution node and task termination node. The task start node is used to initialize the state of the device interaction object, the interaction execution node is used to perform message interaction and state verification operations, and the task termination node is used to close the device interaction connection and save the verification process data.

[0059] The workflow engine orchestrates the task metadata set, message interaction sequence, and conditional judgment nodes into workflow nodes, generating a complete verification task execution flow. The task initiation node is the starting point of the verification task, responsible for initializing the state of the device interaction objects, such as sending initialization commands and setting device parameters, ensuring the device is in a verifiable state. The interaction execution node is the core part of the verification task; it executes the message interaction operations between devices according to the message interaction sequence and performs state verification, checking whether the device state meets expectations.

[0060] The task termination node is the end point of the verification task. It is responsible for closing the device interaction connection to avoid wasting resources, and at the same time saving various data generated during the verification process, such as message transmission data, status response data, and time synchronization data, for subsequent analysis and evaluation.

[0061] Step S1351: Taking the task initiation node as the starting point of the process, set the node execution action: send an initialization command to the device interaction object and wait for a response.

[0062] The task initiation node, as the starting point of the entire verification task execution process, primarily sends an initialization command to the device interaction object. This initialization command contains crucial information such as device address configuration parameters, protocol version negotiation parameters, and timeout settings. The device address configuration parameters determine the device's unique address within the network, ensuring accurate communication between devices. The protocol version negotiation parameters negotiate the communication protocol versions used by the devices, guaranteeing interaction within the same protocol environment. The timeout settings specify the maximum time the device should wait for a response, preventing the verification task from stalling due to prolonged waiting. After sending the initialization command, a response from the device interaction object is required to confirm successful device initialization.

[0063] Step S1352: Connect the interaction execution node after the task start node. The interaction execution node contains multiple child nodes. Each child node corresponds to a message interaction step in the message interaction sequence. The child node performs the following actions: sending request messages, listening for response messages, and recording interaction data.

[0064] After successful execution at the task initiation node, the system connects to the interaction execution node. The interaction execution node consists of multiple child nodes, each corresponding to a message interaction step in the message interaction sequence. The main actions of each child node include sending request messages, listening for response messages, and recording interaction data. When sending a request message, it accurately sends the request message to the target device according to the message interaction sequence. Simultaneously, a listening mechanism is initiated to wait for the response message from the target device. Once a response message is received, the system immediately records the sending timestamp and message content of the request message, as well as the receiving timestamp and message content of the response message. This recorded data constitutes the message transmission data.

[0065] Step S1353: Embed a condition judgment node in each child node. The condition judgment node performs the following actions: detect whether the exception injection trigger condition or the boundary state trigger condition is met. If it is met, execute the corresponding trigger action and jump to the exception handling sub-process. If it is not met, continue to execute the next child node.

[0066] To simulate various abnormal situations and boundary states during the verification process, condition judgment nodes are embedded in each sub-node. These condition judgment nodes continuously monitor the current verification status, determining whether the exception injection trigger condition or boundary state trigger condition is met. If the exception injection trigger condition is met, such as the condition for inserting an error checksum or missing field during message interaction, the condition judgment node immediately executes the corresponding trigger action, initiating the exception injection program to simulate the abnormal situation. If the boundary state trigger condition is met, such as the device load rate reaching a preset load threshold, the condition judgment node adjusts the device load state or records the interaction data under the boundary state. When the trigger condition is met, the process jumps to the exception handling sub-process to handle the abnormal situation; if the trigger condition is not met, it continues to execute the next sub-node, ensuring the normal progress of the verification task.

[0067] Step S1354: After all child nodes have completed their execution, connect the task termination node and set the node's execution actions: close the device interaction connection, save the verification process data, and generate a termination status report.

[0068] Once all child nodes of the interactive execution node have completed their execution, it connects to the task termination node. The task termination node's actions include closing the device interaction connection, releasing related resources to avoid waste, and saving various data generated during the verification process, such as message transmission data, status response data, and time synchronization data. Furthermore, it generates a termination status report, which includes the execution status of the verification task, device status information, and whether any anomalies occurred.

[0069] Step S1355: Set execution order constraints for each node so that the interactive execution node can only be executed after the task initiation node has finished executing, and the task termination node can only be executed after all child nodes of the interactive execution node have finished executing.

[0070] To ensure the correctness and orderliness of the verification task execution process, execution order constraints need to be set for each node. The task initiation node is the starting point of the entire process. Only after the task initiation node has successfully executed, the device interaction object has completed initialization, and returned a success status code can the interaction execution node be executed. Each interaction execution node contains multiple child nodes, which must be executed sequentially according to the message interaction order. Only after all child nodes have completed execution can the task termination node be executed. By setting execution order constraints, the verification task can be ensured to proceed according to the predetermined process, avoiding execution chaos.

[0071] Step S140: Perform the interoperability verification task in the virtual-real combined simulation environment according to the execution process, and collect message transmission data, status response data and time synchronization data in real time during the device interaction process.

[0072] After completing the execution flow planning for the interoperability verification task, the verification task needs to be executed in a virtual-real hybrid simulation environment according to the execution flow, and relevant data needs to be collected in real time.

[0073] Step S141: Trigger the task startup node of the execution process and send an initialization command to all device interaction objects. The initialization command includes device address configuration parameters, protocol version negotiation parameters, and timeout setting parameters.

[0074] First, the task initiation node triggers the execution flow, sending initialization commands to all participating device interaction objects. The device address configuration parameter in the initialization command ensures that each device has a unique identifier on the network, facilitating communication and identification between devices. The protocol version negotiation parameter enables devices to negotiate a commonly supported communication protocol version, ensuring communication compatibility. The timeout setting parameter specifies the maximum time a device can wait for a response, preventing devices from remaining in a waiting state for extended periods. For example, in the verification scenario of highway electromechanical equipment, by sending initialization commands, each device (such as monitoring equipment, toll collection equipment, etc.) determines its own address, negotiates the communication protocol version, and sets the timeout period.

[0075] Step S142: Monitor the response of the device interaction objects to the initialization command. When all device interaction objects have completed initialization and returned a success status code, trigger the message interaction operation of the interaction execution node.

[0076] After sending the initialization command, the response results of the device interaction objects need to be monitored in real time. Each device, upon receiving the initialization command, can perform corresponding initialization operations according to the command content and return a status code indicating the initialization result. When all device interaction objects have completed initialization and returned a success status code, it indicates that the device is ready for subsequent message interaction operations, at which point the message interaction operation of the interaction execution node is triggered. If any device returns a failure status code, that device needs to be checked and debugged to ensure that it can initialize correctly.

[0077] Step S143: In the message interaction operation, send a request message to the sending device interaction object according to the message interaction order, listen for the response message returned by the receiving device interaction object, and record the sending timestamp and message content of the request message and the receiving timestamp and message content of the response message as message transmission data.

[0078] In message interaction operations at interactive execution nodes, the message interaction sequence is strictly followed. A request message containing specific business requirements or operational instructions is sent to the sending device interaction object. Simultaneously, a listening mechanism is initiated to await the response message from the receiving device interaction object. Once a response message is received, the sending timestamp and message content of the request message, as well as the receiving timestamp and message content of the response message, are immediately recorded. This recorded data constitutes message transmission data, and analyzing this data can determine the timeliness, accuracy, and completeness of message transmission between devices. For example, in the verification of a highway toll collection system, the toll collection device sends a toll request message to the monitoring device, and the monitoring device returns a toll confirmation message; the sending and receiving timestamps and contents of both messages are recorded.

[0079] Step S144: During message interaction, read the current running status value of the device interaction object, compare it with the expected status value defined in the set of verification requirements, and record the actual change process and expected change process of the status value as status response data.

[0080] During message interaction, it is necessary to read the current operating status value of the device interaction object in real time. To achieve this, a status monitoring interface is configured for each device interaction object, which is used to read the device's operating status register value in real time. Simultaneously, the expected status values ​​defined in the verification requirement parameter set are converted to the same data format and unit as the device's operating status register value for accurate comparison. At each point in time during message interaction, the sending status value of the sending device interaction object and the receiving status value of the receiving device interaction object are obtained through the status monitoring interface. Based on the message type defined in the message interaction sequence, the expected sending status value and expected receiving status value corresponding to that point in time are determined. The time point, actual sending status value, actual receiving status value, expected sending status value, and expected receiving status value are recorded to form status value record entries. The status value record entries for consecutive time points are arranged in chronological order to generate status response data containing actual and expected change process curves over a time series. By comparing the actual and expected change process curves, the reliability of state synchronization between devices can be evaluated.

[0081] Step S1441: Configure a status monitoring interface for each device interaction object. The status monitoring interface is used to read the device's running status register value in real time.

[0082] To accurately obtain the current operating status value of device interaction objects, a status monitoring interface needs to be configured for each device interaction object. The status monitoring interface is connected to the device's operating status register and can read the values ​​in the register in real time. The operating status register records various operating status information of the device, such as the device's operating mode, fault status, and data transmission status. This status information can be fed back in real time through the status monitoring interface.

[0083] Step S1442: Convert the expected state values ​​defined in the verification requirement parameter set into the same data format and unit as the device operating status register values.

[0084] Because the expected state values ​​defined in the verification requirement parameter set and the device operating status register values ​​may have different data formats and units, the expected state values ​​need to be converted for accurate comparison. The conversion process needs to consider factors such as data type, range, and precision to ensure that the converted expected state values ​​and device operating status register values ​​are consistent in data format and units. For example, if the expected state value is represented by an abstract numerical value, while the device operating status register value is represented by a specific physical quantity, appropriate conversion and mapping are required.

[0085] Step S1443: At each point in time during message interaction, obtain the sending status value of the sender device interaction object and the receiving status value of the receiver device interaction object through the status monitoring interface.

[0086] During message interaction, each point in time corresponds to a specific device state. Through the state monitoring interface, the sending status value of the sender's device interaction object and the receiving status value of the receiver's device interaction object are obtained at each point in time. The sending status value reflects the sender's device state when sending a message, such as whether it is ready to send and the sending progress. The receiving status value reflects the receiver's device state when receiving a message, such as whether it was successfully received and the integrity of the received message.

[0087] Step S1444: Determine the expected sending status value and expected receiving status value corresponding to the time point based on the message type defined in the message interaction sequence.

[0088] The message interaction sequence defines the operation and state transition rules corresponding to different message types. Based on these rules, the expected sending and receiving state values ​​for each point in time can be determined. For example, when sending a request message, the expected sending state value might be that the device is ready to send and the sending process is normal; when receiving a response message, the expected receiving state value might be that the device has successfully received the message and the message content is complete. By determining the expected state values, a standard can be provided for subsequent state comparisons.

[0089] Step S1445: Record the time point, actual transmission status value, actual reception status value, expected transmission status value, and expected reception status value to form a status value record entry.

[0090] The actual transmit status value, actual receive status value, expected transmit status value, and expected receive status value at each time point are recorded to form status value record entries. These record entries contain information about the actual and expected status of the device at different time points and are a fundamental component of the status response data. By analyzing these record entries, the actual changes in the device status and the differences from the expected status can be determined.

[0091] Step S1446: Arrange the state value records at consecutive time points in chronological order to generate state response data containing the actual change process curve and the expected change process curve of the time series.

[0092] Arranging the state value records at consecutive time points in chronological order, with time on the horizontal axis and state value on the vertical axis, generates both the actual change process curve and the expected change process curve. The actual change process curve reflects the real changes in device state during actual message interaction, while the expected change process curve reflects the changes in device state under ideal conditions. By comparing these two curves, the reliability of device state synchronization can be visually observed, such as whether there are issues like state delays or state deviations.

[0093] Step S145: Synchronously collect the local clock time of the device interaction object, calculate the clock time difference between different device interaction objects, and record the changing trend and stability of the time difference as time synchronization data.

[0094] Time synchronization is crucial for ensuring accurate collaboration between devices during interaction. Therefore, it's necessary to synchronously collect the local clock times of the interacting devices. A synchronization mechanism ensures that the clock times of all devices are measured against the same reference. Then, the clock time differences between different interacting devices are calculated. The trends and stability of these time differences are recorded, forming time synchronization data. The trend of the time difference reflects the consistency of the device clocks at different stages of message interaction, while the stability reflects the reliability of the device clocks. For example, if the time difference fluctuates significantly over a period of time, it indicates a problem with time synchronization between devices, which may affect interaction and collaboration.

[0095] Step S146: When the triggering condition of the task termination node is met, stop the message interaction operation and close the device interaction connection.

[0096] The triggering conditions for a task termination node typically include the completion of all message interaction steps, reaching a preset verification time, or the occurrence of a serious anomaly. When these triggering conditions are met, message interaction operations are immediately stopped to avoid unnecessary resource consumption. Simultaneously, device interaction connections are closed, releasing related network and system resources. For example, after completing all predetermined message interaction steps, the task termination node is triggered, stopping communication between devices and closing the device's network connection.

[0097] Step S150: Generate an interoperability verification result based on the message transmission data, status response data, and time synchronization data. The interoperability verification result includes an interactive message integrity description, a status response consistency record, and a time synchronization accuracy description.

[0098] After collecting message transmission data, status response data, and time synchronization data, these data need to be analyzed and processed to generate interoperability verification results.

[0099] Step S151: Compare the content of the request message and response message in the message transmission data, check the integrity of the message fields, the matching of data types and the correctness of the check code, and generate an interactive message integrity description that includes a list of missing fields, a list of fields with mismatched types and a list of fields with failed verification.

[0100] A detailed comparison of request and response messages in the message transmission data is performed. First, the completeness of message fields is checked to see if any fields are missing. For example, a communication message from a highway monitoring device might specify fields such as device number, timestamp, and monitoring data. If a message is missing a field, it is recorded in the missing field list. Next, the data type matching is checked to ensure that the data type of each field in the message conforms to the specifications. For example, if a field is specified as an integer type, but the actual transmitted data is a string type, that field is recorded in the type mismatch field list. Finally, the correctness of the checksum is checked. The checksum is used to verify the completeness and accuracy of the message. If the calculated checksum does not match the checksum carried in the message, the relevant field of the message is recorded in the checksum failure field list. Through these checks and records, an interactive message integrity description is generated, intuitively reflecting any problems that exist in the message transmission process.

[0101] Step S152: Align the actual change process in the state response data with the expected change process on the time axis, calculate the state value deviation at each time point, count the number of time points where the deviation exceeds the allowable threshold and the duration, and generate a state response consistency record containing a deviation time distribution table and a deviation change curve.

[0102] Align the actual and expected change curves in the status response data along the time axis to ensure comparison of status values ​​at the same point in time. Calculate the status value deviation at each time point, i.e., the difference between the actual and expected status values. Then, set an allowable threshold and count the number of time points where the deviation exceeds the threshold and their duration. Compile these statistical results into a deviation time distribution table to clearly show the distribution of deviations at different time points. Simultaneously, plot the deviation change curve with time on the horizontal axis and deviation on the vertical axis to visually reflect the trend of deviation over time. By generating status response consistency records, the consistency and reliability of status synchronization between devices can be evaluated.

[0103] Step S153: Analyze the trend of time difference changes in the time synchronization data, calculate the average, maximum and minimum values ​​of the time difference, evaluate the stability of the time difference in different message interaction stages, and generate a time synchronization accuracy description that includes a time difference statistics table and a stability assessment level.

[0104] A thorough analysis of the time difference trends in time synchronization data is conducted. The average, maximum, and minimum values ​​of the time difference are calculated; these statistics reflect the overall situation of the time difference. The average value represents the average level of the time difference, while the maximum and minimum values ​​represent the range of fluctuation. Simultaneously, the stability of the time difference is evaluated across different message interaction stages, such as message sending, message receiving, and message processing, to assess whether the fluctuations are consistent. Based on the analysis results, a time difference statistics table is generated, recording various statistical information about the time difference. Furthermore, a stability assessment level, such as high, medium, or low, is provided based on the stability of the time difference to intuitively reflect the accuracy of time synchronization between devices.

[0105] Step S154: The integrity description of the interaction message, the consistency record of the status response, and the accuracy description of the time synchronization are structurally integrated to generate an interoperability verification result report that includes the verification task identifier, the verification time range, and an overview of the verification conclusion.

[0106] The report integrates structured descriptions of interactive message integrity, consistency records of status responses, and accuracy descriptions of time synchronization. During integration, data accuracy and consistency must be ensured. Simultaneously, a verification task identifier is added to the report to uniquely identify the verification task; a verification time range is added to specify the execution period of the verification task; and a verification conclusion summary is added to concisely summarize the verification results, such as whether the inter-device communication protocol compatibility is good, whether status synchronization is reliable, and whether anomaly handling is robust. By generating an interoperability verification result report, the verification results can be presented in a clear and standardized manner, facilitating subsequent viewing and analysis.

[0107] Step S155: Store the interoperability verification result report in the verification result database, and add an association tag corresponding to the interoperability verification task to the interoperability verification result report. The association tag includes the device interaction object identifier, the interaction protocol type identifier, and the verification target type identifier.

[0108] To facilitate the management and querying of interoperability verification result reports, they are stored in a verification result database. Simultaneously, associated tags corresponding to the interoperability verification tasks are added to the reports. The device interaction object identifier identifies the devices participating in the verification, the interaction protocol type identifier identifies the type of communication protocol used between the devices, and the verification target type identifier identifies the specific target of this verification. By adding associated tags, verification result reports can be filtered and queried based on different conditions, improving data utilization efficiency. For example, all verification results for a specific device can be queried based on the device interaction object identifier, or all verification results related to anomaly handling robustness can be queried based on the verification target type identifier.

[0109] Throughout the process, when data collection is involved, various privacy protection and leak prevention technologies are employed if the collected data is sensitive to privacy. For example, data encryption technology is used to encrypt the collected sensitive data. Data is encrypted during the data collection phase, converting it into ciphertext for storage and transmission. The encryption algorithm is selected based on the importance and security level of the data to ensure data security throughout its entire lifecycle. For instance, for sensitive data involving user identity information and transaction records in highway electromechanical equipment, a high-strength symmetric encryption algorithm is used, and only authorized equipment and systems can decrypt it.

[0110] Simultaneously, an access control mechanism is established to strictly manage access to privacy-sensitive data. Only authorized personnel and systems can access this data, and access operations are logged in detail. By setting different access permission levels, it is ensured that different personnel can only access the minimum amount of data required for their work. For example, a data administrator may have management rights to all privacy-sensitive data, but ordinary data analysts can only access a portion of the data that has been anonymized.

[0111] During data transmission, secure transmission protocols, such as SSL / TLS, are employed to ensure the confidentiality and integrity of data during network transmission. SSL / TLS protocols prevent data from being stolen or tampered with during transmission through encryption and authentication mechanisms. For example, when transmitting privacy-sensitive data between highway electromechanical equipment, a secure communication channel is established using SSL / TLS protocols to ensure data security during transmission.

[0112] In addition, regularly back up privacy-sensitive data and store the backup data in a secure location. Backup data can be recovered in the event of loss or corruption, ensuring data availability. Simultaneously, encrypt the backup data to prevent leakage during storage. For example, back up privacy-sensitive data of highway electromechanical equipment to an off-site data center and store the backup data encrypted.

[0113] During data usage, the principle of minimization is followed, using only necessary privacy-sensitive data for verification tasks. Before using data, it is anonymized to remove sensitive information. For example, when performing interoperability verification of highway electromechanical equipment, if only equipment operating status data is needed, privacy-sensitive data involving user identity and transaction records will not be used. If some privacy-sensitive data must be used, it will be anonymized, such as partially hiding user ID numbers and retaining only necessary identification information.

[0114] Figure 2 The illustration shows exemplary hardware and software components of a process engine-based autonomous interoperability verification task system 100 that can implement the ideas of this application, according to some embodiments of this application. For example, processor 120 can be used in the process engine-based autonomous interoperability verification task system 100 and to perform the functions in this application.

[0115] The process engine-based interoperability verification task autonomous operation system 100 can be a general-purpose server or a special-purpose server; both can be used to implement the process engine-based interoperability verification task autonomous operation method of this application. Although only one server is shown in this application, for convenience, the functions described in this application can be implemented in a distributed manner on multiple similar platforms to balance the load.

[0116] For example, the process engine-based interoperability verification task autonomous operation system 100 may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the process engine-based interoperability verification task autonomous operation system 100 may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of this application can be implemented according to these program instructions. The process engine-based interoperability verification task autonomous operation system 100 also includes an I / O interface 150 between the computer and other input / output devices.

[0117] For ease of explanation, only one processor is described in the process engine-based interoperability verification task autonomous operation system 100. However, it should be noted that the process engine-based interoperability verification task autonomous operation system 100 of this application may also include multiple processors. Therefore, the steps executed by one processor as described in this application may also be executed jointly by multiple processors or individually. For example, if the processor of the process engine-based interoperability verification task autonomous operation system 100 executes steps A and B, it should be understood that steps A and B may also be executed jointly by two different processors or individually by one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor jointly execute steps A and B.

[0118] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the above-mentioned method for autonomous operation of interoperability verification tasks based on process engine is implemented.

[0119] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for autonomous execution of interoperability verification tasks based on a process engine, characterized in that, The method includes: A virtual-real simulation environment is constructed, which includes field equipment operation data, laboratory scale-down component status information and software simulation model. The virtual-real simulation environment is used to simulate the actual operation scenario of the interoperability mechanism of highway electromechanical equipment. Interoperability verification tasks are generated based on a preset set of verification requirement parameters. The interoperability verification tasks include the device interaction objects to be verified, the interaction protocol types, and the interaction triggering conditions. The device interaction objects include field equipment instances, laboratory scaled-down component instances, and software simulation model instances. The process engine is invoked to parse the interoperability verification task. Based on the communication interface specification and interaction protocol type of the device interaction object, the execution flow of the interoperability verification task is planned. The execution flow includes a task start node, an interaction execution node, and a task termination node. The task start node is used to initialize the state of the device interaction object. The interaction execution node is used to perform message interaction and state verification operations. The task termination node is used to close the device interaction connection and save the verification process data. According to the execution process, the interoperability verification task is performed in the virtual-real combined simulation environment, and message transmission data, status response data and time synchronization data are collected in real time during the device interaction process. Interoperability verification results are generated based on the message transmission data, status response data, and time synchronization data. The interoperability verification results include a description of the integrity of the interaction messages, a record of the consistency of the status response, and a description of the accuracy of the time synchronization.

2. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 1, characterized in that, The construction of the virtual-real combined simulation environment includes field equipment operation data, laboratory scale-down component status information, and software simulation models, including: Acquire historical operation log data of field equipment, wherein the historical operation log data includes equipment communication message records, status change timestamps, and abnormal event trigger records; Collect the current operating status parameters of the laboratory scale-down component, including the component's input and output interface voltage values, signal transmission delay, and protocol conversion power; Load a pre-configured software simulation model, which includes a communication protocol stack module, a state machine transition rule module, and an exception injection control module for highway electromechanical equipment; The historical operation log data, current working status parameters and software simulation model are processed in a unified data format to generate a multi-source data set with spatiotemporal alignment characteristics. Based on the multi-source data set, a three-layer simulation environment structure is constructed, comprising a physical device layer, a simulation layer, and a data mapping layer. The physical device layer is used to connect field equipment and laboratory scale-down components, the simulation layer is used to run software simulation models, and the data mapping layer is used to achieve state synchronization between the physical device layer and the simulation layer.

3. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 1, characterized in that, The process of generating an interoperability verification task based on a preset set of verification requirement parameters includes the device interaction object to be verified, the interaction protocol type, and the interaction triggering conditions, including: Parse the preset set of verification requirement parameters and extract the verification target type parameter. The verification target type parameter is used to indicate whether the device communication protocol compatibility, state synchronization reliability or anomaly handling robustness needs to be verified. Based on the verification target type parameter, select the device interaction objects that need to participate in the verification from the predefined device resource library; Determine the interaction protocol type between the device interaction objects, wherein the interaction protocol type includes basic communication protocol, business data protocol and exception handling protocol; Based on the verification target type parameter and the interaction protocol type, the interaction trigger conditions are set, including normal operation trigger conditions, exception injection trigger conditions and boundary state trigger conditions. The device interaction objects, interaction protocol types, and interaction triggering conditions are encapsulated into a structured task description file, which includes a task identifier field, an object list field, a protocol description field, and a triggering condition field.

4. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 3, characterized in that, The step of setting interaction trigger conditions based on the verification target type parameter and interaction protocol type includes: When the verification target type parameter indicates that the compatibility of communication protocols between devices is verified, the normal operation trigger condition is set to the device interaction object being in the initial ready state, the exception injection trigger condition is the random insertion of error check codes or missing fields during message interaction, and the boundary state trigger condition is the load rate of the device interaction object reaching the preset load threshold. When the verification target type parameter indicates the verification state synchronization reliability, the normal operation trigger condition is set to the completion of the device interaction object initialization synchronization, the exception injection trigger condition is the interruption of the communication connection during the state change process, and the boundary state trigger condition is the state change frequency of the device interaction object reaches the preset frequency threshold. When the verification target type parameter indicates the robustness of verification exception handling, the normal operation trigger condition is set to the device interaction object receiving a legitimate request message, the exception injection trigger condition is sending an illegal format message or an excessively large data volume message to the device interaction object, and the boundary state trigger condition is the cumulative number of exception events of the device interaction object reaching a preset critical threshold. Conflict detection is performed on the triggering conditions corresponding to different verification target type parameters to ensure that mutually exclusive triggering conditions are not triggered simultaneously at the same time point. A corresponding trigger action is set for each trigger condition. The trigger action includes starting an exception injection program, adjusting the device load status, or recording interactive data under boundary conditions.

5. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 1, characterized in that, The call flow engine parses the interoperability verification task and plans the execution flow of the interoperability verification task based on the communication interface specification and interaction protocol type of the device interaction object, including: Read the task identifier field, object list field, protocol description field and trigger condition field from the task description file of the interoperability verification task, and generate a task metadata set; The communication interface specification document for each device interaction object is obtained based on the object list field. The communication interface specification document includes the protocol version supported by the interface, message format definition, and handshake process description. The message interaction order between device interaction objects is determined based on the protocol description fields and communication interface specification documents. The message interaction order includes the order of sending request messages, the order of receiving response messages, and the order of receiving confirmation messages. Combining the normal operation trigger condition, the exception injection trigger condition, and the boundary state trigger condition in the trigger condition field, a condition judgment node is inserted into the message interaction sequence. The condition judgment node is used to control the execution timing of the exception injection operation and the boundary state switching operation. The task metadata set, message interaction sequence, and condition judgment nodes are arranged into process nodes to generate a verification task execution process that includes task start node, interaction execution node, and task termination node.

6. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 5, characterized in that, The step of arranging the task metadata set, message interaction sequence, and condition judgment nodes into process nodes to generate a verification task execution flow that includes a task start node, interaction execution node, and task termination node includes: Starting with the task initiation node as the beginning of the process, set the node to perform the following actions: send an initialization command to the device interaction object and wait for a response; After the task initiation node, an interaction execution node is connected. The interaction execution node contains multiple sub-nodes. Each sub-node corresponds to a message interaction step in the message interaction sequence. The sub-node performs the following actions: sending request messages, listening for response messages, and recording interaction data. A condition judgment node is embedded in each child node. The condition judgment node performs the following actions: detect whether the exception injection trigger condition or the boundary state trigger condition is met. If it is met, the corresponding trigger action is executed and the exception handling sub-process is jumped to. If it is not met, the next child node is executed. After all child nodes have completed their execution, connect the task termination node and set the node's execution actions: close the device interaction connection, save the verification process data, and generate a termination status report. Set execution order constraints for each node so that the interactive execution node can only be executed after the task initiation node has completed execution, and the task termination node can only be executed after all child nodes of the interactive execution node have completed execution.

7. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 1, characterized in that, The interoperability verification task is performed in the virtual-real hybrid simulation environment according to the aforementioned execution flow, and message transmission data, status response data, and time synchronization data during device interaction are collected in real time, including: The task startup node that triggers the execution process sends an initialization command to all device interaction objects. The initialization command includes device address configuration parameters, protocol version negotiation parameters, and timeout setting parameters. Monitor the response of device interaction objects to initialization commands. When all device interaction objects have completed initialization and returned a success status code, trigger the message interaction operation of the interaction execution node. In message interaction operations, request messages are sent to the sending device interaction object in the order of message interaction, and the response messages returned by the receiving device interaction object are listened to. The sending timestamp and message content of the request message and the receiving timestamp and message content of the response message are recorded as message transmission data. During message interaction, the current running status value of the device interaction object is read, compared with the expected status value defined in the set of verification requirements, and the actual change process and expected change process of the status value are recorded as status response data. Synchronously collect the local clock time of the device interaction objects, calculate the clock time difference between different device interaction objects, and record the changing trend and stability of the time difference as time synchronization data; When the triggering conditions for the task termination node are met, stop message interaction operations and close the device interaction connection.

8. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 7, characterized in that, During message interaction, the current running status value of the device interaction object is read, compared with the expected status value defined in the verification requirement parameter set, and the actual change process and expected change process of the status value are recorded as status response data, including: Configure a status monitoring interface for each device interaction object. The status monitoring interface is used to read the operating status register value of the device in real time. Convert the expected state values ​​defined in the verification requirement parameter set into the same data format and units as the values ​​in the device operating status register; At each point in time during message interaction, the sending status value of the sender's device interaction object and the receiving status value of the receiver's device interaction object are obtained through the status monitoring interface. Based on the message type defined in the message interaction sequence, determine the expected sending status value and expected receiving status value corresponding to the time point; Record the time point, actual transmission status value, actual reception status value, expected transmission status value, and expected reception status value to form a status value record entry; The state value records at consecutive time points are arranged in chronological order to generate state response data containing actual change process curves and expected change process curves of the time series.

9. The method for autonomous operation of interoperability verification tasks based on a process engine according to claim 1, characterized in that, The generation of interoperability verification results based on the message transmission data, status response data, and time synchronization data includes: The request and response messages in the message transmission data are compared to check the integrity of message fields, the matching of data types, and the correctness of check codes. An interactive message integrity description is generated, which includes a list of missing fields, a list of fields with mismatched types, and a list of fields with failed verification. Align the actual change process with the expected change process in the state response data on the time axis, calculate the state value deviation at each time point, count the number of time points where the deviation exceeds the allowable threshold and the duration of the deviation, and generate a state response consistency record containing a deviation time distribution table and a deviation change curve. Analyze the trend of time difference in the time synchronization data, calculate the average, maximum and minimum values ​​of the time difference, evaluate the stability of the time difference at different message interaction stages, and generate a time synchronization accuracy description that includes a time difference statistics table and a stability assessment level. The integrity description of the interaction messages, the consistency record of the status response, and the description of the accuracy of time synchronization are structured and integrated to generate an interoperability verification result report that includes the verification task identifier, the verification time range, and an overview of the verification conclusion. The interoperability verification result report is stored in the verification result database, and an associated tag corresponding to the interoperability verification task is added to the interoperability verification result report. The associated tag includes the device interaction object identifier, the interaction protocol type identifier, and the verification target type identifier.

10. An interoperability verification task autonomous operation system based on a process engine, characterized in that, The system includes a processor and a memory, the memory being connected to the processor. The memory is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the memory to implement the autonomous operation method for interoperability verification tasks based on a process engine as described in any one of claims 1-9.

Images