Double-script engine simulation method and system for intelligent fusion terminal

Abstract

The invention discloses a dual-script engine simulation method and system for an intelligent fusion terminal, and relates to the technical field of dual-script engine simulation. According to the method, the intelligent fusion terminal is tested through virtual equipment templated configuration, multi-dimensional protocol intelligent perception, instruction differentiation processing and double-engine load balancing design by simulating the interactive response of the virtual equipment and various hardware equipment, so that a large number of real equipment is not needed, and the test environment and equipment cost are remarkably reduced; a shadow storage area is preferentially called through query, script verification is set, and data safety and accuracy are guaranteed; double-engine scenarized matching and dynamic load balancing are achieved, and the resource utilization rate and the system stability are improved; the expansion cost is reduced through unknown protocol self-learning and template management, and finally the efficient, flexible, safe and extensible simulation interaction target between the intelligent fusion terminal and the virtual device is achieved.

Description

Technical Field

[0001] This invention relates to the field of dual-script engine simulation technology, specifically to a dual-script engine simulation method and system for intelligent fusion terminals. Background Technology

[0002] With the deep integration of industrial automation and Internet of Things technologies, smart devices are widely used in smart grids, industrial control and other scenarios. These devices often use a variety of communication protocols for data interaction, such as the DL / T645-2007 and DL / T698.45 protocols in the power industry, as well as the general Modbus-RTU / TCP and other industrial bus protocols. When developing and testing smart fusion terminals, it is necessary to connect multiple terminal devices to verify the correctness and stability of their communication processing, data management and business logic. However, the traditional method of relying on physical real devices for testing faces severe challenges: (1) Equipment availability and scale bottleneck: The number of physical devices is limited and the types are incomplete, making it difficult to simulate the real load and performance in real scenarios, which seriously restricts the various application tests of smart fusion terminals. (2) Insufficient test scenario coverage: Real devices are difficult to flexibly and repeatedly simulate various abnormal working conditions and boundary conditions, such as communication interruption, data distortion, non-standard protocol implementation, etc., resulting in insufficient test cases and difficulty in exposing potential risks. (3) Complex configuration and deployment and low efficiency: The test environment setup depends on physical wiring and on-site equipment configuration. Changing the test scenario requires heavy physical reconstruction and parameter reset, which is cumbersome, time-consuming and labor-intensive, greatly reducing test efficiency. (4) High cost and difficult maintenance: Purchasing a large number of real devices covering all protocol types is very costly, and the devices are easily damaged during frequent testing, resulting in high maintenance costs and complex lifecycle management.

[0003] To overcome the above difficulties, virtual device simulation technology has emerged. However, the existing simulation solutions still have obvious shortcomings: (1) Most systems have limited functions and can only simulate a single or fixed number of communication protocols, lacking the ability to adaptively identify and be compatible with multiple protocols, especially unknown or variant protocols; (2) In terms of behavior simulation, they can often only respond to simple data query commands and cannot handle complex parameter setting commands and related business logic verification; (3) The data generation mechanism is rigid and cannot dynamically simulate the real behavior and state changes of the device through scripts; (4) At the same time, the system architecture lacks an effective resource scheduling mechanism, making it difficult to support the stable, efficient, and concurrent operation of a large number of virtual devices.

[0004] Therefore, there is an urgent need in this field for an intelligent virtual device simulation solution that can achieve multi-protocol adaptive perception and parsing, support complex instructions and dynamic scripted behavior simulation, and have high-performance concurrent processing capabilities, in order to solve the problems of existing testing solutions. Summary of the Invention

[0005] The purpose of this invention is to provide a dual-script engine simulation method and system for intelligent converged terminals to improve the above-mentioned technical problems.

[0006] To achieve the above-mentioned objectives, the embodiments of the present invention provide the following technical solutions:

[0007] A dual-script engine simulation method for intelligent converged terminals includes:

[0008] Create each virtual device and load the corresponding device template and script library;

[0009] Feature extraction is performed on the original messages of each virtual device to generate a multi-dimensional fused feature vector;

[0010] A protocol fingerprint database is constructed, and an adaptive matching algorithm is used to match it with multi-dimensional fused feature vectors. A protocol parser is selected to generate the corresponding standardized instruction information.

[0011] Based on the device address information of each virtual device and the standardized instruction information, the instruction type is determined by routing; the instruction type includes query instructions and setting instructions.

[0012] Based on each instruction type, the shadow storage area is invoked and verified. Combined with the load balancing algorithm, resources are allocated to the script execution nodes corresponding to each script engine, and the data item scripts are executed. Message response data is generated and fed back to the intelligent fusion terminal.

[0013] In the aforementioned scheme, this method constructs a closed-loop design of "virtual device creation - intelligent protocol perception - instruction differentiation processing - dynamic resource scheduling." By creating virtual devices and loading corresponding templates and script libraries, it can flexibly expand the scale of devices and quickly reconstruct test scenarios without relying on physical hardware, significantly reducing testing costs and configuration complexity. Simultaneously, the script library lays the foundation for dynamic behavior simulation. Through multi-dimensional fusion feature extraction and adaptive matching algorithms, combined with the construction of a protocol fingerprint database and confidence and confusion analysis, it achieves accurate identification of known protocols and secure handling and self-learning expansion of unknown protocols, completely solving the problem of multi-protocol compatibility. This approach addresses complex challenges. By differentiating query and setting commands through routing, and combining shadow storage area calls with device-level script verification, it ensures both the accuracy of complex command processing and data security while meeting business logic verification requirements, overcoming the limitation of traditional simulations that can only respond to simple query commands. Furthermore, the scenario-based adaptation of the dual script engines and the load balancing algorithm based on node hardware capabilities and script complexity enable efficient global scheduling of the resource pool, effectively supporting the stable concurrent operation of a large number of virtual devices and solving the problem of insufficient resource scheduling in existing solutions. Ultimately, it achieves the goal of efficient, flexible, secure, and scalable simulation interaction between intelligent converged terminals and virtual devices.

