Method and system for autonomously running interoperation verification task based on process engine

Abstract

The invention provides an interoperation verification task autonomous operation method and system based on a process engine, and the method comprises the steps: simulating an actual operation scene of a highway electromechanical equipment interoperation mechanism through constructing a virtual-real combined simulation environment which comprises external field equipment operation data, laboratory scale component state information and a software simulation model; generating an interoperation verification task according to a preset verification demand parameter set, calling a process engine to analyze the task and plan an execution process, executing the task in a virtual-real combined simulation environment according to the execution process, and collecting message transmission data, state response data and time synchronization data in a device interaction process in real time; and based on the message transmission data, the state response data and the time synchronization data, generating an interoperation verification result containing an interaction message integrity description, a state response consistency record and a time synchronization accuracy description, thereby autonomously planning a verification task and providing a comprehensive and real test environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtual-real combined testing, in particular to an interoperation verification task autonomous running method and system based on a process engine. BACKGROUND

[0002] In the field of highway electromechanical equipment, the interoperability between different equipment is crucial for ensuring the normal operation of the highway system, improving traffic efficiency and safety. Currently, the verification of the interoperability of highway electromechanical equipment mainly relies on traditional manual testing methods and simple simulation software. Manual testing methods require a large amount of manpower, and testers need to manually operate equipment and record data, which is not only inefficient, but also prone to human error, making it difficult to ensure the accuracy and reliability of test results. Simple simulation software can simulate the running state of some equipment, but it can only simulate a single type of equipment or simple interaction scenarios, and cannot fully and realistically simulate the complex interoperation mechanism of highway electromechanical equipment in actual operating environment. In addition, the existing verification methods lack autonomous planning and management capabilities for verification tasks, and cannot flexibly adjust the verification process according to different verification requirements, making it difficult to meet the growing demand for interoperability verification of highway electromechanical equipment. SUMMARY

[0003] In view of the above-mentioned problems, in combination with the first aspect of the present application, the embodiments of the present application provide an interoperation verification task autonomous running method based on a process engine, which comprises:

[0004] A virtual-real combined realistic environment containing field equipment running data, laboratory scaled component state information and software simulation model is constructed, which is used to simulate the actual operating scene of the interoperation mechanism of highway electromechanical equipment;

[0005] An interoperation verification task is generated according to a preset set of verification requirement parameters, which contains the equipment interaction object to be verified, the interaction protocol type and the interaction trigger condition;

[0006] A process engine is called to analyze the interoperation verification task, and an execution process of the interoperation verification task is planned based on the communication interface specification of the equipment interaction object and the interaction protocol type, which contains a task start node, an interaction execution node and a task termination node;

[0007] The interoperation verification task is executed in the virtual-real combined realistic environment according to the execution process, and message transmission data, state response data and time synchronization data in the equipment interaction process are collected in real time;

[0008] An interoperability verification result is generated based on the message transmission data, state response data and time synchronization data, and the interoperability verification result includes an interactive message integrity description, a state response consistency record and a time synchronization accuracy description.

[0009] In another aspect, the embodiment of the present application also provides a process engine-based interoperability verification task autonomous running system, which comprises a processor and a machine readable storage medium, the machine readable storage medium is connected with the processor, the machine readable storage medium is used for storing programs, instructions or codes, and the processor is used for executing the programs, instructions or codes in the machine readable storage medium to realize the above method.

[0010] Based on the above aspects, the embodiment of the present application can highly realistically simulate the actual running scene of the interoperability mechanism of the highway electromechanical equipment by constructing a virtual-real combined realistic environment including the field equipment running data, the laboratory scaled component state information and the software simulation model, and provides a comprehensive and real test environment for the interoperability verification, thereby guaranteeing the reliability of the verification result from the source. The interoperability verification task is generated according to the preset verification requirement parameter set, the process engine is called to analyze the task, the execution process is planned based on the communication interface specification and the interactive protocol type of the equipment interactive object, the autonomous planning and management of the verification task are realized, the verification process can be flexibly adjusted according to different verification requirements, the efficiency and flexibility of the verification are improved, the interoperability verification task is executed in the virtual-real combined realistic environment according to the execution process, and various data in the equipment interactive process are collected in real time, and finally the interoperability verification result including the interactive message integrity description, the state response consistency record and the time synchronization accuracy description is generated based on the collected data, the interoperability of the highway electromechanical equipment is comprehensively and accurately reflected, and the level of the interoperability verification of the highway electromechanical equipment is effectively improved. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 is an execution process schematic diagram of the process engine-based interoperability verification task autonomous running method provided by the embodiment of the present application.

[0012] Figure 2 is a schematic diagram of exemplary hardware and software components of the process engine-based interoperability verification task autonomous running system provided by the embodiment of the present application. DETAILED DESCRIPTION

[0013] The present application will be described in detail below with reference to the accompanying drawings, Figure 1 is a process schematic diagram of the process engine-based interoperability verification task autonomous running method provided by an embodiment of the present application, and the process engine-based interoperability verification task autonomous running method will be described in detail below.

[0014] Step S110: A virtual-real combined realistic environment containing field equipment operation data, laboratory scaled component state information and software simulation model is constructed, and the virtual-real combined realistic environment is used to simulate actual operation scenarios of the highway electromechanical equipment interoperation mechanism.

[0015] In the embodiment, in the process of research and development and testing of the highway electromechanical equipment, in order to accurately simulate the actual operation scenarios of the interoperation mechanism, a virtual-real combined realistic environment needs to be constructed. The realistic environment integrates field equipment operation data, laboratory scaled component state information and software simulation model to achieve high restoration of the real scene.

[0016] Step S111: Historical operation log data of the field equipment is obtained, and the historical operation log data contains device communication message records, state change time stamps and abnormal event trigger records.

[0017] In the embodiment, the field equipment will generate a large amount of historical operation log data in the long-term operation process, and these historical operation log data are real records of the actual operation of the equipment. The device communication message records record the content of the messages transmitted when the devices communicate, including the format, data field and transmission time sequence of the messages. The state change time stamp accurately records the specific time point when the device state changes, for example, the time when the device switches from normal operation state to fault state or from fault state to normal operation state. The abnormal event trigger record records the related information of the abnormal event occurring in the operation process of the device, such as the type of the abnormal event, the trigger condition and the impact generated. By collecting and analyzing these historical operation log data, various situations of the field equipment in actual operation can be determined.

[0018] Step S112: Current working state parameters of the laboratory scaled component are collected, and the working state parameters contain component input and output interface voltage values, signal transmission delay and protocol conversion success rate.

[0019] The laboratory scaled component is a simulation of the highway electromechanical equipment in a reduced scale, and its working state parameters can reflect part of the characteristics of the actual equipment. The component input and output interface voltage value is an important indicator for measuring the electrical performance of the component, and a normal voltage value range can ensure the stable operation of the component. The signal transmission delay reflects the time spent for the signal transmission inside the component, and a large delay may affect the communication efficiency and data transmission accuracy between devices. The protocol conversion success rate represents the success rate of the component when converting between different communication protocols, and a high protocol conversion success rate can ensure the compatibility and interoperability of the equipment in different protocol environments. By collecting these current working state parameters, the running status of the laboratory scaled component can be determined in real time.

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

[0021] The software simulation model is an important part of the simulation environment, which can simulate various behaviors and characteristics of the highway electromechanical equipment. The communication protocol stack module simulates various protocols followed by the highway electromechanical equipment when communicating, including physical layer protocol, data link layer protocol, network layer protocol, etc., to ensure correct data transmission and interaction between devices. The state machine transition rule module defines the transition rules of device state under different conditions, such as how the state will change when the device receives a specific instruction or a specific event occurs. The exception injection control module can simulate various abnormal situations, such as communication failure, data loss, device failure, etc., to test the response ability and stability of the device under abnormal conditions. By loading the pre-configured software simulation model, various running scenarios of the highway electromechanical equipment can be simulated in the virtual environment.

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

[0023] Since the historical running log data, current working state parameters, and software simulation model come from different sources, their data formats may differ. In order to effectively integrate the historical running log data, current working state parameters, and software simulation model, data format uniform processing is required. In the process of uniform data format, the time and space characteristics of the data need to be considered to ensure that the historical running log data, current working state parameters, and software simulation model are aligned in time and space. For example, for historical running log data and current working state parameters, the timestamps of historical running log data, current working state parameters, and software simulation model need to be unified to facilitate analysis and comparison in the same time dimension. For software simulation model, the simulated data needs to be matched with the actually collected data to ensure consistency in space. Through data format uniform processing, a multi-source data set with spatiotemporal alignment characteristics 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 simulation layer, and a data mapping layer. The physical device layer is used to connect field equipment and laboratory scale components, the simulation simulation layer is used to run software simulation models, and the data mapping layer is used to realize state synchronization between the physical device layer and the simulation simulation layer.

[0025] The physical device layer is the interface between the virtual environment and the real world, which is responsible for connecting field devices and laboratory scale components. Through the physical device layer, real-time operation data of field devices and working state parameters of laboratory scale components can be obtained, providing real data sources for the virtual environment. The simulation layer is the core of the virtual environment, which runs software simulation models to simulate various behaviors and characteristics of road mechanical and electrical equipment. In the simulation layer, different parameters and scenarios can be set according to different testing requirements to simulate various actual operating conditions. The data mapping layer acts as a bridge, which is responsible for realizing the state synchronization between the physical device layer and the simulation layer. Through the data mapping layer, the actual data collected by the physical device layer can be mapped to the simulation layer, so that the simulation model can be dynamically adjusted according to the actual situation; at the same time, virtual data generated by the simulation layer can be fed back to the physical device layer to realize the interaction between virtual and reality. By constructing a three-layer virtual environment structure, the actual operating scene of the interoperability mechanism of road mechanical and electrical equipment can be highly simulated.

[0026] Step S120: generating an interoperability verification task according to the preset verification requirement parameter set, the interoperability verification task containing the device interaction object to be verified, the interaction protocol type and the interaction trigger condition.

[0027] After the virtual-real combined virtual environment is constructed, the interoperability verification task needs to be generated according to the preset verification requirement parameter set. These interoperability verification tasks will be used to comprehensively verify the interoperability mechanism of road mechanical and electrical equipment.

[0028] Step S121: parsing the preset verification requirement parameter set, extracting the verification target type parameter, the verification target type parameter being used to indicate whether the device communication protocol compatibility, state synchronization reliability or exception handling robustness needs to be verified.

[0029] The preset verification requirement parameter set contains various verification related parameter information, among which the verification target type parameter is one of the key information. The verification target type parameter clearly indicates the specific goal of this verification task, i.e., whether the device communication protocol compatibility, state synchronization reliability or exception handling robustness needs to be verified. For example, if the verification target type parameter indicates the verification of device communication protocol compatibility, the subsequent verification task will mainly focus on the interaction of devices under different communication protocols; if it indicates the verification of state synchronization reliability, it will focus on the synchronization of state information between devices; if it indicates the verification of exception handling robustness, it needs to simulate various abnormal situations to test the processing ability of devices under abnormal situations.

[0030] Step S122: Filter the device interaction objects that need to participate in the verification from the pre-defined device resource library according to the verification target type parameter, wherein the device interaction objects include field device instances, laboratory scaled component instances, and software simulation model instances.

[0031] The pre-defined device resource library contains various field device instances, laboratory scaled component instances, and software simulation model instances. According to the verification target type parameter, appropriate device interaction objects can be selected from the device resource library to participate in the verification task. For example, if the verification target is the compatibility of inter-device communication protocols, field device instances and laboratory scaled component instances of different brands and models, as well as software simulation model instances that can simulate different communication protocols, may need to be selected to comprehensively test the compatibility of devices under different protocol environments.

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

[0033] After determining the device interaction objects, it is necessary to further clarify the interaction protocol type between them. The basic communication protocol specifies the rules and methods for basic communication between devices, such as data transmission format, communication baud rate, etc. The business data protocol specifies the transmission and processing method of business data for specific business needs, such as the toll data transmission protocol in a highway toll system. The exception handling protocol is used to handle exceptions that occur during device operation, such as communication failure, data error, etc. Clarifying the interaction protocol type between device interaction objects helps accurately perform verification tasks and ensures that devices can interact normally under different protocols.

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

[0035] The interaction trigger condition is an important factor in controlling device interaction behavior, which is set according to the verification target type parameter and the interaction protocol type. The normal operation trigger condition is used to trigger the interaction behavior of the device under normal conditions, such as starting normal communication interaction when the device is in the initial ready state. The exception injection trigger condition is used to simulate various abnormal situations, such as randomly inserting error check codes or missing fields during message interaction, to test the processing capability of the device under abnormal conditions. The boundary state trigger condition is used to test the performance of the device under the limit state, such as triggering the corresponding interaction operation when the load rate of the device reaches the preset load threshold.