[0014] Furthermore, the generation of corresponding standardized instruction information includes:

[0015] Construct a protocol fingerprint database; the protocol fingerprint database includes Modbus feature model, DL / T645 feature model and DL / T698.45 feature model;

[0016] Calculate the weighted Euclidean distance between each multi-dimensional fused feature vector and each feature model in the protocol fingerprint database; calculate the confidence level based on each Euclidean distance;

[0017] Based on each confidence level, the multi-dimensional fused feature vectors are matched with each protocol parser to determine the protocol type; the protocol type is divided into normal protocol and unknown protocol.

[0018] Select the protocol parser required for the multi-dimensional fusion feature vector of the normal protocol type and parse it to generate the corresponding standardized instruction information;

[0019] The multi-dimensional fusion feature vector of the protocol type is analyzed to generate analysis results; the protocol fingerprint database is updated based on the analysis results.

[0020] In the above scheme, this method constructs a feature model library containing commonly used industrial protocols such as Modbus, DL / T645, and DL / T698.45. It combines multi-dimensional fusion feature vectors with weighted Euclidean distance calculation, confidence derivation, and protocol confusion analysis of each protocol model to accurately distinguish between normal and unknown protocols. For normal protocols, a dedicated parser is matched to parse the corresponding standardized instructions. At the same time, a special analysis is performed on unknown protocols and the protocol fingerprint library is updated to improve the accuracy of known protocol identification. Protocol confusion analysis further avoids the risk of misjudgment between similar protocols. The analysis of unknown protocols and the fingerprint library update mechanism realize the self-learning expansion of protocol support capabilities. It effectively solves the technical problems of existing simulation schemes, such as lack of multi-protocol adaptive identification capability, insufficient compatibility with unknown or variant protocols, and easy misjudgment of protocol identification due to confusion. Finally, it significantly improves the adaptability and adaptive parsing capability of multi-protocol scenarios, and provides a reliable protocol parsing foundation for subsequent complex instruction processing and dynamic simulation.

[0021] Furthermore, determining the protocol type includes:

[0022] Select the two protocol models with the highest confidence from the multi-dimensional fusion feature vectors and calculate the corresponding protocol confusion.

[0023] Calculate the type recognition accuracy based on historical protocol types; calculate the adaptive confidence threshold based on the type recognition accuracy, historical adaptive confidence threshold, and influence velocity coefficient.

[0024] Based on the adaptive confidence threshold, the protocol confusion corresponding to each multi-dimensional fused feature vector, and the two highest confidence levels, the corresponding protocol type is determined.

[0025] In the above scheme, this method can quantify the degree of distinction between similar protocols by calculating the confusion degree between the two protocol models with the highest confidence, effectively avoiding the risk of misjudgment caused by similar protocol features. The adaptive confidence threshold calculated based on historical recognition accuracy, historical threshold and speed coefficient can dynamically adjust the judgment criteria according to the system recognition performance, avoiding missed or false judgments when the recognition accuracy fluctuates due to a fixed threshold. By combining the adaptive threshold, protocol confusion degree and highest confidence for comprehensive decision-making, this method effectively solves the technical problem in the existing simulation scheme that protocol recognition is prone to misjudgment due to confusion of similar protocol features, and that the fixed confidence threshold cannot adapt to the dynamic changes in recognition accuracy, thus affecting the determination of protocol type.

[0026] Furthermore, the generated message response data includes:

[0027] Determine whether each instruction type is a query instruction;

[0028] If yes, then based on each query command, call the shadow storage area and determine if the setting value exists; if yes, then directly obtain the message response data; otherwise, load the corresponding data item script, allocate the resources of the script execution nodes corresponding to each script engine through the load balancing algorithm and execute the data item script, generate the corresponding message response data and feed it back to the intelligent fusion terminal.

[0029] Conversely, based on the various setting instructions, the corresponding virtual device executes the device-level script and performs verification, generating verification results; based on the verification results, the corresponding message response data is generated and fed back to the intelligent converged terminal.

[0030] In the above scheme, this method differentiates between query and setting commands. Query commands prioritize retrieving the set value directly from the shadow storage area, significantly improving response efficiency. When no set value is available, the data item script is dynamically loaded, and the dual script engine resources are scheduled for execution using a load balancing algorithm. This breaks the limitations of rigid data generation and achieves efficient resource utilization, supporting large-scale concurrency. Setting commands undergo legality verification by executing device-level scripts, which not only accurately handles complex business logic but also intercepts illegal parameters, preventing data distortion and ensuring interactive security. The entire process satisfies the intelligent fusion terminal's processing needs for different commands and achieves a balance between response efficiency, processing flexibility, and system stability through dynamic script loading. It solves the problems of existing simulation schemes, such as difficulty in handling complex parameter setting commands and related business logic verification, rigid data generation mechanisms, and low query response efficiency.

[0031] Furthermore, the processing procedure of the load balancing algorithm is as follows:

[0032] Construct a resource pool and set decision rules; the resource pool includes multiple script execution nodes;

[0033] Based on the hardware resources of each script execution node and the script data items, calculate the corresponding node baseline capability coefficient and script task complexity.

[0034] The number of unexecuted data item scripts in the waiting queue is counted, and the dynamic load factor is calculated by combining the node baseline capability coefficient and the script task complexity.

[0035] The dynamic load factor of each script execution node under different data item scripts in the computing resource pool;

[0036] Based on the dynamic load factors and decision rules, script execution nodes are assigned to each data item script and executed to generate corresponding message response data.