[0036] Step S1241: When the verification target type parameter indicates verification of inter-device communication protocol compatibility, the normal operation trigger condition is set as the device interaction object being in an initial ready state, the abnormality injection trigger condition is set as randomly inserting an error check code or missing fields in the message interaction process, and the boundary state trigger condition is set as the load rate of the device interaction object reaching a preset load threshold.

[0037] If the verification target is inter-device communication protocol compatibility, the normal operation trigger condition is set as the device interaction object being in an initial ready state, which ensures that the device starts communication interaction after normal startup to test its protocol compatibility under normal conditions. The abnormality injection trigger condition is set as randomly inserting an error check code or missing fields in the message interaction process, which tests the device's processing capability under protocol error conditions by simulating these abnormal conditions. The boundary state trigger condition is set as the load rate of the device interaction object reaching a preset load threshold, which tests the device's protocol compatibility under high load conditions when the device load is too high.

[0038] Step S1242: When the verification target type parameter indicates verification of state synchronization reliability, the normal operation trigger condition is set as the device interaction object completing initialization synchronization, the abnormality injection trigger condition is set as interrupting the communication connection during state change, and the boundary state trigger condition is set as the state change frequency of the device interaction object reaching a preset frequency threshold.

[0039] When the verification target is state synchronization reliability, the normal operation trigger condition is set as the device interaction object completing initialization synchronization, which is a prerequisite for ensuring that the device performs subsequent verification based on state synchronization. The abnormality injection trigger condition is set as interrupting the communication connection during state change, which simulates communication failure conditions and tests the device's state synchronization capability when communication is interrupted. The boundary state trigger condition is set as the state change frequency of the device interaction object reaching a preset frequency threshold, which tests the device's synchronization reliability under high-frequency state change conditions when state changes are too frequent.

[0040] Step S1243: When the verification target type parameter indicates verification of abnormality processing robustness, the normal operation trigger condition is set as the device interaction object receiving a legal request message, the abnormality injection trigger condition is set as sending an illegal format message or a large data volume message to the device interaction object, and the boundary state trigger condition is set as the cumulative number of abnormal events of the device interaction object reaching a preset critical threshold.

[0041] If the verification target is abnormality processing robustness, the normal operation trigger condition is set as the device interaction object receiving a legal request message, which is a basic condition for the normal operation of the device. The abnormality injection trigger condition is set as sending an illegal format message or an excessively large data volume message to the device interaction object. By simulating these abnormal conditions, the processing capability of the device in the face of illegal input is tested. The boundary state trigger condition is set as the cumulative number of abnormal events of the device interaction object reaching a preset critical threshold. When the abnormal events accumulate to a certain degree, whether the device can remain stable operation and whether the device can correctly handle these abnormal conditions are tested.

[0042] Step S1244: Conflict detection is performed on the trigger conditions corresponding to different verification target type parameters, so that mutually exclusive trigger conditions are not triggered at the same time point.

[0043] The trigger conditions corresponding to different verification target type parameters may conflict. If mutually exclusive trigger conditions are triggered at the same time point, the verification result may be inaccurate. Therefore, conflict detection needs to be performed on these trigger conditions. For example, the abnormality injection trigger condition set when verifying the compatibility of the inter-device communication protocol and the abnormality injection trigger condition set when verifying the state synchronization reliability may conflict. Through conflict detection, the above situation can be avoided, and the smooth progress of the verification task is ensured.

[0044] Step S1245: A corresponding trigger action is set for each trigger condition, and the trigger action includes starting an abnormality injection program, adjusting a device load state, or recording interaction data in a boundary state.

[0045] Each trigger condition needs to be set with a corresponding trigger action to achieve the corresponding verification purpose. When the trigger condition is met, the corresponding trigger action is executed. For example, when the abnormality injection trigger condition is met, the abnormality injection program is started to simulate abnormal conditions; when the boundary state trigger condition is met, the device load state is adjusted or the interaction data in the boundary state is recorded for subsequent analysis of the performance of the device in special conditions.

[0046] Step S125: The device interaction object, the interaction protocol type, and the interaction trigger condition are encapsulated into a structured task description file, and the task description file includes a task identification field, an object list field, a protocol description field, and a trigger condition field.

[0047] To facilitate the management and execution of the interoperability verification task, the device interaction object, the interaction protocol type and the interaction trigger condition are encapsulated into a structured task description file. The task identification field is used to uniquely identify the verification task, facilitating subsequent query and management. The object list field lists the device interaction objects participating in the verification task, including field device instances, laboratory scaled component instances and software simulation model instances. The protocol description field describes the interaction protocol type between the device interaction objects in detail, including the basic communication protocol, the business data protocol and the exception handling protocol. 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 into a task description file, the related information of the verification task can be uniformly managed, and the execution efficiency of the verification task can be improved.

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

[0049] After generating the interoperability verification task, the flow engine needs to be called to parse it and plan the execution flow of the verification task. The flow engine can reasonably arrange each step of the verification task according to the communication interface specification and the interaction protocol type of the device interaction object, to ensure the smooth execution of the verification task.

[0050] Step S131: reading the task identification field, the object list field, the protocol description field and the trigger condition field in the task description file of the interoperability verification task, and generating a task metadata set.

[0051] The flow engine first reads the task description file of the interoperability verification task, extracts the task identification field, the object list field, the protocol description field and the trigger condition field and other key information from it. These information constitute the task metadata set, which contains the basic information and execution requirements of the verification task. The task identification field is used to uniquely identify the verification task, the object list field specifies the device interaction objects participating in the verification, the protocol description field describes the interaction protocol type between the devices, and the trigger condition field specifies various trigger conditions in the verification process. By generating the task metadata set, the flow engine can determine the specific content of the verification task comprehensively.

[0052] Step S132: obtaining the communication interface specification document of each device interaction object according to the object list field, the communication interface specification document including the protocol version supported by the interface, the message format definition and the handshake flow description.

[0053] According to the object list field in the task metadata set, the process engine can obtain the communication interface specification document of each device interaction object. These documents describe the various characteristics of the device interface in detail, including the supported protocol version of the interface, message format definition, and handshake process description, etc. The supported protocol version of the interface specifies the specific version of the communication protocol that the device can support, and different protocol versions may differ in function and performance. The message format definition explicitly defines the specific format of the message when communicating between devices, including the header, data field, and check code of the message, etc. The handshake process description describes the interaction process when establishing a communication connection, such as sending a handshake request, receiving a handshake response, etc. By obtaining the communication interface specification document, the process engine can determine the communication capability and interaction mode of the device interaction object.