[0037] In the above process, this method provides a basic carrier for global resource scheduling by constructing a resource pool containing multiple script execution nodes. At the same time, it quantifies the differences in hardware capacity of each node by calculating the node baseline capability coefficient, quantifies the computational intensity of different scripts by calculating the script task complexity, and obtains a dynamic load factor by combining the number of unexecuted scripts in the waiting queue. This comprehensively and dynamically reflects the actual load status of each node. Finally, it allocates execution nodes according to the decision rule of minimizing the dynamic load factor, which can achieve precise matching between tasks and node capacity. This avoids the imbalance problem of high-performance nodes being idle and low-performance nodes being overloaded, and maximizes the utilization rate of resources. This effectively supports the concurrent operation of large-scale virtual devices, ensures the response speed of script execution and system stability, and significantly improves the overall performance of virtual device simulation.

[0038] A dual-script engine simulation system for intelligent converged terminals includes:

[0039] The virtual device management module is used to create virtual devices and load the corresponding device templates and script libraries.

[0040] The template management module supports batch definition and initialization of virtual devices;

[0041] The communication interface module is used to transmit raw messages from various virtual devices based on communication protocols.

[0042] The feature fusion module is used to extract features from the original messages of each virtual device and generate a multi-dimensional fused feature vector.

[0043] The protocol parsing module is used to build a protocol fingerprint library and match it with multi-dimensional fused feature vectors through an adaptive matching algorithm to select a protocol parser and generate corresponding standardized instruction information.

[0044] The instruction type determination module is used to determine the instruction type based on the device address information of each virtual device and the standardized instruction information through routing.

[0045] The response generation module is used to call the shadow storage area and perform verification based on each instruction type, combine the load balancing algorithm to allocate resources of the script execution nodes corresponding to each script engine and execute the data item scripts, generate message response data and feed it back to the intelligent fusion terminal.

[0046] Furthermore, the dual-script engine simulation system also includes a routing module, a shadow storage area, a script engine module, and a user interface module; wherein:

[0047] The routing module is used to forward the corresponding raw packets to the selected protocol parser for parsing based on the device address information and standardized command information of each virtual device.

[0048] The shadow storage area is used to provide independent data storage space for each virtual device and to save parameter values ​​modified by setting commands;

[0049] The script engine module is used to execute the data item scripts issued by the response generation module;

[0050] The user interface module provides a graphical user interface to display communication monitoring and system status.

[0051] Furthermore, the communication interface module supports RS-485 / RS-232 serial communication and TCP communication.

[0052] Furthermore, the script engine module employs a Lua script engine and a Python script engine.

[0053] In the above solution, this system supports batch creation and initialization of virtual devices through the coordinated operation of multiple modules such as virtual device management, template management, communication interface, and feature fusion. It is compatible with RS-485 / RS-232 serial ports and TCP communication, and can realize feature extraction and adaptive recognition of original messages of multiple protocols. By distinguishing query / set commands and combining shadow storage area verification and load balancing scheduling with dual script engines to execute scripts, it effectively solves the problems of limited testing scale, insufficient scene coverage, high cost of traditional physical devices, poor protocol compatibility, weak complex command processing, and inefficient resource scheduling of existing simulation solutions. It also realizes efficient, flexible, secure and scalable simulation interaction between virtual devices and intelligent fusion terminals, providing a stable and reliable virtual testing environment for intelligent fusion terminals, greatly improving testing efficiency and coverage, and reducing testing costs. Attached Figure Description

[0054] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a flowchart of the method involved in the embodiment.

[0056] Figure 2 This is a system architecture diagram related to the embodiment. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0058] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance, or suggesting any such actual relationship or order between these entities or operations. Additionally, the terms "connected," "linked," etc., can refer to a direct connection between elements or an indirect connection via other elements.

[0059] See Figure 1 This embodiment provides a dual-script engine simulation method for intelligent converged terminals, which enables efficient, flexible, and scalable simulation interaction between intelligent converged terminals and virtual devices.

[0060] like Figure 1 As shown, a dual-script engine simulation method for intelligent converged terminals includes:

[0061] S1. Create each virtual device and load the corresponding device template and script library;

[0062] S2. Extract features from the original messages of each virtual device and generate a multi-dimensional fused feature vector;

[0063] Specifically, the original messages of the virtual devices are those sent by the intelligent fusion terminal, and the feature extraction process is identical for each virtual device. Therefore, taking any single original message as an example, feature extraction is performed on the original message, calculating its frame length, specific offset values ​​at the frame header / tail, byte value frequency distribution, and information entropy. These are respectively used as frame length and distribution features, frame header / tail structural features, and byte-level statistical features (byte value frequency distribution and information entropy). Finally, timing and interaction features and message intervals are collected. The timing and interaction features are comprehensive features combining the transmission patterns (such as transmission intervals and frequencies) over time with the interaction logic of inter-device communication (such as request-response pairing and interaction sequences). These can be collected using existing feature extraction methods and will not be elaborated upon further.

[0064] In this embodiment, information entropy is selected as a byte-level statistical feature. A byte-level statistical algorithm is used to calculate the information entropy. The corresponding formula is:

[0065] ;

[0066] ;

[0067] in, Indicates the payload in the original message, Indicates the first The byte value of the payload. Let represent the logarithmic function with base 2. Represents byte value The frequency of occurrence in the load, This represents the summation function. Represents byte value The number of times it appears in the load, Indicates the length of the load.

[0068] The generated frame length and distribution features, frame header / tail structure features, byte-level statistical features, timing and interaction features, and message intervals are fused to generate a multi-dimensional fused feature vector.

[0069] S3. Construct a protocol fingerprint database and match it with multi-dimensional fused feature vectors through an adaptive matching algorithm, select a protocol parser, and generate corresponding standardized instruction information.

[0070] S3 includes:

[0071] S3-1. Construct a protocol fingerprint database; the protocol fingerprint database includes Modbus feature models, DL / T645 feature models, and DL / T698.45 feature models. The Modbus, DL / T645, and DL / T698.45 feature models are all aggregated from historical data to meet the requirements for determining feature / instruction types, etc. Integrating all this information constructs a corresponding feature model, essentially creating a smart feature database for the protocol.

[0072] S3-2. Calculate the weighted Euclidean distance between each multi-dimensional fused feature vector and each feature model in the protocol fingerprint database; calculate the confidence level based on each Euclidean distance.

[0073] Specifically, the multi-dimensional fused feature vectors are calculated by their weighted Euclidean distances to the feature models in the protocol fingerprint database. Taking any multi-dimensional fused feature vector and any feature model as an example, the formula for the weighted Euclidean distance is:

[0074] ;

[0075] Convert the weighted Euclidean distance into confidence scores. The formula is as follows:

[0076] ;

[0077] in, Indicates the first A multi-dimensional fused feature vector, The number of dimensions representing the multi-dimensional fused feature vector, in this embodiment... ; This represents the feature weights, specifically the feature weights of the frame header / frame tail structural features in this embodiment. The feature weight is set to 0.35 for byte-level statistical features. The value is set to 0.25, representing the feature weights of frame length and distribution characteristics. Setting it to 0.2, the feature weights for time series and interaction features are... Take 0.2; Indicates the first The protocol model of the first One characteristic.

[0078] S3-3. Based on each confidence level, match each multi-dimensional fused feature vector with each protocol parser to determine the protocol type; the protocol type is divided into normal protocol and unknown protocol.

[0079] S3-3 includes:

[0080] S3-3-1. Select the two protocol models with the highest confidence in each multi-dimensional fusion feature vector and calculate the corresponding protocol confusion.

[0081] Specifically, taking any multi-dimensional fused feature vector as an example, we select the two protocol models with the highest confidence and use them as... and And the corresponding confidence level is and .

[0082] Traditional methods select protocols based solely on a single confidence level, relying only on the highest confidence score. If the two highest confidence scores are very close, the corresponding protocol models may overlap or be similar in their feature spaces, potentially leading to misidentification of protocol types. Therefore, to address this problem, this embodiment introduces protocol confusion to capture uncertainties during the identification process. By calculating protocol confusion, matching quality can be evaluated more precisely, avoiding blind decisions in "high-confusion" scenarios and improving the accuracy and robustness of protocol identification.

[0083] Calculate the ratio of the two confidence levels and use it as the protocol confusion of the multi-dimensional fused feature vector. The corresponding formula is:

[0084] .

[0085] S3-3-2. Calculate the type recognition accuracy based on historical protocol types; calculate the adaptive confidence threshold based on the type recognition accuracy, historical adaptive confidence threshold, and influence velocity coefficient.

[0086] The formula corresponding to S3-3-2 is:

[0087] ;

[0088] in, Indicates based on the previous simulation The type identification accuracy is calculated from the obtained historical protocol types and the actual protocol types. Indicates the influence of the speed coefficient. Indicates the last simulation Historical adaptive confidence threshold Indicates the current simulation The adaptive confidence threshold. When initially calculating the adaptive confidence threshold, The initial adaptive confidence threshold is set according to the actual scenario. In this embodiment, the initial adaptive confidence threshold is 0.8.

[0089] Affecting the speed coefficient This controls the rate at which newly acquired accuracy data influences the current threshold. The smaller the value, the more sensitive the adaptive confidence threshold is to recent performance changes. (Influence speed coefficient) As a hyperparameter, its value ranges from [0,1]. In this embodiment, it affects the velocity coefficient. The value is 0.9.

[0090] S3-3-3. Based on the adaptive confidence threshold, the protocol confusion corresponding to each multi-dimensional fusion feature vector, and its two highest confidence levels, determine the corresponding protocol type.

[0091] Specifically, set the PCS obfuscation threshold. Taking any multi-dimensional fused feature vector as an example, when the two highest confidence levels and protocol confusion levels of this multi-dimensional fused feature vector satisfy the following conditions: and If so, it indicates that the protocol type of the corresponding original message is a normal protocol, and the process proceeds to S3-3-3 to determine the corresponding protocol parser for parsing and generate the corresponding standardized instruction information.

[0092] If the highest confidence and protocol confusion of the multi-dimensional fused feature vector satisfy the following conditions: and If so, it indicates that the protocol of the corresponding original message is severely obfuscated, the protocol type is an unknown protocol, and it is impossible to determine whether it belongs to a normal protocol, thus triggering a high obfuscation handling process, such as submitting the message to the administrator for manual review and labeling.

[0093] In other cases, it indicates that the protocol type of the corresponding original message is an unknown protocol, which cannot be parsed. Since the message structure and field definitions of unknown protocols are completely different from those of known protocols (normal protocols), forcibly parsing them with existing parsers will lead to data interpretation distortion. For example, random bytes may be misinterpreted as control commands, tampering with virtual device data items or shadow storage information, resulting in business decision-making errors. It may also trigger script execution anomalies, memory overflows, and other problems, damaging system stability. Furthermore, brute-force parsing can consume significant computing resources, reducing the efficiency of normal business responses. It may also allow malicious attack messages disguised as unknown protocols to take advantage, leading to security risks such as unauthorized operations. Moreover, data generated by incorrect parsing can persist and spread for a long time, posing continuous hidden dangers to subsequent business operations. Therefore, the original messages corresponding to unknown protocols will be sent to the unknown protocol analysis module, and a self-learning process will be initiated to collect samples for future expansion of protocol support capabilities.

[0094] S3-4. Select the protocol parser required for the multi-dimensional fusion feature vector of the normal protocol type and parse it to generate the corresponding standardized instruction information;

[0095] Specifically, after determining that the protocol type is a normal protocol, the routing module matches the corresponding dedicated protocol parser according to the protocol type. The parser completes the message legality verification, key field extraction and data format conversion according to the protocol standard, and uniformly converts the differentiated messages into standardized instructions containing core fields such as target device address, instruction type, and operation object, and finally transmits them to the virtual device management module for subsequent processing.

[0096] S3-5. Analyze the multi-dimensional fusion feature vector of the protocol type unknown to generate analysis results; update the protocol fingerprint database based on the analysis results.