[0054] Step S133: Determine the message interaction order between device interaction objects based on the protocol description field and the communication interface specification document, the message interaction order including request message sending order, response message receiving order, and confirmation message feedback order.

[0055] In combination with the protocol description field in the task metadata set and the communication interface specification document of the device interaction object, the process engine can determine the message interaction order between the device interaction objects. The request message sending order specifies the sequence of initiating communication requests by the device, the response message receiving order specifies the sequence of receiving response messages by the device, and the confirmation message feedback order describes the sequence of sending confirmation messages by the device after receiving the response message. For example, in a verification task of a highway toll system, the toll device may first send a request message to the monitoring device, the monitoring device receives the request message and sends a response message to the toll device, and the toll device sends a confirmation message to the monitoring device. By determining the message interaction order, the process engine can ensure that the communication interaction between devices is carried out in the correct order, avoiding the situation of message confusion or loss.

[0056] Step S134: In combination with the normal operation trigger condition, the abnormal injection trigger condition, and the boundary state trigger condition in the trigger condition field, insert a condition judgment node in the message interaction order, the condition judgment node is used to control the execution timing of the abnormal injection operation and the boundary state switching operation.

[0057] After determining the message interaction sequence, the flow engine needs to insert condition judgment nodes in the message interaction sequence in combination with various trigger conditions in the trigger condition field. The condition judgment node can monitor various state information in the verification process in real time, and perform corresponding operations when a specific trigger condition is met. For example, when the abnormal injection trigger condition is met, the condition judgment node will trigger the abnormal injection operation, such as randomly inserting an error check code or missing a field in the message interaction process; when the boundary state trigger condition is met, the condition judgment node will trigger the boundary state switching operation, such as adjusting the load state of the device. By inserting the condition judgment node, the injection of abnormal conditions and the switching of boundary states can be flexibly controlled in the verification process, improving the comprehensiveness and accuracy of the verification task.

[0058] Step S135: The task metadata set, message interaction sequence and condition judgment node are flow node arranged to generate a verification task execution flow containing a task start node, an interaction execution node and a task termination node. The task start node is used to initialize the device interaction object state, the interaction execution node is used to execute the message interaction and state verification operation, and the task termination node is used to close the device interaction connection and save the verification process data.

[0059] The flow engine arranges the task metadata set, message interaction sequence and condition judgment node to generate a complete verification task execution flow. The task start node is the starting point of the verification task, which is responsible for initializing the state of the device interaction object, such as sending initialization instructions, setting device parameters, etc., to ensure that the device is in a verifiable state. The interaction execution node is the core part of the verification task, which executes the message interaction operation between devices according to the message interaction sequence and performs state verification to check whether the state of the device meets the expectation.

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

[0061] Step S1351: Take the task start node as the starting point of the flow, and set the node execution action: send initialization instructions to the device interaction object and wait for the response.

[0062] The task starting node is the starting point of the whole verification task execution process, and its main execution action is to send initialization instructions to the device interactive object. The initialization instructions contain important information such as device address configuration parameters, protocol version negotiation parameters, and timeout time setting parameters. The device address configuration parameters are used to determine the unique address of the device in the network, ensuring accurate communication between devices. The protocol version negotiation parameters are used to negotiate the communication protocol version used between devices to ensure that devices interact in the same protocol environment. The timeout time setting parameter specifies the maximum time for the device to wait for a response, avoiding verification task stagnation due to long waiting time. After sending the initialization instructions, the response of the device interactive object needs to be waited for to confirm whether the device is successfully initialized.

[0063] Step S1352: Connect the interactive execution node after the task starting node, and the interactive execution node contains multiple sub-nodes, each sub-node corresponding to a message interaction step in the message interaction sequence. The sub-node execution action is to send a request message, listen to a response message, and record interaction data.

[0064] After the task starting node is successfully executed, the interactive execution node is connected. The interactive execution node is composed of multiple sub-nodes, each sub-node corresponding to a message interaction step in the message interaction sequence. The main execution actions of the sub-node include sending a request message, listening to a response message, and recording interaction data. When sending a request message, the request message is accurately sent to the target device according to the message interaction sequence. At the same time, a listening mechanism is started to wait for the response message returned by the target device. Once the response message is received, the sending timestamp of the request message, the message content, and the receiving timestamp of the response message, the message content are immediately recorded. The above recorded data constitutes the message transmission data.

[0065] Step S1353: Embed a condition judgment node in each sub-node, and the condition judgment node performs the action of detecting whether the abnormal injection trigger condition or the boundary state trigger condition is met, and if met, performs the corresponding trigger action and jumps to the abnormal handling sub-process, and if not met, continues to execute the next sub-node.

[0066] In order to simulate various abnormal conditions and boundary states in the verification process, conditional judgment nodes are embedded in each sub-node. The conditional judgment nodes can detect the current verification state in real time, and determine whether the abnormal injection trigger condition or the boundary state trigger condition is met. If the abnormal injection trigger condition is met, such as the condition of inserting an error check code or missing a field in the message interaction process, the conditional judgment node will immediately execute the corresponding trigger action to start the abnormal injection program and simulate abnormal conditions. If the boundary state trigger condition is met, such as the load rate of the device reaching the preset load threshold, the conditional judgment node will adjust the device load state or record the interaction data under the boundary state. When the trigger condition is met, the flow jumps to the abnormal handling sub-flow to handle the abnormal conditions; if the trigger condition is not met, the next sub-node is executed to ensure the normal progress of the verification task.

[0067] Step S1354: After the execution of all sub-nodes is completed, the task termination node is connected, and the node execution action is set: the device interaction connection is closed, the verification process data is saved, and a termination state report is generated.

[0068] When all sub-nodes of the interaction execution node are executed, the task termination node is connected. The execution action of the task termination node includes closing the device interaction connection and releasing related resources to avoid waste of resources. At the same time, various data generated in the verification process, such as message transmission data, state response data, and time synchronization data, are saved. In addition, a termination state report is generated, which includes the execution situation of the verification task, the state information of the device, and whether an abnormality occurs.

[0069] Step S1355: Set the execution order constraint relationship for each node, so that the task start node can be executed only after the interaction execution node is executed, and the task termination node can be executed only after all sub-nodes of the interaction execution node are executed.