[0097] Specifically, in this embodiment, the multi-dimensional fusion feature vector of an unknown protocol type is analyzed using an unknown protocol analysis module. The processing procedure of the unknown protocol analysis module is as follows:

[0098] The system receives raw messages from unknown protocols and compares the multi-dimensional fused feature vector corresponding to the raw message with all existing protocol feature models in the protocol fingerprint database to confirm no duplication and avoid storing known protocol variants repeatedly. Then, the raw message, multi-dimensional fused feature vector, and metadata such as collection time or communication scenario are merged and packaged for storage to form an unknown protocol sample library, providing high-quality training material for the self-learning process.

[0099] In the self-learning process, samples with high repetition rates and stable features in the sample library are automatically selected, triggering manual annotation to clarify the core features of the unknown protocol. Based on the annotated features, a protocol feature model corresponding to the unknown protocol is automatically generated and verified through confidence thresholds, such as simulating test message generation or verifying the model's recognition accuracy. The new protocol feature model that passes verification is retained. The new protocol feature model is added to the protocol fingerprint library and automatically associated with the template management module to generate a corresponding virtual device template (bound to the protocol type), and linked with the dual script engine to generate basic parsing scripts (such as data item extraction logic). After the new protocol model and configuration are deployed, when a message of this protocol is received subsequently, the message can be directly identified, and the corresponding parser can be called to complete the parsing, realizing the ability to support the expansion capability of the new protocol without manual development.

[0100] S4. Based on the device address information of each virtual device and the standardized instruction information, determine the instruction type through routing; the instruction type includes query instructions and setting instructions.

[0101] Specifically, based on the standard definition of the corresponding protocol, the key bytes (or fields) that specifically identify the operational intent are located from the parsed message. The location and meaning of the identifiers are fixed for different protocols. For example, if the protocol is Modbus-RTU, then the second byte of the message is the "function code," which is the core identifier of the instruction type; if the protocol is DL / T645, then the ninth byte of the message is the "control code," which identifies the instruction type.

[0102] Based on the built-in mapping rule base of identifier bytes to instruction types for each protocol (maintained by the protocol parser), the extracted key bytes are matched with the rule base:

[0103] If the identifier byte corresponds to an operation such as "read data" or "query status", it is mapped to a query command; if the identifier byte corresponds to an operation such as "operation parameters" or "write data", it is mapped to a set command.

[0104] By combining the validity of the virtual device configuration with the target virtual device associated with the command type, it verifies whether the device supports the command type, ensuring that the command type is compatible with the device configuration and avoiding invalid operations.

[0105] S5. Based on each instruction type, the shadow storage area is invoked and verified. Using a load balancing algorithm, resources are allocated to the script execution nodes corresponding to each script engine, and the data item scripts are executed. Message response data is generated and fed back to the intelligent fusion terminal. The script engines employ Lua and Python language languages.

[0106] S5 includes:

[0107] S5-1. Determine if each instruction type is a query instruction; if yes, proceed to S5-2; otherwise, proceed to S5-4.

[0108] S5-2. Based on each query command, call the shadow storage area and determine if the setting value exists; if it does, directly obtain the message response data; otherwise, load the corresponding data item script and proceed to S5-3.

[0109] Specifically, check the data items of the virtual devices corresponding to each query command to see if there are parameter values ​​saved in the shadow storage area through the "set command". If a setting value exists, it means that the parameter value has been manually set, and the value saved in the shadow storage area is returned directly; if "no setting value exists", it means that the parameter value has not been manually set and the data item script needs to be executed.

[0110] S5-3: Allocate resources to the script execution nodes corresponding to each script engine through a load balancing algorithm, execute the data item scripts, generate corresponding message response data, and feed it back to the intelligent fusion terminal.

[0111] In scenarios where multiple devices execute scripts simultaneously, a lack of a reasonable load balancing mechanism can lead to task imbalance: different scripts with varying computational intensities may be distributed evenly based on quantity, causing high-performance scripts to concentrate on a single node, overloading it while other nodes remain idle. Similarly, if nodes have different hardware capabilities (such as the number of CPU cores and hardware performance) but are not allocated accordingly, high-performance nodes may be idle while low-performance nodes are overwhelmed. Furthermore, the inability to dynamically perceive current load and future task pressure can easily lead to task backlog on nodes and high overall response latency.

[0112] The root cause of these problems is that traditional allocation methods (such as the least connections algorithm) only focus on the number of tasks, without quantifying differences in task complexity or hardware capabilities, and lack a comprehensive understanding of dynamic load (current and future), resulting in inaccurate resource allocation, low resource utilization, and impact on system stability and response speed.

[0113] Therefore, this embodiment introduces a load balancing algorithm based on hardware metrics and script task complexity. The processing procedure of the load balancing algorithm is the same for each script task (data item script). S5-3 includes:

[0114] S5-3-1. Construct a resource pool and set decision rules; the resource pool includes multiple script execution nodes, and according to the language configuration of the virtual device, an adapted script engine is deployed for each script execution node, and corresponding dedicated hardware resources (number of CPU cores and hardware indicators) are allocated; the hardware indicators include memory and I / O performance.

[0115] The decision rule is as follows: when a new data item script arrives, the load balancer always assigns the data item script to the script execution node with the smallest dynamic load factor.

[0116] S5-3-2. Based on the hardware resources of each script execution node and the script of each data item, calculate the corresponding node baseline capability coefficient and script task complexity.

[0117] Specifically, the node baseline capability coefficient is a baseline value derived from the number of CPU cores and hardware specifications, quantifying the hardware capacity of each script execution node. In this embodiment, a preset number of node threads is used as the initial value of the node baseline capability coefficient. For example, the resource pool has 10 preset nodes, and each node has 1 to 10 threads. A node with 10 threads naturally consumes more CPU cores and memory. During task execution, some of the node's threads may be occupied by running script tasks. At this time, the node baseline capability coefficient needs to be optimized based on the real-time occupancy status. Thus, the node baseline capability coefficient at this time is the difference between the preset number of node threads and the number of threads already occupied, dynamically reflecting the node's current remaining hardware resource capacity and avoiding node overload or resource idleness caused by allocating only the initial number of threads.