[0070] In order to ensure the correctness and orderliness of the verification task execution flow, the execution order constraint relationship needs to be set for each node. The task start node is the starting point of the entire flow, and only when the task start node is successfully executed and the device interaction object is initialized and returns a successful status code, the interaction execution node can be executed. The interaction execution node includes multiple sub-nodes, which must be executed in the order of message interaction. Only when all sub-nodes are executed, the task termination node can be executed. By setting the execution order constraint relationship, the verification task can be ensured to proceed according to the predetermined flow, and the execution confusion can be avoided.

[0071] Step S140: According to the execution flow, the interoperation verification task is executed in the virtual-real combined simulation environment, and message transmission data, state response data, and time synchronization data in the device interaction process are collected in real time.

[0072] After the execution flow plan of the interoperability verification task is completed, the verification task needs to be performed in the virtual-real combined simulation environment according to the execution flow, and relevant data needs to be collected in real time.

[0073] Step S141: Trigger the task start node of the execution flow to send initialization instructions to all device interactive objects, and the initialization instructions include device address configuration parameters, protocol version negotiation parameters and timeout time setting parameters.

[0074] First, trigger the task start node of the execution flow to send initialization instructions to all devices participating in the verification. The device address configuration parameters in the initialization instructions ensure that the device has a unique identifier in the network, facilitating communication and identification between devices. The protocol version negotiation parameters enable devices to negotiate a commonly supported communication protocol version, ensuring communication compatibility. The timeout time setting parameters specify the maximum time for devices to wait for a response, preventing devices from being in a waiting state for a long time. For example, in the verification scene of highway electromechanical devices, by sending initialization instructions, each device (such as monitoring devices, charging devices, etc.) determines its own address, negotiates the communication protocol version, and sets the timeout time.

[0075] Step S142: Monitor the response results of the device interactive objects to the initialization instructions, and when all device interactive objects complete initialization and return a successful status code, trigger the message interaction operation of the interactive execution node.

[0076] After sending the initialization instructions, the response results of the device interactive objects need to be monitored in real time. Each device can perform the corresponding initialization operation according to the instruction content after receiving the initialization instruction, and return a status code to indicate the initialization result. When all device interactive objects complete initialization and return a successful status code, it means that the devices are ready for subsequent message interaction operations, at which point the message interaction operation of the interactive execution node is triggered. If a device returns a failure status code, the device needs to be checked and debugged to ensure that it can be initialized normally.

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

[0078] In the message interaction operation of the interaction execution node, the message interaction sequence is strictly followed. A request message is sent to the sending device interaction object, and the request message contains specific business requirements or operation instructions. At the same time, a monitoring mechanism is started to wait for a response message returned by the receiving device interaction object. Once the response message is received, the sending time stamp, message content of the request message, and the receiving time stamp, message content of the response message are immediately recorded. These recorded data constitute message transmission data, and by analyzing these data, the timeliness, accuracy and integrity of message transmission between devices can be determined. For example, in the verification of a highway toll system, the toll device sends a toll request message to the monitoring device, and the monitoring device returns a toll confirmation message, and the sending and receiving time stamps and contents of the two messages are recorded.

[0079] Step S144: In the message interaction process, the current running state value of the device interaction object is read, and the actual change process and the expected change process of the state value are recorded as state response data by comparing the expected state value defined in the verification requirement parameter set.

[0080] In the message interaction process, the current running state value of the device interaction object needs to be read in real time. In order to achieve this purpose, a state monitoring interface is configured for each device interaction object, which is used to read the running state register value of the device in real time. At the same time, the expected state value defined in the verification requirement parameter set is converted into the same data format and unit as the device running state register value, so as to accurately compare. At each time point of message interaction, the sending state value of the sending device interaction object and the receiving state value of the receiving device interaction object are obtained through the state monitoring interface. According to the message type defined in the message interaction sequence, the expected sending state value and the expected receiving state value corresponding to the time point are determined. The time point, the actual sending state value, the actual receiving state value, the expected sending state value and the expected receiving state value are recorded to form a state value record entry. The state value record entries of consecutive time points are arranged in time sequence to generate state response data containing actual change process curve and expected change process curve of time sequence. By comparing the actual change process curve and the expected change process curve, the reliability of state synchronization between devices can be evaluated.

[0081] Step S1441: A state monitoring interface is configured for each device interaction object, and the state monitoring interface is used to read the running state register value of the device in real time.

[0082] In order to accurately obtain the current running state value of the device interaction object, a state monitoring interface needs to be configured for each device interaction object. The state monitoring interface is connected to the running state register of the device and can read the value in the register in real time. The running state register records various running state information of the device, such as the working mode, fault state, data transmission state, etc. of the device. Through the state monitoring interface, the above state information can be fed back in real time.

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

[0084] Since the expected state value defined in the verification requirement parameter set and the device running state register value may have different data formats and units, in order to be able to accurately compare, the expected state value needs to be converted. The conversion process needs to consider factors such as the type, range and precision of the data, to ensure that the converted expected state value is consistent with the device running state register value in data format and unit. For example, if the expected state value is represented by an abstract numerical value, and the device running state register value is represented by a specific physical quantity, corresponding conversion and mapping need to be performed.

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

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

[0087] Step S1444: According to the message type defined in the message interaction sequence, determine the expected sending state value and the expected receiving state value corresponding to the time point.

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

[0089] Step S1445: Record the time point, actual sending state value, actual receiving state value, expected sending state value, and expected receiving state value to form a state value record entry.

[0090] The actual sending state value, actual receiving state value, expected sending state value, and expected receiving state value of each time point are recorded to form a state value record entry. These record entries contain the actual state and expected state information of the device at different time points, and are the basic components of the state response data. Through analysis of these record entries, the actual changes in the state of the device and the differences from the expected situation can be determined.

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

[0092] The state value record entries of consecutive time points are arranged in chronological order, with time as the horizontal axis and state value as the vertical axis, to generate actual change process curves and expected change process curves. The actual change process curve reflects the real changes in the state of the device in the actual message interaction process, and the expected change process curve reflects the changes in the state of the device under ideal conditions. By comparing the two curves, the reliability of the synchronization of the state of the device, such as whether there are state delays, state deviations, and other problems, can be directly observed.

[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 change trend and stability of the time difference value as time synchronization data.

[0094] In the device interaction process, time synchronization is an important factor to ensure accurate cooperation between devices. Therefore, the local clock time of the device interaction object needs to be synchronously collected. Through a certain synchronization mechanism, the clock times of the devices are ensured to be measured under the same reference. Then, the clock time difference between different device interaction objects is calculated. The change trend and stability of these time difference values are recorded to form time synchronization data. The change trend of the time difference value reflects the consistency of the device clock at different message interaction stages, and the stability reflects the reliability of the device clock. For example, if the time difference value fluctuates greatly over a period of time, it indicates that there is a problem with the time synchronization between the devices, which may affect the interaction and cooperation between the devices.

[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 of the task termination node usually include completion of all message interaction steps, reaching a preset verification time, or occurrence of a serious abnormal situation, etc. When these triggering conditions are met, the message interaction operation is immediately stopped to avoid unnecessary resource consumption. At the same time, the device interaction connection is closed to release relevant network resources and system resources. For example, after completing all the scheduled message interaction steps, the task termination node is triggered to stop the communication between devices and close the network connection of the devices.

[0097] Step S150: generating an interoperation verification result based on the message transmission data, the state response data, and the time synchronization data, the interoperation verification result including an interaction message integrity description, a state response consistency record, and a time synchronization accuracy description.

[0098] After collecting the message transmission data, the state response data, and the time synchronization data, these data need to be analyzed and processed to generate an interoperation verification result.

[0099] Step S151: performing content comparison on the request messages and the response messages in the message transmission data, checking the integrity of the message fields, the matching of the data types, and the correctness of the check codes, and generating an interaction message integrity description including a missing field list, a type mismatch field list, and a check failure field list.

[0100] The request messages and the response messages in the message transmission data are compared in detail. First, the integrity of the message fields is checked to see if there are missing fields in the messages. For example, in a communication message of a highway monitoring device, there may be fields including a device number, a timestamp, and monitoring data. If one of these fields is missing in a message, the field is recorded in the missing field list. Then, the matching of the data types is checked to ensure that the data types of each field in the message meet the specifications. For example, if a field is specified as an integer type but the actual transmitted data is a string type, the field is recorded in the type mismatch field list. Finally, the correctness of the check codes is checked. The check code is used to verify the integrity and accuracy of the message. If the check code calculation result does not match the check code carried in the message, the related field of the message is recorded in the check failure field list. Through these checks and records, the interaction message integrity description is generated to intuitively reflect the problems existing in the message transmission process.

[0101] Step S152: time axis alignment of the actual change process in the state response data with the expected change process, calculation of the state value deviation amount at each time point, statistics of the number of time points and the duration of the time points whose deviation amount exceeds the allowed threshold, and generation of a state response consistency record including a deviation time distribution table and a deviation amount change curve.

[0102] The actual change process curve and the expected change process curve in the state response data are time axis aligned to ensure comparison of state values at the same time point. The state value deviation at each time point, i.e., the difference between the actual state value and the expected state value, is calculated. Then, an allowed threshold is set, and the number of time points and the duration of time points whose deviation exceeds the threshold are counted. The statistical results are arranged into a deviation time distribution table to clearly show the distribution of deviations at different time points. At the same time, a deviation amount change curve is drawn with time as the horizontal axis and deviation amount as the vertical axis to intuitively reflect the trend of deviation amount change over time. By generating the state response consistency record, the consistency and reliability of state synchronization between devices can be evaluated.

[0103] Step S153: Analyze the time difference value trend in the time synchronization data, calculate the average, maximum and minimum of the time difference value, evaluate the stability of the time difference value at different message interaction stages, and generate a time synchronization accuracy description containing a time difference statistical table and a stability evaluation level.

[0104] The time difference value trend in the time synchronization data is analyzed in depth. The average, maximum and minimum of the time difference value are calculated, which can reflect the overall situation of the time difference value. The average value represents the average level of the time difference value, and the maximum and minimum values represent the fluctuation range of the time difference value. At the same time, the stability of the time difference value at different message interaction stages is evaluated, such as the message sending stage, the message receiving stage and the message processing stage, whether the fluctuation of the time difference value is consistent. According to the analysis result, a time difference statistical table is generated to record various statistical information of the time difference value. And according to the stability of the time difference value, a stability evaluation level is given, such as high, medium and low, to intuitively reflect the accuracy of time synchronization between devices.

[0105] Step S154: Structurally integrate the interaction message integrity description, state response consistency record and time synchronization accuracy description to generate an interoperation verification result report containing verification task identification, verification time range and verification conclusion summary.

[0106] The interaction message integrity description, state response consistency record and time synchronization accuracy description are structurally integrated. In the integration process, the accuracy and consistency of the data must be ensured. At the same time, the verification task identification is added in the report to uniquely identify the verification task; the verification time range is added to clearly define the execution time period of the verification task; the verification conclusion summary is added to briefly summarize the verification result, such as whether the communication protocol compatibility between devices is good, whether the state synchronization is reliable, and whether the exception handling is robust, etc. By generating the interoperation verification result report, the verification result can be presented in a clear and standardized way, which is convenient for subsequent viewing and analysis.

[0107] Step S155: store the interoperability verification result report to a verification result database, and add an associated label corresponding to the interoperability verification task to the interoperability verification result report, the associated label including a device interaction object identifier, an interaction protocol type identifier, and a verification target type identifier.

[0108] To facilitate the management and query of the interoperability verification result report, it is stored to the verification result database. At the same time, an associated label corresponding to the interoperability verification task is added to the report. The device interaction object identifier is used to identify the device participating in the verification, the interaction protocol type identifier is used to identify the communication protocol type used between the devices, and the verification target type identifier is used to identify the specific target of this verification. By adding the associated label, the verification result report can be filtered and queried according to different conditions, improving the utilization efficiency of data. For example, all verification results of a certain device can be queried according to the device interaction object identifier, or all verification results about abnormal handling robustness can be queried according to the verification target type identifier.

[0109] In the entire process, when data collection is involved, if private sensitive data is collected, a variety of privacy protection and anti-leakage technical means are adopted. For example, data encryption technology is adopted to encrypt the collected private sensitive data. In the data collection stage, the data is encrypted and stored and transmitted in the form of ciphertext. The encryption algorithm is selected according to the importance and security level of the data to ensure the security of the data in the entire life cycle. For example, for private sensitive data such as user identity information and transaction records involved in highway electromechanical equipment, a high-strength symmetric encryption algorithm is used to encrypt it, and only authorized devices and systems can perform decryption operations.

[0110] At the same time, an access control mechanism is set up to strictly manage the access to private sensitive data. Only authorized personnel and systems can access these data, and the access operations will be recorded 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, data administrators may have management permissions for all private sensitive data, but ordinary data analysts can only access part of the data after desensitization.

[0111] In the data transmission process, a secure transmission protocol such as SSL / TLS protocol is adopted to ensure the confidentiality and integrity of the data in the network transmission process. The SSL / TLS protocol prevents data from being stolen or tampered with during transmission through encryption and identity verification mechanisms. For example, when private sensitive data is transmitted between highway electromechanical equipment, a secure communication channel is established through the SSL / TLS protocol to ensure the security of the data during transmission.

[0112] In addition, the privacy-sensitive data is regularly backed up and the backup data is stored in a secure location. The backup data can be restored in case of data loss or damage, ensuring the availability of data. At the same time, the backup data is also encrypted to prevent the backup data from being leaked during storage. For example, the privacy-sensitive data of the highway electromechanical equipment is backed up to a data center in a remote place, and the backup data is encrypted and stored.

[0113] During data use, the principle of minimizing use is followed, and only necessary privacy-sensitive data is used for verification tasks. Before using the data, the data is desensitized to remove sensitive information in the data. For example, when performing interoperability verification of highway electromechanical equipment, if only the running state data of the equipment is needed, privacy-sensitive data such as user identity and transaction records will not be used. If part of the privacy-sensitive data must be used, it is desensitized, such as partially hiding the user's identity card number and only retaining the necessary identification information.

[0114] Figure 2 A schematic diagram of exemplary hardware and software components of the process engine-based interoperability verification task autonomous running system 100 that can implement the idea of the present application is shown. For example, the processor 120 can be used on the process engine-based interoperability verification task autonomous running system 100 and used to perform the functions in the present application.

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

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

[0117] For the convenience of description, only one processor is described in the process engine-based interoperability verification task autonomous running system 100. However, it should be noted that the process engine-based interoperability verification task autonomous running system 100 in the present application can also include multiple processors, and therefore the steps performed by one processor described in the present application can also be jointly performed or separately performed by multiple processors. For example, if the processor of the process engine-based interoperability verification task autonomous running system 100 performs steps A and B, it should be understood that steps A and B can also be jointly performed by two different processors or separately performed in one processor. For example, a first processor performs step A, a second processor performs step B, or the first processor and the second processor jointly perform steps A and B.

[0118] In addition, the embodiment of the present application also provides a readable storage medium, wherein computer executable instructions are preset, and when a processor executes the computer executable instructions, the process engine-based interoperability verification task autonomous running method is realized.

[0119] It should be noted that, in order to simplify the description of the present application and to help the understanding of one or more embodiments of the present application, in the foregoing description of the embodiments of the present application, various features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A process engine based autonomous running method of an interoperability verification task, characterized in that, The method comprises: Constructing a virtual-real combined simulation environment comprising field device operation data, laboratory scaled component state information and software simulation model, the virtual-real combined simulation environment being used to simulate actual operation scenarios of road electromechanical device interoperability mechanism; Generating an interoperability verification task according to a preset verification requirement parameter set, the interoperability verification task comprising device interaction objects, interaction protocol types and interaction trigger conditions that need to be verified; Calling a flow engine to analyze the interoperability verification task, and planning an execution flow of the interoperability verification task based on communication interface specifications and interaction protocol types of the device interaction objects, the execution flow comprising a task start node, an interaction execution node and a task termination node; Executing the interoperability verification task in the virtual-real combined simulation environment according to the execution flow, and collecting message transmission data, state response data and time synchronization data in real time during device interaction; Generating an interoperability verification result based on the message transmission data, state response data and time synchronization data, the interoperability verification result comprising interaction message integrity description, state response consistency record and time synchronization accuracy description. 2.The process engine based interoperability verification task autonomous running method according to claim 1, wherein, The method comprises: Obtaining historical operation log data of field devices, the historical operation log data comprising device communication message records, state change time stamps and abnormal event trigger records; Collecting current working state parameters of laboratory scaled components, the working state parameters comprising component input and output interface voltage values, signal transmission delay amounts and protocol conversion success rates; Loading a preconfigured software simulation model, the software simulation model comprising a communication protocol stack module, a state machine conversion rule module and an abnormality injection control module of road electromechanical devices; Performing data format uniform processing on the historical operation log data, current working state parameters and software simulation model, and generating a multi-source data set with space-time alignment characteristics; Based on the multi-source data set, constructing a three-layer simulation environment structure comprising a physical device layer, a simulation layer and a data mapping layer, the physical device layer being used to connect field devices and laboratory scaled components, the simulation layer being used to run the software simulation model, and the data mapping layer being used to realize state synchronization between the physical device layer and the simulation layer. 3.The process engine based interoperability verification task autonomous running method according to claim 1, wherein, The method comprises: Analyzing the preset verification requirement parameter set, and extracting a verification target type parameter, the verification target type parameter being used to indicate that communication protocol compatibility between devices, state synchronization reliability or abnormality processing robustness needs to be verified; According to the verification target type parameter, screening device interaction objects that need to participate in verification from a pre-defined device resource library, the device interaction objects comprising field device instances, laboratory scaled component instances and software simulation model instances; determining an interaction protocol type between the device interaction objects, the interaction protocol type including a basic communication protocol, a service data protocol, and an exception handling protocol; setting an interaction trigger condition based on the verification target type parameter and the interaction protocol type, the interaction trigger condition including a normal operation trigger condition, an exception injection trigger condition, and a boundary state trigger condition; encapsulating the device interaction objects, the interaction protocol type, and the interaction trigger condition into a structured task description file, the task description file including a task identification field, an object list field, a protocol specification field, and a trigger condition field. 4.The process engine based interoperability verification task autonomous running method according to claim 3, wherein, The setting of the interaction trigger condition based on the verification target type parameter and the interaction protocol type comprises: when the verification target type parameter indicates verification of communication protocol compatibility between devices, setting the normal operation trigger condition as the device interaction objects being in an initial ready state, the exception injection trigger condition as randomly inserting an error check code or missing fields in the message interaction process, and the boundary state trigger condition as the load rate of the device interaction objects reaching a preset load threshold; when the verification target type parameter indicates verification of state synchronization reliability, setting the normal operation trigger condition as the device interaction objects completing initialization synchronization, the exception injection trigger condition as interrupting the communication connection in the state change process, and the boundary state trigger condition as the state change frequency of the device interaction objects reaching a preset frequency threshold; when the verification target type parameter indicates verification of exception handling robustness, setting the normal operation trigger condition as the device interaction objects receiving a legal request message, the exception injection trigger condition as sending an illegal format message or a large data volume message to the device interaction objects, and the boundary state trigger condition as the cumulative number of exception events of the device interaction objects reaching a preset critical threshold; performing conflict detection on the trigger conditions corresponding to different verification target type parameters, so that mutually exclusive trigger conditions are not triggered at the same time point; setting a corresponding trigger action for each trigger condition, the trigger action including starting an exception injection program, adjusting the device load state, or recording interaction data in the boundary state. 5.The process engine based interoperability verification task autonomous running method according to claim 1, wherein, The calling of the flow engine to parse the interoperation verification task comprises: reading the task identification field, the object list field, the protocol specification field, and the trigger condition field in the task description file of the interoperation verification task to generate a task metadata set; obtaining the communication interface specification document of each device interaction object according to the object list field, the communication interface specification document including the protocol version supported by the interface, the message format definition, and the handshake process specification; determining the message interaction sequence between the device interaction objects based on the protocol specification field and the communication interface specification document, the message interaction sequence including a request message sending sequence, a response message receiving sequence, and an acknowledgement message feedback sequence; The condition judgment node is inserted into the message interaction sequence according to the normal operation trigger condition, the abnormal injection trigger condition and the boundary state trigger condition in the trigger condition field, and the condition judgment node is used for controlling the execution time of the abnormal injection operation and the boundary state switching operation; The task metadata set, the message interaction sequence and the condition judgment node are arranged into a flow node to generate a verification task execution flow including a task starting node, an interaction execution node and a task termination node, the task starting node is used for initializing the device interaction object state, the interaction execution node is used for executing the message interaction and the state verification operation, and the task termination node is used for closing the device interaction connection and saving the verification process data. 6.The process-engine-based interoperability verification task autonomous running method according to claim 5, wherein, The task metadata set, the message interaction sequence and the condition judgment node are arranged into a flow node to generate a verification task execution flow including a task starting node, an interaction execution node and a task termination node, and the method comprises the following steps of: The task starting node is set as a flow starting point, and a node execution action of sending an initialization instruction to the device interaction object and waiting for a response is set; The interaction execution node is connected after the task starting node, the interaction execution node includes a plurality of sub-nodes, each sub-node corresponds to a message interaction step in the message interaction sequence, and a sub-node execution action of sending a request message, listening to a response message and recording interaction data is set; The condition judgment node is embedded in each sub-node, and the condition judgment node performs an execution action of detecting whether the abnormal injection trigger condition or the boundary state trigger condition is met, if the trigger condition is met, a corresponding trigger action is performed and the abnormal processing sub-flow is jumped to, and if the trigger condition is not met, the next sub-node is continuously executed; The task termination node is connected after all the sub-nodes are executed, and a node execution action of closing the device interaction connection, saving the verification process data and generating a termination state report is set; An execution sequence constraint relationship is set for each node, so that the interaction execution node can be executed only after the task starting node is executed, and the task termination node can be executed only after all the sub-nodes of the interaction execution node are executed.

7. The process engine based interoperability verification task autonomous running method according to claim 1, wherein, The task starting node of the execution flow is triggered, and an initialization instruction is sent to all the device interaction objects, the initialization instruction includes a device address configuration parameter, a protocol version negotiation parameter and a timeout time setting parameter; The response result of the initialization instruction of the device interaction object is monitored, and when all the device interaction objects complete the initialization and return a success status code, the message interaction operation of the interaction execution node is triggered; In the message interaction operation, a request message is sent to the sender device interaction object according to the message interaction sequence, a response message returned by the receiver device interaction object is listened to, and a sending timestamp, message content of the request message and a receiving timestamp, message content of the response message are recorded as message transmission data. ​ In the message interaction process, the current running state value of the device interaction object is read, the expected state value defined in the demand parameter set is compared and verified, and the actual change process and the expected change process of the state value are recorded as state response data; The local clock time of the device interaction object is synchronously collected, the clock time difference between different device interaction objects is calculated, and the change trend and stability of the time difference value are recorded as time synchronization data; When the trigger condition of the task termination node is met, the message interaction operation is stopped and the device interaction connection is closed. 8.The process-engine-based interoperability verification task autonomous running method according to claim 7, wherein, The reading of the current running state value of the device interaction object in the message interaction process, the comparison and verification of the expected state value defined in the demand parameter set, and the recording of the actual change process and the expected change process of the state value as state response data, comprise: A state monitoring interface is configured for each device interaction object, and the state monitoring interface is used to read the running state register value of the device in real time; The expected state value defined in the verification demand parameter set is converted into the same data format and unit as the device running state register value; At each time point of message interaction, the sending state value of the sender device interaction object and the receiving state value of the receiver device interaction object are obtained through the state monitoring interface; According to the message type defined in the message interaction sequence, the expected sending state value and the expected receiving state value corresponding to the time point are determined; The time point, the actual sending state value, the actual receiving state value, the expected sending state value and the expected receiving state value are recorded to form a state value record entry; The state value record entries of consecutive time points are arranged in chronological order to generate state response data containing actual change process curve and expected change process curve of time series. 9.The process engine based interoperability verification task autonomous running method according to claim 1, wherein, The generation of the interoperation verification result based on the message transmission data, the state response data and the time synchronization data, comprises: The content comparison of the request message and the response message in the message transmission data is performed, the integrity of the message field, the matching of the data type and the correctness of the check code are checked, and the interactive message integrity description containing the missing field list, the type mismatch field list and the check failure field list is generated; The actual change process and the expected change process in the state response data are time axis aligned, the state value deviation amount of each time point is calculated, the number of time points and the duration of the deviation amount exceeding the allowed threshold are counted, and the state response consistency record containing the deviation time distribution table and the deviation amount change curve is generated; The time difference value change trend in the time synchronization data is analyzed, the average value, the maximum value and the minimum value of the time difference value are calculated, the stability of the time difference value in different message interaction stages is evaluated, and the time synchronization accuracy description containing the time difference statistical table and the stability evaluation level is generated; The interactive message integrity description, the state response consistency record and the time synchronization accuracy description are structured and integrated to generate the interoperation verification result report containing the verification task identification, the verification time range, the verification conclusion summary. The interoperability verification result report is stored into a verification result database, and an associated label corresponding to the interoperability verification task is added to the interoperability verification result report, the associated label including a device interaction object identifier, an interaction protocol type identifier, and a verification target type identifier.

10. A process engine based interoperability verification task autonomous running system, characterized in that, The application also provides a computer readable storage medium storing a computer program product, wherein the computer program product comprises a computer program, and the computer program is configured to perform the method of any one of claims 1-9 when the computer program is executed by a processor.

Images