[0118] To assess script task complexity, a weighted value derived from quantitative analysis of factors such as bytecode size and common function complexity of each data item's script can be used as the script task complexity. In this embodiment, the open-source tool Lizard can be used to calculate the script task complexity. First, Lizard is integrated into the system, and parsing support for the target scripting language (Lua / Python) is configured. After loading the data item scripts, the system calls Lizard to scan and analyze the scripts, automatically extracting key indicators. For example, bytecode size can be indirectly quantified through the number of lines of script code, and the complexity of common functions can be characterized by indicators such as cyclomatic complexity and function nesting depth. Finally, each key indicator is weighted according to a preset weight to obtain a normalized weighted value, which represents the script task complexity.

[0119] S5-3-3: Count the number of data item scripts that have not yet been executed in the waiting queue, and calculate the dynamic load factor by combining the node baseline capability coefficient and the script task complexity.

[0120] Specifically, the number of unexecuted data item scripts in the waiting queue is counted and used as the node queue depth, which reflects the future pressure on the script execution node.

[0121] The dynamic load factor The corresponding formula is:

[0122] ;

[0123] in, Indicates the depth of the node queue. Represents the weight parameters. Indicates the first The baseline capability coefficient of each script execution node. This indicates the number of data item scripts currently being executed. This indicates the complexity of the script task.

[0124] S5-3-4, Dynamic load factor of each script execution node under different data item scripts in the computing resource pool;

[0125] S5-3-5. Based on each dynamic load factor and decision rule, allocate script execution nodes for each data item script and execute it through the allocated script execution nodes. That is, select the script execution node corresponding to the smallest dynamic load factor for each data item script to execute, generate the corresponding message response data and feed it back to the intelligent fusion terminal.

[0126] The load balancing algorithm introduced in this embodiment quantifies the hardware capacity differences of each execution node through a node baseline capability coefficient, quantifies the script computation intensity through task complexity parameters, and comprehensively evaluates the real-time load and future task pressure of nodes by combining dynamic load factors. This achieves precise matching between tasks and node capacity, avoiding "strong nodes idle and weak nodes overloaded." At the same time, it fully explores the hardware potential of each node based on global scheduling of the resource pool, maximizing the efficiency of shared resource utilization. After a task is assigned to the adapted node with the lowest load, it is quickly executed through the matching language script engine deployed on the node itself, reducing cross-node scheduling latency to improve script response speed. It can also dynamically sense load fluctuations to prevent node overload and crashes. It is compatible with Lua / Python multi-engine deployment to adapt to different business scenarios, enhancing the reliability and adaptability of system operation. It also supports adapting to various business needs by adjusting weight coefficients and hardware indicator dimensions. When adding nodes or script engines, they can be quickly included in the resource pool scheduling, reducing system expansion costs.

[0127] S5-4. Based on each setting command, execute the device-level script through the corresponding virtual device and perform verification to generate verification results; based on the verification results, generate corresponding message response data and feed it back to the intelligent fusion terminal.

[0128] Specifically, since the essence of setting instructions is to modify device parameters, it is necessary to load the corresponding device-level script to verify whether the setting value conforms to the device's legality rules (such as numerical range, format, etc.). At the same time, the script can adapt to the personalized constraints of different devices to ensure that only legal parameters are stored in the shadow storage area, avoiding invalid or incorrect settings.

[0129] The device-level script is executed by the script engine to obtain the corresponding initial message response data. Each initial message response data is then verified to determine its validity, i.e., data verification (numerical range, format, endianness, number system, etc.). If the verification result is valid, the initial message response data is considered correct; otherwise, it is considered an abnormal response.

[0130] Specifically, based on the standard definition of the corresponding protocol, the key bytes (or fields) that specifically identify the operational intent are located from the parsed message. The location and meaning of the identifiers are fixed for different protocols. For example, if the protocol is Modbus-RTU, then the second byte of the message is the "function code," which is the core identifier of the instruction type; if the protocol is DL / T645, then the ninth byte of the message is the "control code," which identifies the instruction type.

[0131] Based on the built-in mapping rule base of identifier bytes to instruction types for each protocol (maintained by the protocol parser), the extracted key bytes are matched with the rule base:

[0132] If the identifier byte corresponds to an operation such as "read data" or "query status", it is mapped to a query command; if the identifier byte corresponds to an operation such as "operation parameters" or "write data", it is mapped to a set command.

[0133] By combining the validity of the virtual device configuration with the target virtual device associated with the command type, it verifies whether the device supports the command type, ensuring that the command type is compatible with the device configuration and avoiding invalid operations.

[0134] S5. Based on each instruction type, the shadow storage area is invoked and verified. Using a load balancing algorithm, resources are allocated to the script execution nodes corresponding to each script engine, and the data item scripts are executed. Message response data is generated and fed back to the intelligent fusion terminal. The script engines employ Lua and Python language languages.

[0135] S5 includes:

[0136] S5-1. Determine if each instruction type is a query instruction; if yes, proceed to S5-2; otherwise, proceed to S5-4.

[0137] S5-2. Based on each query command, call the shadow storage area and determine if the setting value exists; if it does, directly obtain the message response data; otherwise, load the corresponding data item script and proceed to S5-3.

[0138] Specifically, check the data items of the virtual devices corresponding to each query command to see if there are parameter values ​​saved in the shadow storage area through the "set command". If a setting value exists, it means that the parameter value has been manually set, and the value saved in the shadow storage area is returned directly; if "no setting value exists", it means that the parameter value has not been manually set and the data item script needs to be executed.

[0139] S5-3: Allocate resources to the script execution nodes corresponding to each script engine through a load balancing algorithm, execute the data item scripts, generate corresponding message response data, and feed it back to the intelligent fusion terminal.

[0140] In scenarios where multiple devices execute scripts simultaneously, a lack of a reasonable load balancing mechanism can lead to task imbalance: different scripts with varying computational intensities may be distributed evenly based on quantity, causing high-performance scripts to concentrate on a single node, overloading it while other nodes remain idle. Similarly, if nodes have different hardware capabilities (such as the number of CPU cores and hardware performance) but are not allocated accordingly, high-performance nodes may be idle while low-performance nodes are overwhelmed. Furthermore, the inability to dynamically perceive current load and future task pressure can easily lead to task backlog on nodes and high overall response latency.

[0141] The root cause of these problems is that traditional allocation methods (such as the least connections algorithm) only focus on the number of tasks, without quantifying differences in task complexity or hardware capabilities, and lack a comprehensive understanding of dynamic load (current and future), resulting in inaccurate resource allocation, low resource utilization, and impact on system stability and response speed.

[0142] Therefore, this embodiment introduces a load balancing algorithm based on hardware metrics and script task complexity. The processing procedure of the load balancing algorithm is the same for each script task (data item script). S5-3 includes:

[0143] S5-3-1. Construct a resource pool and set decision rules; the resource pool includes multiple script execution nodes, and according to the language configuration of the virtual device, an adapted script engine is deployed for each script execution node, and corresponding dedicated hardware resources (number of CPU cores and hardware indicators) are allocated; the hardware indicators include memory and I / O performance.

[0144] The decision rule is as follows: when a new data item script arrives, the load balancer always assigns the data item script to the script execution node with the smallest dynamic load factor.

[0145] S5-3-2. Based on the hardware resources of each script execution node and the script of each data item, calculate the corresponding node baseline capability coefficient and script task complexity.

[0146] Specifically, the node baseline capability coefficient is a baseline value derived from the number of CPU cores and hardware specifications, quantifying the hardware capacity of each script execution node. In this embodiment, a preset number of node threads is used as the initial value of the node baseline capability coefficient. For example, the resource pool has 10 preset nodes, and each node has 1 to 10 threads. A node with 10 threads naturally consumes more CPU cores and memory. During task execution, some of the node's threads may be occupied by running script tasks. At this time, the node baseline capability coefficient needs to be optimized based on the real-time occupancy status. Thus, the node baseline capability coefficient at this time is the difference between the preset number of node threads and the number of threads already occupied, dynamically reflecting the node's current remaining hardware resource capacity and avoiding node overload or resource idleness caused by allocating only the initial number of threads.

[0147] To assess script task complexity, a weighted value derived from quantitative analysis of factors such as bytecode size and common function complexity of each data item's script can be used as the script task complexity. In this embodiment, the open-source tool Lizard can be used to calculate the script task complexity. First, Lizard is integrated into the system, and parsing support for the target scripting language (Lua / Python) is configured. After loading the data item scripts, the system calls Lizard to scan and analyze the scripts, automatically extracting key indicators. For example, bytecode size can be indirectly quantified through the number of lines of script code, and the complexity of common functions can be characterized by indicators such as cyclomatic complexity and function nesting depth. Finally, each key indicator is weighted according to a preset weight to obtain a normalized weighted value, which represents the script task complexity.

[0148] S5-3-3: Count the number of data item scripts that have not yet been executed in the waiting queue, and calculate the dynamic load factor by combining the node baseline capability coefficient and the script task complexity.

[0149] Specifically, the number of unexecuted data item scripts in the waiting queue is counted and used as the node queue depth, which reflects the future pressure on the script execution node.

[0150] The dynamic load factor The corresponding formula is:

[0151] ;

[0152] in, Indicates the depth of the node queue. Represents the weight parameters. Indicates the first The baseline capability coefficient of each script execution node. This indicates the number of data item scripts currently being executed. This indicates the complexity of the script task.

[0153] S5-3-4, Dynamic load factor of each script execution node under different data item scripts in the computing resource pool;

[0154] S5-3-5. Based on each dynamic load factor and decision rule, allocate script execution nodes for each data item script and execute it through the allocated script execution nodes. That is, select the script execution node corresponding to the smallest dynamic load factor for each data item script to execute, generate the corresponding message response data and feed it back to the intelligent fusion terminal.

[0155] The load balancing algorithm introduced in this embodiment quantifies the hardware capacity differences of each execution node through a node baseline capability coefficient, quantifies the script computation intensity through task complexity parameters, and comprehensively evaluates the real-time load and future task pressure of nodes by combining dynamic load factors. This achieves precise matching between tasks and node capacity, avoiding "strong nodes idle and weak nodes overloaded." At the same time, it fully explores the hardware potential of each node based on global scheduling of the resource pool, maximizing the efficiency of shared resource utilization. After a task is assigned to the adapted node with the lowest load, it is quickly executed through the matching language script engine deployed on the node itself, reducing cross-node scheduling latency to improve script response speed. It can also dynamically sense load fluctuations to prevent node overload and crashes. It is compatible with Lua / Python multi-engine deployment to adapt to different business scenarios, enhancing the reliability and adaptability of system operation. It also supports adapting to various business needs by adjusting weight coefficients and hardware indicator dimensions. When adding nodes or script engines, they can be quickly included in the resource pool scheduling, reducing system expansion costs.

[0156] S5-4. Based on each setting command, execute the device-level script through the corresponding virtual device and perform verification to generate verification results; based on the verification results, generate corresponding message response data and feed it back to the intelligent fusion terminal.

[0157] Specifically, since the essence of setting instructions is to modify device parameters, it is necessary to load the corresponding device-level script to verify whether the setting value conforms to the device's legality rules (such as numerical range, format, etc.). At the same time, the script can adapt to the personalized constraints of different devices to ensure that only legal parameters are stored in the shadow storage area, avoiding invalid or incorrect settings.

[0158] The device-level script is executed by the script engine to obtain the corresponding initial message response data. Each initial message response data is then verified to determine its validity, i.e., data verification (numerical range, format, endianness, number system, etc.). If the verification result is valid, the initial message response data is considered correct; otherwise, it is considered an abnormal response.

Claims

1. A dual-script engine simulation method for intelligent converged terminals, characterized in that, include: Create each virtual device and load the corresponding device template and script library; Feature extraction is performed on the original messages of each virtual device to generate a multi-dimensional fused feature vector; A protocol fingerprint database is constructed, and an adaptive matching algorithm is used to match it with multi-dimensional fused feature vectors. A protocol parser is selected to generate the corresponding standardized instruction information. Based on the device address information of each virtual device and the standardized instruction information, the instruction type is determined by routing; the instruction type includes query instructions and setting instructions. Based on each instruction type, the shadow storage area is invoked and verified. Combined with the load balancing algorithm, resources are allocated to the script execution nodes corresponding to each script engine, and the data item scripts are executed. Message response data is generated and fed back to the intelligent fusion terminal.

2. The dual-script engine simulation method for intelligent converged terminals according to claim 1, characterized in that, The generation of corresponding standardized instruction information includes: Construct a protocol fingerprint database; the protocol fingerprint database includes Modbus feature model, DL / T645 feature model and DL / T698.45 feature model; Calculate the weighted Euclidean distance between each multi-dimensional fused feature vector and each feature model in the protocol fingerprint database; calculate the confidence level based on each Euclidean distance; Based on each confidence level, the multi-dimensional fused feature vectors are matched with each protocol parser to determine the protocol type; the protocol type is divided into normal protocol and unknown protocol. Select the protocol parser required for the multi-dimensional fusion feature vector of the normal protocol type and parse it to generate the corresponding standardized instruction information; The multi-dimensional fusion feature vector of the protocol type is analyzed to generate analysis results; the protocol fingerprint database is updated based on the analysis results.

3. The dual-script engine simulation method for intelligent converged terminals according to claim 2, characterized in that, The determination of the protocol type includes: Select the two protocol models with the highest confidence from the multi-dimensional fusion feature vectors and calculate the corresponding protocol confusion. Calculate the type recognition accuracy based on historical protocol types; calculate the adaptive confidence threshold based on the type recognition accuracy, historical adaptive confidence threshold, and influence velocity coefficient. Based on the adaptive confidence threshold, the protocol confusion corresponding to each multi-dimensional fused feature vector, and the two highest confidence levels, the corresponding protocol type is determined.

4. The dual-script engine simulation method for intelligent converged terminals according to claim 1, characterized in that, The generated message response data includes: Determine whether each instruction type is a query instruction; If yes, then based on each query command, call the shadow storage area and determine if the setting value exists; if yes, then directly obtain the message response data; otherwise, load the corresponding data item script, allocate the resources of the script execution nodes corresponding to each script engine through the load balancing algorithm and execute the data item script, generate the corresponding message response data and feed it back to the intelligent fusion terminal. Conversely, based on the various setting instructions, the corresponding virtual device executes the device-level script and performs verification, generating verification results; based on the verification results, the corresponding message response data is generated and fed back to the intelligent converged terminal.

5. The dual-script engine simulation method for intelligent converged terminals according to claim 4, characterized in that, The processing procedure of the load balancing algorithm is as follows: Construct a resource pool and set decision rules; the resource pool includes multiple script execution nodes; Based on the hardware resources of each script execution node and the script data items, calculate the corresponding node baseline capability coefficient and script task complexity. The number of unexecuted data item scripts in the waiting queue is counted, and the dynamic load factor is calculated by combining the node baseline capability coefficient and the script task complexity. The dynamic load factor of each script execution node under different data item scripts in the computing resource pool; Based on the dynamic load factors and decision rules, script execution nodes are assigned to each data item script and executed to generate corresponding message response data.

6. A dual-script engine simulation system for intelligent converged terminals, used to implement the dual-script engine simulation method for intelligent converged terminals as described in any one of claims 1 to 5, characterized in that, include: The virtual device management module is used to create virtual devices and load the corresponding device templates and script libraries. The template management module supports batch definition and initialization of virtual devices; The communication interface module is used to transmit raw messages from various virtual devices based on communication protocols. The feature fusion module is used to extract features from the original messages of each virtual device and generate a multi-dimensional fused feature vector. The protocol parsing module is used to build a protocol fingerprint library and match it with multi-dimensional fused feature vectors through an adaptive matching algorithm to select a protocol parser and generate corresponding standardized instruction information. The instruction type determination module is used to determine the instruction type based on the device address information of each virtual device and the standardized instruction information through routing. The response generation module is used to call the shadow storage area and perform verification based on each instruction type, combine the load balancing algorithm to allocate resources of the script execution nodes corresponding to each script engine and execute the data item scripts, generate message response data and feed it back to the intelligent fusion terminal.

7. A dual-script engine simulation system for intelligent converged terminals according to claim 6, characterized in that, The dual-script engine simulation system also includes a routing module, a shadow storage area, a script engine module, and a user interface module; wherein: The routing module is used to forward the corresponding raw packets to the selected protocol parser for parsing based on the device address information and standardized command information of each virtual device. The shadow storage area is used to provide independent data storage space for each virtual device and to save parameter values ​​modified by setting commands; The script engine module is used to execute the data item scripts issued by the response generation module; The user interface module provides a graphical user interface to display communication monitoring and system status.

8. A dual-script engine simulation system for intelligent converged terminals according to claim 6, characterized in that, The communication interface module supports RS-485 / RS-232 serial communication and TCP communication.

9. A dual-script engine simulation system for intelligent converged terminals according to claim 7, characterized in that, The script engine module uses a Lua script engine and a Python script engine.

Images