A cross-protocol instruction adaptation and distribution method, device, equipment and storage medium

Abstract

Embodiments of the present application disclose a cross-protocol instruction adaptation and distribution method, device, equipment and storage medium, the method comprising: receiving a source protocol instruction stream, extracting four-dimensional features of target devices, and performing weighted fusion on the four-dimensional features to generate a context feature vector; inputting the context feature vector into an adaptation rule engine to generate an adaptation scheme; converting the source protocol instruction into a target protocol instruction according to the adaptation scheme; collecting current load statistics of each target device, determining instruction issuing time of each target device according to the current load statistics; and issuing the target protocol instruction to the target device at the instruction issuing time of each target device. Real-time sensing and adaptive adaptation of dynamic network environment and device state are realized, the accuracy of cross-protocol instruction conversion and device compatibility are significantly improved, and response delay is effectively reduced.

Description

Technical Field

[0001] This invention relates to the field of protocol adaptation technology, and in particular to a cross-protocol instruction adaptation and distribution method, a cross-protocol instruction adaptation and distribution device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of IoT technology, a large number of heterogeneous devices have been deployed in scenarios such as smart homes, industrial IoT, and smart cities. These devices use different communication protocols (such as Wi-Fi, Zigbee, MQTT, CoAP, HTTP, etc.), resulting in serious "language incompatibility" problems between devices, which greatly limits the system's interoperability. Existing technologies mainly convert between different protocols by pre-establishing a fixed mapping relationship from the source protocol to the target protocol, or by deploying dedicated gateway devices to uniformly convert different protocols.

[0003] However, existing solutions struggle to perceive real-time device status and dynamic network changes (such as packet loss rate, latency, and bandwidth fluctuations). This leads to issues such as low command adaptation accuracy, poor device compatibility, and high response latency when making protocol selections and parameter configurations in a dynamically changing IoT environment. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a cross-protocol instruction adaptation and distribution method, a cross-protocol instruction adaptation and distribution apparatus, an electronic device, and a computer-readable storage medium to overcome or at least partially solve the above problems.

[0005] To address the aforementioned problems, a first aspect of this invention provides a cross-protocol instruction adaptation and distribution method, the method comprising: The system receives a source protocol instruction stream, extracts four-dimensional features of the target device based on the source protocol instruction stream, and performs weighted fusion of the four-dimensional features to generate a context feature vector. The source protocol instruction stream contains multiple instructions pointing to different target devices. The four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features. The context feature vector is input into the adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; According to the adaptation scheme, the source protocol instructions are converted into the target protocol instructions; Collect the current load statistics of each target device, and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but unacknowledged instructions, the number of acknowledged instructions still waiting in the queue, and the number of instructions being executed. At the time when the instruction is issued to each target device, the target protocol instruction is sent to the target device.

[0006] According to a second aspect of the present invention, a cross-protocol instruction adaptation and distribution apparatus is provided, the apparatus comprising: The feature vector generation module is used to receive a source protocol instruction stream, extract four-dimensional features of the target device based on the source protocol instruction stream, and perform weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; An adaptation scheme generation module is used to input the context feature vector into an adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; The protocol instruction conversion module is used to convert the source protocol instruction into the target protocol instruction according to the adaptation scheme. The instruction issuance time determination module is used to collect the current load statistics of each target device and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but not yet confirmed instructions, the number of confirmed instructions still waiting in the queue, and the number of instructions being executed. The target instruction delivery module is used to deliver the target protocol instruction to the target device at the instruction delivery time of each target device.

[0007] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the cross-protocol instruction adaptation and distribution method as described in any of the preceding embodiments.

[0008] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, wherein when executed by a processor, the computer program implements the steps of the cross-protocol instruction adaptation and distribution method as described in any of the preceding embodiments.

[0009] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a cross-protocol instruction adaptation and distribution method, apparatus, device, and storage medium. The method includes: receiving a source protocol instruction stream; extracting four-dimensional features of a target device based on the source protocol instruction stream; and performing weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; inputting the context feature vector into an adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instructions into target protocol instructions; converting the source protocol instructions into target protocol instructions according to the adaptation scheme; collecting the current load statistics of each target device; determining the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but unconfirmed instructions, the number of confirmed and received instructions still waiting in the queue, and the number of instructions currently being executed; and issuing the target protocol instructions to the target devices at the instruction issuance time of each target device. By extracting the four-dimensional features of the target device (protocol type, device capabilities, network status, and historical execution data) in real time and performing dynamic weighted fusion, the adaptation rule engine can accurately generate protocol formats and transmission strategies based on the current context. At the same time, by combining multi-stage load statistics (issued but not confirmed, waiting in the queue, and executing), it determines the optimal time for issuing commands to each device. This enables real-time perception and adaptive adaptation to dynamic network environments and device status, significantly improving the accuracy of cross-protocol command conversion and device compatibility, and effectively reducing response latency. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the steps of a cross-protocol instruction adaptation and distribution method provided in an embodiment of the present invention; Figure 2 This is a flowchart of another cross-protocol instruction adaptation and distribution method provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating a cross-protocol instruction adaptation and distribution method provided in an embodiment of the present invention; Figure 4 This is a structural block diagram of a cross-protocol instruction adaptation and distribution device provided in an embodiment of the present invention. Detailed Implementation

[0011] To make the above-mentioned objects, features and advantages of the present invention more readily understood, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0012] Existing solutions typically pre-define a fixed mapping relationship, such as "all HTTP commands from the app are always converted to the MQTT protocol and sent to the device." During network congestion, MQTT may experience increased latency due to frequent retransmissions. In such cases, the lighter CoAP protocol might be more suitable, but fixed mappings cannot make this adjustment. When network quality is good, a more efficient protocol can be selected, but static rules cannot detect this change, thus missing optimization opportunities and causing unnecessary latency. Existing technologies struggle to detect device status, such as battery level and CPU load. When a device's battery is low, it should choose a more power-efficient communication method, but traditional gateways still mechanically execute the pre-define conversion rules. This can cause the device to drain its battery too quickly due to processing complex protocols, or even go offline, thus reducing overall compatibility and stability.

[0013] One of the core concepts of this invention is that by extracting the four-dimensional features (protocol type, device capabilities, network status, and historical execution data) of the target device in real time and performing dynamic weighted fusion, the adaptation rule engine can accurately generate protocol formats and transmission strategies based on the current context. At the same time, by combining multi-stage load statistics (issued but not confirmed, waiting in the queue, and executing), the optimal time for issuing instructions to each device is determined. This achieves real-time perception and adaptive adaptation to dynamic network environments and device status, significantly improving the accuracy of cross-protocol instruction conversion and device compatibility, and effectively reducing response latency.

[0014] Reference Figure 1 The diagram illustrates a flowchart of a cross-protocol instruction adaptation and distribution method provided by an embodiment of the present invention. The method specifically includes the following steps: Step 101: Receive the source protocol instruction stream, extract the four-dimensional features of the target device based on the source protocol instruction stream, and perform weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; This invention relates to a cross-protocol command adaptation and distribution system deployed in IoT scenarios. The system comprises five core functional modules that collaboratively complete the entire process from command reception to command distribution. Specifically, the context-aware module is deployed on edge nodes, close to the data source to reduce perception latency; the adaptation rule engine and feedback optimization module are deployed in the cloud, utilizing GPUs to accelerate model training and inference; and the command conversion module and load balancing module can dynamically select their deployment location (edge ​​or cloud) based on the network topology. The modules communicate asynchronously via RESTful APIs or message queues (such as Kafka), achieving decoupling between the edge and cloud.

[0015] The context-aware module on the edge node receives the source protocol instruction stream, extracts four-dimensional features, generates a context feature vector, and sends it to the adaptation rule engine in the cloud via Kafka. The adaptation rule engine performs inference based on a hybrid architecture of hierarchical attention network and differentiable rule decision tree, generates a structured adaptation scheme, and sends it to the instruction conversion module. After the instruction conversion module completes the protocol format conversion, the load balancing module dynamically determines the timing of the distribution based on the three-zone load statistics of each target device. After the distribution is completed, the feedback optimization module continuously monitors the execution results and continuously fine-tunes the parameters of the adaptation rule engine through incremental learning.

[0016] A source protocol command stream refers to a stream of command data sent from the sender that follows a specific source protocol format. The source protocol, relative to the target protocol after conversion, refers to the original communication protocol, such as an HTTP request from a mobile app, an MQTT message reported by a sensor, or a CoAP command sent from the cloud. A command stream is not a single, isolated command, but rather a continuously arriving data sequence that may contain multiple commands.

[0017] Four-dimensional features are four types of contextual information extracted from each source protocol instruction and its corresponding target device, current network environment, and historical records. These are protocol type features, target device capability features, network status features, and historical execution data features. Specifically, they include the protocol used for the current instruction (protocol type), the recipient, the recipient's status (device capability), the current network quality (network status), and the past communication results with this device (historical execution).

[0018] The protocol type feature describes the protocol information carried by the current command itself, including the multi-dimensional one-hot encoding of the source protocol type (identifying HTTP, MQTT, CoAP, etc.), the protocol version number (e.g., HTTP / 1.1, MQTT v3.1.1), and extended flags (e.g., whether QoS is supported, whether reserved messages are supported). This feature originates from the protocol header parsing of the current command stream, essentially stating "what language the current command is in." The target device capability feature describes the target device's configuration and current state, including static capabilities (CPU architecture, memory size, list of available protocols, supported cipher suites, maximum message fragment length) and dynamic capabilities (current remaining battery power, CPU load, available storage space). This feature originates from the device capability database (dynamic capabilities are updated every 30 seconds via heartbeats), indicating "who the command is sent to and what the recipient's state is." The network status feature describes the quality and stability of the current communication link, including round-trip time (RTT), packet loss rate, jitter, bandwidth estimation, and a network trend factor (calculated by measuring the slope of packet loss rate changes over the past three time windows to determine if the network is deteriorating). This feature originates from active probing (Ping / ICMP) and passive observation (TCP retransmission rate, RTCP reports), and describes "the current network conditions." Historical execution data features describe the target device's past cooperation, including weighted success rate and failure mode vector. The weighted success rate is calculated using an exponentially decaying time window, ensuring that recent execution results have a much greater impact on current decisions than long-term results, with a decay coefficient λ = 0.05 / second. The failure mode vector statistically analyzes the distribution of causes for the 10 most recent failures (timeout, protocol rejection, parameter error). This feature originates from the historical execution database and describes "how effective communication with this device was in the past."

[0019] The context feature vector is a 128-dimensional unified numerical vector generated by dynamically weighting and fusing four-dimensional features (protocol type features, target device capability features, network status features, and historical execution data features). The four-dimensional features are "raw signals" collected from various angles, with different formats, dimensions, and importance. The context feature vector transforms these raw signals into a unified format, scale, and dynamically adjusted dimension importance based on the current scenario—a "comprehensive feature representation"—serving as standardized input for the rule engine to make decisions.

[0020] In this embodiment of the invention, a source protocol instruction stream is first received from a sender (such as a mobile app, cloud platform, etc.). This instruction stream contains multiple instructions pointing to different target devices (e.g., instructions controlling multiple devices such as air conditioners, lights, and sensors). For each instruction, four-dimensional context features are extracted: protocol type features (what the source protocol is, version number, whether it supports QoS, etc.), target device capability features (target device's CPU / memory, list of supported protocols, current battery level and load, etc.), network status features (current RTT, packet loss rate, jitter, bandwidth, and whether the network is deteriorating), and historical execution data features (past success rate and failure reason distribution of the device). After the four-dimensional feature extraction is completed, through a dynamic weighted fusion mechanism, each dimension feature is first mapped to a sub-vector of a unified dimension by an encoder. Then, a multilayer perceptron automatically calculates the importance weight of each dimension based on the current signal strength of each dimension (e.g., when network fluctuations are severe or historical variance is large). Finally, the weighted sub-vectors are concatenated and dimensionality reduced to generate a 128-dimensional context feature vector.

[0021] Step 102: Input the context feature vector into the adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; The adaptation rule engine receives context feature vectors as input, and outputs a structured adaptation scheme after internal reasoning. It adopts a hybrid architecture of hierarchical attention network and differentiable rule decision tree.

[0022] In this embodiment of the invention, the generated context feature vector is input into the adaptation rule engine. The engine performs intelligent reasoning based on the current complete context information (protocol type, device capabilities, network status, historical execution) and outputs a structured adaptation scheme. The adaptation scheme consists of specific conversion parameters and transmission strategy parameters, used to instruct the subsequent instruction conversion module how to convert the source protocol instruction into the target protocol instruction. This includes specifying the target protocol type (e.g., MQTT or CoAP), the QoS level, how the payload field is mapped, the authentication method used, the number of retransmissions, and the timeout. For example, for an HTTP request from a mobile app, the adaptation scheme instructs that it be converted to the MQTT protocol, with QoS=1, the payload mapped as "action=turnOn&temp=26", token authentication used, a timeout of 2000ms, and one retransmission.

[0023] The adaptation rule engine employs a hybrid architecture of hierarchical attention networks and differentiable rule decision trees. First, the engine deeply encodes the context feature vector through a hierarchical attention network, capturing the correlation between sub-features within each dimension (e.g., the coupling between latency and packet loss in network states). Then, using protocol type as an anchor, it focuses across dimensions on the device capabilities and network information most relevant to the protocol. Finally, a 64-dimensional policy latent vector is output through a gating unit, condensing the semantic information most relevant to the adaptation decision in the current scenario. Next, the engine inputs the policy latent vector into the rule adapter of the differentiable rule decision tree, dynamically activating relevant rules from a predefined rule template library (e.g., "If the device supports MQTT and the packet loss rate is <1%, prioritize using MQTT, QoS=1"). It outputs the activation weight and continuous parameter offsets for each rule, generating multiple candidate rule suggestions. Finally, the engine resolves contradictions between candidate rules through a four-layer conflict resolution mechanism (parameter type-based flow aggregation, security-first resolution, context-based tie-breaker, and cross-parameter consistency verification), outputting a conflict-free, security-constrained, and logically consistent final adaptation scheme. Step 103: According to the adaptation scheme, convert the source protocol instruction into the target protocol instruction; In this embodiment of the invention, the source protocol instructions are converted from their original format to an instruction format that conforms to the target protocol specification, according to the specific instructions of each parameter in the generated adaptation scheme, that is, the "translation" between the protocols is performed. The system receives a structured adaptation scheme from the adaptation rules engine (containing parameters such as target protocol type, QoS level, payload mapping rules, authentication method, retransmission count, and timeout), and performs the conversion operation based on these parameters: First, it parses the source protocol request URL into the target protocol's topic or path format (e.g., converting the HTTP ` / api / device / AC001 / command` to the MQTT topic `device / AC001 / cmd`); then, it performs field mapping and format conversion on the key-value pairs in the source protocol payload according to the `payload_mapping_rules` in the adaptation scheme (e.g., converting the HTTP JSON format `{"action":"turnOn","temperature":26}` to the MQTT payload key-value pair string `action=turnOn&temp=26`); next, it configures the target protocol's transmission behavior according to the QoS level, retransmission count, and timeout parameters set in the adaptation scheme; finally, it sends out the converted command through the corresponding protocol client.

[0024] For cases where source protocol fields do not have direct mappings in the target protocol during the conversion process, traffic is split according to the semantic criticality of the fields: security-critical fields (such as auth_token) are forcibly retained and placed in the authentication segment of the target protocol; if they cannot be retained, the conversion is blocked and an error is returned; control-critical fields (such as timeout) are preferentially expressed using the target protocol's native mechanism (such as MQTT's keepAlive); if this is not possible, they are placed in the payload's extension segment (X-prefix) for literal transmission; semantic content fields (action, temperature, etc.) are forcibly mapped according to the payload mapping rules and cannot be discarded; pure metadata fields (such as Correlation-ID) can be discarded but written to the audit log. When the converted target protocol payload exceeds the length limit, payload segments are trimmed sequentially according to a preset priority: starting with the tracking information segment, followed by the authentication information segment, then the control parameter segment, and finally the semantic mapping segment, until the payload length meets the limit. For bidirectional communication protocols (such as WebSocket), the conversion module also needs to establish and maintain a long-connection session state and support asynchronous responses to commands.

[0025] Step 104: Collect the current load statistics of each target device, and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but unconfirmed instructions, the number of confirmed instructions still waiting in the queue, and the number of instructions being executed. Load statistics are multi-dimensional quantitative indicators collected to assess the current workload of each target device. Load statistics are not a single value, but rather a measure of the actual stress state of the device, collected at three stages of the instruction lifecycle: the number of issued but unacknowledged instructions, the number of acknowledged instructions waiting in the queue, and the number of instructions currently being executed.

[0026] The number of sent but unacknowledged instructions refers to the number of instructions that have been converted and sent to the target device but for which an acknowledgment message (ACK) has not yet been received. These instructions consume network connection resources and retransmission timers at the sending end, reflecting the pressure on the protocol layer. A high value indicates potential network congestion or insufficient device receiving capacity. This statistic is maintained locally in real-time by the instruction conversion module, incrementing a counter by 1 for each sent instruction and decrementing it by 1 for each received acknowledgment or timeout notification. The number of acknowledged but still queued instructions refers to the number of instructions that the target device has acknowledged receiving but has not yet started executing due to a full execution queue or limited processing capacity. These instructions occupy the device's memory queue space, reflecting queuing pressure on the device. When this value approaches the device's queue capacity limit, newly sent instructions may be rejected. This statistic is reported by the target device through the `queue_len` field in its heartbeat message every 30 seconds. The number of instructions currently executing refers to the number of instructions that the target device is currently actually executing (consuming CPU or hardware resources). This reflects the device's real-time processing pressure. The execution time of an air conditioning control command is typically around 50 milliseconds, with minimal fluctuations in the number of commands. This statistic is also reported by the target device via the exec_count field in its heartbeat message every 30 seconds.

[0027] In this embodiment of the invention, the number of issued but unacknowledged instructions is maintained locally in real time by the instruction conversion module (incremented by 1 upon issuance, decremented by 1 upon receipt of acknowledgment or timeout), representing the protocol layer pressure and reflecting network transmission and the receiving capacity of the other party; the number of acknowledged received instructions still waiting in the queue and the number of instructions being executed are both reported by the device every 30 seconds via heartbeat messages, representing the device's memory queue pressure and CPU real-time processing pressure, respectively. The three counts are weighted and summed according to preset weights (0.4, 0.35, 0.25), and divided by the device's maximum equivalent processing capacity to obtain the equivalent load rate of each device.

[0028] Based on the equivalent load rate, when the equivalent load rate of the target device is less than or equal to a preset load rate threshold (e.g., 80%) and the current latency is less than or equal to a preset latency threshold (e.g., 200ms), the device is marked as an available device, the command issuance time is set to the current time, and the command is issued immediately. When the equivalent load rate exceeds 80% or the latency exceeds 200ms, the device is marked as an unavailable device, and the command issuance time is postponed until the first available time after the device's load rate and latency have both recovered below the threshold. During this period, newly arriving commands will not be sent to the device. For the case of consecutive missing heartbeat messages, a three-level progressive fallback strategy is also set: when one heartbeat cycle (30 seconds) is missing, the queue and execution counts are multiplied by a decay factor of 0.8 using the previous value; when two cycles (60 seconds) are missing, they are multiplied by 0.5; when three cycles (90 seconds) are missing, a health check is triggered, the device's weight is reduced to 0, and it is removed from the candidate list. The effect of this step is that, through three-zone refined load perception and dynamic timing control, it effectively avoids sending instructions to overloaded or poorly networked devices, prevents device queue overflow and instruction timeout failures, and significantly improves the overall throughput and instruction execution success rate of the system.

[0029] Step 105: At the time when the instruction is issued by each target device, the target protocol instruction is sent to the target device.

[0030] In this embodiment of the invention, at the designated instruction issuance time for each target protocol instruction, the target protocol instruction is actually issued to the corresponding target device. The target protocol instruction, which has undergone protocol conversion, load balancing assessment, and issuance timing decision, is sent to the communication endpoint of the target device through the corresponding protocol client (such as MQTT client, CoAP client, HTTP client, etc.), so that the instruction truly enters the execution phase.

[0031] In practice, a queue of instructions to be sent is maintained. Each instruction in the queue is sorted and scheduled according to a predetermined sending time. Instructions with a sending time of "current moment" enter the immediate sending channel, while instructions with delayed sending times remain in the queue awaiting their turn. Secondly, during sending, a secure session is established with the target device based on the authentication method (Token or X.509 certificate) specified in the adaptation scheme, or an existing long connection is reused. Then, the target protocol instruction is sent to the target device through the selected physical channel. For the MQTT protocol, sending manifests as publishing a PUBLISH message to a specific topic; for the CoAP protocol, it manifests as sending a CON or NON request; for the HTTP protocol, it manifests as sending a POST or PUT request. After sending, the number of sent but unconfirmed instructions (Zone 1) is incremented by 1, and a timeout timer is started, waiting for confirmation messages or execution results from the target device.

[0032] Reference Figure 2 The diagram illustrates a flowchart of another cross-protocol instruction adaptation and distribution method provided by an embodiment of the present invention. The method specifically includes the following steps: Step 201: Receive the source protocol instruction stream, extract the four-dimensional features of the target device based on the source protocol instruction stream, and perform weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; In this embodiment of the invention, a source protocol instruction stream is received from a sender (such as a mobile app, cloud platform, etc.). This instruction stream contains multiple instructions pointing to different target devices (e.g., instructions controlling multiple devices such as air conditioners, lights, and sensors simultaneously). For each instruction, four-dimensional context features are extracted: protocol type features, target device capability features, network status features, and historical execution data features. After the four-dimensional feature extraction is completed, a dynamic weighted fusion mechanism is used. Each dimension feature is first mapped to a sub-vector of a unified dimension by an encoder. Then, a multilayer perceptron automatically calculates the importance weight of each dimension based on the current signal strength of each dimension. Finally, the weighted sub-vectors are concatenated and dimensionality reduced to generate a 128-dimensional context feature vector.

[0033] In some embodiments, the protocol type feature includes at least one of the following: multidimensional one-hot encoding of the protocol type, normalized value of protocol version number, and extended flag bit; the target device capability feature includes static capabilities and dynamic capabilities, wherein the static capabilities include at least one of CPU architecture, memory size, list of available protocols, supported cipher suites, and maximum message fragment length, and the dynamic capabilities include at least one of current remaining battery power, CPU load, and available storage space; the network status feature includes at least one of round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor; the historical execution data feature includes weighted success rate and failure mode vector, wherein the failure mode vector includes at least one of timeout, protocol rejection, and parameter error; step 201 may include the following sub-steps: Sub-step S11: Perform protocol fingerprinting on the source protocol instruction stream to determine the source protocol type, generate the multi-dimensional one-hot encoding based on the source protocol type, parse the normalized value of the protocol version number from the protocol header of the source protocol instruction stream, and parse the extended flag bit from the protocol header of the source protocol instruction stream; In some embodiments, the protocol fingerprinting includes parallel execution of port number identification, first byte feature identification, and finite state machine deep parsing; step S11 may include the following sub-steps: Sub-step S111 involves performing port number identification, first byte feature identification, and finite state machine deep parsing on the source protocol instruction stream in parallel, respectively obtaining the port number identification result and corresponding port confidence, the first byte feature identification result and corresponding first byte confidence, and the finite state machine deep parsing result and corresponding structure matching confidence. Sub-step S112: If the result of the finite state machine deep parsing is to complete the full syntax structure verification of a certain protocol, then the protocol type identified by the finite state machine is used as the protocol type of the source protocol instruction stream. In sub-step S113, if the finite state machine deep parsing result is that the complete syntax structure verification cannot be completed, the port number identification result and the first byte feature identification result are used as candidate protocols. The port confidence, the first byte confidence and the structure matching confidence are multiplied by their respective preset weights and then summed to obtain the weighted confidence of each candidate protocol. The candidate protocol with the highest weighted confidence is taken as the protocol type of the source protocol instruction stream.

[0034] In this embodiment of the invention, in an IoT environment, different devices may use different protocols such as HTTP, MQTT, CoAP, and WebSocket. Furthermore, non-standard protocols may run on the same port (e.g., HTTP on port 1883), and the same protocol may appear on non-standard ports. Relying solely on a single identification signal can easily lead to misjudgment. Port number identification assigns a protocol label and confidence level based on the target port number of the message (e.g., 80 / 443 for HTTP, 1883 for MQTT, and 5683 for CoAP). Its advantage is the fastest speed and zero overhead, but port numbers can be arbitrarily reused, resulting in the lowest reliability. First byte feature identification assigns a protocol label and confidence level based on a fixed pattern of the message's starting byte (e.g., the first byte `0x10` of HTTP's `GET / POST`, the first byte of MQTT's `CONNECT` message, and the fixed version field `0x01` of CoAP messages). Its distinguishing power is better than port number identification, but there is still a possibility of overlapping first byte patterns for different protocols. Finite state machine (FSM) deep parsing performs field-by-field structural verification of messages according to the standard syntax specifications of each protocol. For example, it verifies the completeness of the fixed header, variable header, and payload of an MQTT message, and the completeness of the request line, header, and entity of an HTTP message. If the FSM completes the full syntax structure verification of a protocol, it means that the message's syntax structure fully conforms to the protocol specification; this is structural-level deterministic evidence. If the FSM can only complete partial verification, it outputs a structure matching confidence score between 0 and 1, reflecting the degree of structural completeness of the verified portion.

[0035] When a finite state machine (FSM) completes the full syntactic structure verification of a protocol (e.g., a complete MQTT frame is parsed successfully, or an HTTP request line, header, and entity are perfectly matched), the protocol type identified by the FSM is used as the final protocol type, and the port number and first byte identification results are no longer considered. The FSM verifies the syntactic structural integrity of the protocol; its essence is structural-level validation. A complete and valid protocol frame structure can only be generated by real communication conforming to the protocol specification. Port numbers can be arbitrarily configured and reused, and first byte features may overlap by chance, but a complete and valid protocol frame structure cannot be forged.

[0036] When the finite state machine fails to complete the full syntax structure verification (e.g., encountering an unfamiliar field sequence halfway through parsing, only verifying that the first few fields of the message conform to a certain protocol specification), it enters the confidence-weighted fusion mode. At this point, the port number identification result and the first byte feature identification result serve as candidate protocols, and the protocol tags partially matched by the finite state machine are also considered candidates. The confidence scores of the three (port confidence score, first byte confidence score, and structure matching confidence score) are multiplied by their respective preset weights and then summed. The weight allocation reflects the inherent reliability of each identification signal: the port number is most easily reused and forged, so it has the lowest weight (0.2); the first byte has some discriminative power but may overlap, so its weight is in the middle (0.3); the structural partial matching of the finite state machine is still better than pure heuristic identification, so its weight is the highest (0.5). The candidate protocol with the highest weighted confidence score is selected as the final protocol type. The protocol fingerprinting mechanism achieves high reliability in determining the source protocol type through a three-layer hierarchical adjudication process, ensuring the accuracy of the protocol type dimension in subsequent four-dimensional feature extraction.

[0037] Sub-step S12: Query the device capability database according to the target device identifier in the source protocol instruction stream, read the static and dynamic capabilities of the target device, and obtain the capability characteristics of the target device based on the static and dynamic capabilities; Sub-step S13: Based on the target device identifier or target device address in the source protocol instruction stream, send a probe message to the target device to obtain the round-trip time, listen to the target device's transport layer retransmission event and communication quality feedback report to obtain the packet loss rate and jitter, use a sliding window message pair algorithm to obtain bandwidth estimation, and obtain the slope of the packet loss rate change in the past time window to determine the network trend factor. Sub-step S14: Based on the target device identifier in the source protocol instruction stream, query the historical execution database, read the historical execution records of the target device within a preset time range, determine the weighted success rate based on the historical execution records using an exponential decay time window, statistically analyze the distribution of reasons for the most recent preset number of failures, and generate a failure mode vector.

[0038] In this embodiment of the invention, the source protocol instruction stream is first subjected to protocol fingerprinting. Three identification channels—port number identification, first byte feature identification, and finite state machine deep parsing—are executed in parallel to determine the source protocol type (e.g., HTTP, MQTT, CoAP, etc.). If the finite state machine completes the full syntax structure verification of a protocol, its identification result is used; if only a partial match is achieved, the identification results and confidence scores of the three channels are weighted and fused, and the protocol tag with the highest confidence score is taken as the final protocol type. After determining the source protocol type, a multi-dimensional one-hot encoding is generated based on this protocol type (the dimension is fixed at 16, covering common protocols, with corresponding protocol positions set to 1 and the rest set to 0). Simultaneously, the protocol version number (e.g., HTTP / 1.1, MQTT v3.1.1) is parsed from the protocol header of the source protocol instruction stream and normalized, and extended flag bits (e.g., whether QoS is supported, whether reserved messages are supported) are parsed. The essence of protocol type feature extraction is to answer "what protocol format is used to send the current instruction?"

[0039] Based on the target device identifier (e.g., `deviceId:AC001`) carried in the source protocol command stream, the device capability database is queried to read the static and dynamic capabilities of the target device. Static capabilities refer to the device's inherent hardware and protocol stack configuration, including CPU architecture type, memory size, list of available protocols (including versions), supported encryption suites, and maximum message fragment length. This information is typically entered during the device's initial registration or obtained through the protocol's native discovery mechanism. Dynamic capabilities refer to the device's current real-time operating status, including remaining battery power, CPU load, and available storage space. This information is continuously updated through the device's heartbeat reporting every 30 seconds. In terms of encoding, discrete capabilities (list of available protocols, supported encryption suites) use multi-hot encoding, with each support bit marked as 1; continuous capabilities (memory size, battery power, CPU load, storage space) use binning normalization. For example, battery power is divided into three levels: 0~20%, 20%~50%, and 50%~100%, mapped to 0.2, 0.5, and 1.0 respectively. For newly connected unknown devices, the records in the device capability database are gradually improved through implicit inference from protocol fingerprinting, native protocol discovery and detection, confidence labeling capability recording, and progressive behavior verification.

[0040] Based on the target device identifier or address, the system first actively probes to obtain the Round-Trip Time (RTT), sending a lightweight Ping / ICMP timestamp request to the target device every 5 seconds and calculating the smoothed average as the current RTT estimate. Simultaneously, it passively monitors the target device's TCP retransmission rate and RTCP reports to obtain packet loss rate and jitter metrics. Bandwidth estimation uses a sliding window packet pair algorithm, updating the bandwidth estimate every 10 seconds. Furthermore, a network trend factor is introduced, calculating the slope of packet loss rate changes over the past three time windows (2 seconds each). If the slope is greater than 0.2, a "network degradation" state is marked, and this state is added as a binary feature to the network state feature vector. The network trend factor enables the system to have predictive awareness, reacting not only when packet loss becomes severe enough to affect communication, but also identifying and marking degradation states early in the trend of increasing packet loss rates. This allows subsequent adaptation decisions to proactively select more robust protocols and parameters, rather than reacting passively.

[0041] The historical execution database is queried based on the target device identifier, retrieving the historical execution records of the target device over the past 24 hours, arranged in reverse chronological order. When calculating the weighted success rate, an exponentially decaying time window is used. Essentially, this means that more recent execution results have a greater impact on the current decision, while more distant results have a smaller impact. Specifically, each historical record is assigned a weight that decays over time: e^(-λ×(t_now-t_i)). The decay coefficient λ = 0.05 / second means that records approximately 13.9 seconds ago have a weight that decays to approximately 50%, records approximately 46 seconds ago have a weight that decays to approximately 10%, and records approximately 2 minutes ago have a weight that decays to less than 1%. Therefore, this weighted success rate reflects a "recent trend" rather than a "historical average." If the device has a high overall success rate over the past 24 hours but experiences multiple consecutive failures within the last minute, the weighted success rate will drop rapidly. This will be detected promptly and a conservative adaptation strategy (such as increasing the number of retransmissions or extending the timeout period) will be triggered to avoid consecutive failures due to relying on optimistic historical estimates. If a standard mean is used, a large number of recent failure signals would be overwhelmed by the excellent performance of the past 23 hours, leading to system response delays. Simultaneously, by statistically analyzing the distribution of causes for the last 10 failures, a 3-dimensional failure mode vector is generated (timeout, protocol rejection, and parameter error each occupying one dimension). For example, the failure mode vector [0.6, 0.2, 0.2] indicates that 60% of the last 10 failures were timeouts, 20% were protocol rejections, and 20% were parameter errors. A high proportion of timeouts suggests potential issues with network or device processing speed; a high proportion of protocol rejections suggests potentially inappropriate protocol selection; and a high proportion of parameter errors suggests that the load mapping rules may need adjustment. This provides refined guidance for subsequent decision-making and feedback optimization of the rule engine.

[0042] By employing a four-dimensional parallel extraction approach—protocol fingerprinting, device capability querying, network status detection, and historical data compression—comprehensive and real-time context awareness capabilities are provided. Specifically, protocol type identification addresses the uncertainty of the source protocol, device capability characteristics enable the system to perceive the static configuration and real-time status of the target device, network status characteristics provide predictive awareness, and historical data compression allows the system to quickly respond to recent changes in device behavior.

[0043] In some embodiments, step 201 may include the following sub-steps: Sub-step S21: Input the protocol type feature, the target device capability feature, the network status feature, and the historical execution data feature into the first fully connected layer corresponding to each dimension, and map the original features of each dimension into sub-vectors of fixed dimensions. Sub-step S22: The sub-vectors are concatenated and input into a multilayer perceptron, and the weights of each dimension are output. Sub-step S23: Multiply the sub-vectors by their corresponding weights and then concatenate them. Reduce the dimensionality of the concatenated vectors to a preset dimension to generate the context feature vector.

[0044] The first fully connected layer consists of four independent single-layer fully connected networks that map the original features of each dimension into sub-vectors of a unified dimension. Each network corresponds to one feature for protocol type, one for target device capability, one for network state, and one for historical execution data. Each network processes only one dimension of the original feature. The input to each first fully connected layer is the original feature vector of that dimension (the dimension varies depending on the dimension; for example, protocol type is approximately 19 dimensions, and network state is approximately 5 dimensions), and the output is a sub-vector of a fixed 32 dimensions. For example, the input for protocol type is 19 dimensions (16-bit one-hot encoding + version number + 2-bit extended flag), and the output is 32 dimensions after passing through the first fully connected layer for that dimension. The input for network state is 5 dimensions (RTT, packet loss rate, jitter, bandwidth, trend factor), and the output is also 32 dimensions.

[0045] A Multilayer Perceptron (MLP) is used to dynamically calculate the fusion weights for the four dimensions based on the current feature signals of each dimension. A MLP consists of two fully connected layers and a sigmoid activation function in the last layer. Its input is a 128-dimensional vector obtained by concatenating four 32-dimensional sub-vectors, and its output is four scalar values ​​between 0 and 1, which serve as dynamic weights for the four dimensions: protocol type, target device capability, network state, and historical execution data. The sum of these four values ​​is 1.

[0046] The internal structure of a multilayer perceptron (MLP) is as follows: the first fully connected layer maps the 128-dimensional input to a 64-dimensional intermediate representation; the second fully connected layer maps the 64-dimensional intermediate representation to a 4-dimensional output; and the final sigmoid activation function compresses the 4-dimensional output to the 0-1 range. The input to the MLP not only includes the concatenation of four sub-vectors but also key statistical features calculated from these sub-vectors (such as the maximum value of the network state sub-vector and the variance of the historical execution data sub-vectors). This allows the network to identify scene patterns such as "drastic network state fluctuations" or "large historical execution variance" and adjust the weight allocation of each dimension accordingly.

[0047] During training, the parameters of this multilayer perceptron are jointly optimized with the entire adaptation rule engine. The resulting learned mapping relationships lead to the following: when the network state fluctuates drastically, the weights of network dimensions automatically increase; when the historical execution variance is large, the weights of historical dimensions automatically increase; and when both are stable, the weights of static protocol type and device capability dimensions are relatively higher. This multilayer perceptron differs structurally and functionally from the single-layer fully connected networks used for dimension mapping mentioned above. The former uses a two-layer fully connected network with an activation function to output dynamic weights, while the latter uses a single-layer fully connected network without an activation function for dimension mapping. This design enables the weight allocation to be scene-adaptive, eliminating the need for manual pre-setting of "how much the network weights should be increased when the network is poor." Instead, the multilayer perceptron automatically calculates the optimal weight allocation based on the characteristics of the input signal.

[0048] In this embodiment of the invention, protocol type features, target device capability features, network state features, and historical execution data features are respectively input into their respective first fully connected layers. Each fully connected layer is a single-layer fully connected network without an activation function, mapping the original features of each dimension into sub-vectors of a fixed dimension (32 dimensions). Since the original formats of the four-dimensional features are diverse—protocol type is one-hot encoded (approximately 19 dimensions), device capability includes multi-hot and normalized values ​​(approximately 10 dimensions), network state is a continuous value (approximately 5 dimensions), and historical execution data is a weighted value (approximately 4 dimensions)—they cannot be directly subjected to unified mathematical operations. Through their respective independent encoders, each dimension of features is mapped to a unified vector space while preserving its own semantic information, making the subsequent weighting and concatenation mathematically reasonable. The encoder parameters for each dimension are learned independently, enabling optimal compression based on the data distribution and semantic structure of each feature.

[0049] Four 32-dimensional sub-vectors are concatenated and input into a multilayer perceptron. This multilayer perceptron consists of two fully connected layers and a sigmoid activation function in the last layer. It outputs four scalar values ​​between 0 and 1 as dynamic weights for each dimension, with a sum of 1. The input to this multilayer perceptron includes not only the sub-vectors themselves but also key statistics for the current scenario—the maximum value of the network state sub-vector (reflecting network fluctuation) and the variance of the historical execution data sub-vector (reflecting historical performance stability). This design gives the weight calculation context-awareness: when network state fluctuations are severe, the output weight of the network dimension automatically increases because network factors have a much greater impact on adaptation decisions than static protocol types; when historical execution variance is large, the weight of the historical dimension automatically increases because the recent behavior trend of the device is more valuable than static capabilities; and when the network is stable and historical performance is consistent, the weights of the static protocol type and device capability dimensions are relatively higher, allowing the system to make decisions more confidently based on the inherent attributes of the device. The core advantage of this dynamic weighting mechanism is that it is not a fixed weight preset by humans, but an adaptive weight automatically calculated by the model based on the statistical characteristics of the current input signal.

[0050] Each sub-vector is multiplied by its corresponding dynamic weight and then concatenated to obtain a weighted vector (4×32=128 dimensions). This concatenated vector is then passed through a fully connected network to reduce its dimensionality to the preset 128 dimensions, generating the final context feature vector. This dimensionality reduction is not simply about maintaining the same dimensions; rather, it involves remapping and compressing the weighted concatenated features to further extract higher-order semantic information from the fused dimensions, resulting in a more compact and efficient final output. This ensures that the output context feature vector retains the complete semantics of the four-dimensional features while highlighting the most relevant information dimensions in the current scenario through the dynamic weight mechanism, providing high-quality, standardized input for subsequent reasoning decisions in the rule engine.

[0051] Traditional feature fusion methods typically employ fixed weights or simple concatenation, ignoring the varying importance of features across different scenarios. By employing a learnable dynamic weighting mechanism, the contribution of network features can be automatically strengthened when the network deteriorates, and the impact of uncertain device capability features can be automatically reduced when new devices are added, significantly improving the accuracy and robustness of subsequent adaptation decisions.

[0052] Step 202: Input the context feature vector into the adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; In this embodiment of the invention, the adaptation rule engine performs deep encoding of the context feature vector through a hierarchical attention network. First, it captures the correlation between sub-features within each dimension. Then, using protocol type as an anchor, it focuses on the device capabilities and network information most relevant to the protocol across dimensions. Finally, it outputs a 64-dimensional policy latent vector through a gating unit. This policy latent vector is input into the rule adapter of the differentiable rule decision tree, dynamically activating relevant rules in the predefined rule template library (e.g., "If the device supports MQTT and the packet loss rate is <1%, prioritize using MQTT, QoS=1"). The engine outputs the activation weight and continuous parameter offset for each rule, generating multiple candidate rule suggestions. Finally, the engine resolves contradictions between candidate rules through a four-layer conflict resolution mechanism (parameter type-based flow aggregation, security-first resolution, context-based tie-breaker, and cross-parameter consistency verification), outputting the final adaptation scheme.

[0053] In some embodiments, step 202 may include the following sub-steps: Sub-step S31: Determine the Mahalanobis distance between the context feature vector and the feature distribution of the training set; Sub-step S32: If the Mahalanobis distance does not exceed the preset threshold, the context feature vector is input into the adaptation rule engine to generate an adaptation scheme. Sub-step S33: If the Mahalanobis distance exceeds the preset threshold, then retrieve the N historical samples most similar to the context feature vector from the historical sample library. Each historical sample contains a historical context feature vector and a corresponding historical adaptation scheme, where N is a positive integer. In this embodiment of the invention, the Mahalanobis distance between the generated context feature vector and the feature distribution of the training set is determined. Mahalanobis distance is a statistical measure of the similarity between a sample and a known distribution. Unlike Euclidean distance, its core advantage lies in considering the correlation between the dimensions of the features and the variance differences of each dimension. By performing a whitening transformation on the feature space through the inverse of the covariance matrix, the influence of different dimensional units and variance variability is eliminated, making the distance measurement more scientific.

[0054] All historical context feature vectors are extracted from the training set, and their mean vectors and covariance matrices are calculated. Then, a quadratic operation is performed between the difference vector between the current context feature vector and the mean vector and the inverse of the covariance matrix to obtain the Mahalanobis distance. This distance reflects the degree of deviation between the current feature vector and the overall distribution of the training set. The smaller the distance, the closer the current scene is to the training samples, and the higher the model's confidence in that region. The larger the distance, the rarer or more abnormal the current scene is, and the more likely the model lacks sufficient training data to support it. If the Mahalanobis distance does not exceed a preset threshold (e.g., 3 standard deviations), it means that the current context feature vector belongs to a normal sample within the coverage of the training set, and there is sufficient confidence in the inference results of the main model of the adaptation rule engine. Therefore, the context feature vector is normally input into the hierarchical attention network and differentiable rule decision tree of the adaptation rule engine, and an adaptation scheme is generated according to the standard process.

[0055] If the Mahalanobis distance exceeds a preset threshold, it indicates a significant deviation between the current context feature vector and the training set distribution, falling under the category of "unknown scenarios." This could involve new types of devices, unseen protocol combinations, or extreme network conditions. In this case, the main model's inference results in this region lack sufficient data support. Therefore, a case-based inference degradation strategy is triggered: N historical samples most similar to the current context feature vector are retrieved from the historical sample library (each sample contains the historical context feature vector and its corresponding historical adaptation scheme, which may be manually annotated or validated through successful execution). These samples are marked as "to be annotated" and added to the training set after confirmation by operations personnel. This mechanism ensures that the system can still provide reasonable adaptation schemes in unknown scenarios (by referencing the most similar historical cases), and each downgraded sample eventually becomes part of the training set, preventing further degradation when encountering similar scenarios in the future. This allows for automatic regression to a conservative case-based inference strategy in "unknown scenarios," avoiding unpredictable erroneous outputs in areas without data support, ensuring the efficiency and accuracy of the main model in known scenarios, and ensuring system security and continuous scalability through a closed loop of case retrieval and manual annotation.

[0056] In some embodiments, step S33 may include the following sub-steps: Sub-step S331: Determine the mixed distance between the context feature vector and each historical sample in the historical sample library; the mixed distance is obtained by weighted summation based on protocol type distance, target device capability distance, network status distance, and historical execution data distance; In some embodiments, step S331 may include the following sub-steps: Sub-step S3311: Compare the multidimensional one-hot encoding of the protocol type feature in the context feature vector with the multidimensional one-hot encoding of the protocol type feature in the historical samples bit by bit, count the number of different bits, and obtain the protocol type distance; Sub-step S3312: Calculate the difference between the target device capability feature sub-vector in the context feature vector and the target device capability feature sub-vector in the historical samples according to each dimension, and determine the target device capability distance based on the confidence of each difference and the corresponding dimension in the target device capability feature sub-vector. Sub-step S3313: Calculate the difference between the network state feature sub-vector in the current context feature vector and the network state feature sub-vector in the historical samples according to each dimension, and determine the network state distance based on each difference and the global standard deviation of the corresponding dimension of the network state feature. Sub-step S3314: Calculate the difference between the historical execution data feature sub-vector in the current context feature vector and the historical execution data feature sub-vector in the historical samples according to each dimension, and determine the distance of the historical execution data based on each difference and the global standard deviation of the corresponding dimension of the historical execution data feature.

[0057] In this embodiment of the invention, the multidimensional one-hot encoding of the protocol type feature in the current context feature vector is compared bit by bit with the multidimensional one-hot encoding of the protocol type feature in historical samples. The number of different bits is counted to obtain the protocol type distance. For example, if the current protocol type is HTTP (the 3rd bit of the one-hot encoding is 1, and the rest are 0), and the protocol type of the historical sample is MQTT (the 7th bit of the one-hot encoding is 1, and the rest are 0), the two differ in the 3rd and 7th bits, but are the same in the rest, so the number of different bits is 2, and the protocol type distance is 2. This distance uses the Hamming distance, which is suitable for discrete one-hot encoded data. Its physical meaning is "the degree of difference between two protocol types in the encoding space." The more different bits, the greater the difference in protocol types. If the two protocol types are the same (e.g., both are HTTP), the number of different bits is 0, and the distance is 0; if the two protocol types are completely different (e.g., HTTP and CoAP), the distance is 2 (because each of the two different one-hot bits contributes 1). The maximum value of the protocol type distance is 2 (two different one-hot bits). Its calculation is simple and intuitive and conforms to the characteristics of discrete data. The weighted sum is used as a component of the mixed distance.

[0058] The target device capability feature sub-vector in the current context feature vector is compared with the target device capability feature sub-vector in historical samples, with the difference calculated item by item along each dimension. Each difference is multiplied by the confidence level of the corresponding dimension in the target device capability feature sub-vector, and the sum of the squares of the multiplied differences is calculated. The square root is then taken to obtain the target device capability distance. This distance is essentially a confidence-weighted Euclidean distance. Some capability values ​​in the target device capability features are actively declared by the device (high confidence, such as a resource list obtained through the CoAP discovery mechanism with a confidence level of 0.8), while others are implicitly inferred (low confidence, such as the lower bound of the maximum fragment length inferred from the first packet payload size with a confidence level of only 0.3). When calculating the distance, the contribution of low-confidence dimensions to the distance should be less than that of high-confidence dimensions, because low-confidence capability values ​​themselves have high uncertainty. If they were to have the same impact on the distance as high-confidence dimensions, it would mislead the search results to favor uncertain features.

[0059] The network state feature subvectors in the current context feature vector are compared with those in historical samples, with the differences calculated item by item along each dimension. Each difference is then normalized by dividing by the global standard deviation of the corresponding dimension of the network state feature. The sum of squares of the normalized differences is calculated, and the square root is taken to obtain the network state distance. Network state features include multiple dimensions such as round-trip time (RTT), packet loss rate, jitter, and bandwidth estimation. These dimensions have different units: RTT is in milliseconds, packet loss rate is in percentages, and bandwidth is in Mbps. If the raw values ​​are used directly to calculate the Euclidean distance, the larger dimensions (e.g., bandwidth estimation might be tens of Mbps) will dominate the distance calculation, while smaller dimensions (e.g., packet loss rate might be only 0.01) will have almost no effect. By normalizing by dividing by the standard deviation of each dimension in the global training set, all dimensions are unified to the same scale, eliminating the distortion caused by the difference in units and ensuring that the contribution of each dimension to the distance is proportional to its actual change.

[0060] The differences between the historical execution data feature vectors in the current context feature vector and the historical execution data feature vectors in historical samples are calculated item by item along each dimension. Each difference is normalized by dividing by the global standard deviation of the corresponding dimension of the historical execution data feature. The sum of squares of the normalized differences is calculated, and the square root is taken to obtain the historical execution data distance. The historical execution data features include a weighted success rate and a failure mode vector (three dimensions). Similar to the network state features, the dimensions and value ranges of each dimension may be different (the weighted success rate is a probability value between 0 and 1, and the failure mode statistics are counts or frequencies). The calculation method of the four component distances adopts the most appropriate distance metric for the characteristics of different data types. Through this dimensionally customized distance metric, and then weighted summation with weights, the case-based reasoning degradation path and the main model path share the same set of context semantic understanding logic, making the temporary adaptation scheme of degradation output semantically consistent with the main model logic.

[0061] Sub-step S332: Sort the historical samples in the historical sample library according to the mixed distance, and select the N historical samples with the smallest distance.

[0062] In this embodiment of the invention, a mixed distance is calculated between the current context feature vector and each historical sample in the historical sample library. This mixed distance is not a single distance metric, but rather a weighted sum of four components: protocol type distance, target device capability distance, network state distance, and historical execution data distance. A "mixed distance" is used because the four-dimensional features have different data types: protocol type is a discrete one-hot encoded value, device capability includes a confidence-weighted continuous value, and network state and historical execution data are normalized continuous values. Different data types require their own most suitable distance functions. The protocol type distance uses Hamming distance (comparing one-hot encoding bit by bit and counting the number of different bits); the target device capability distance uses confidence-weighted Euclidean distance (multiplying the difference of each dimension by the confidence level of that dimension before calculating the L2 norm), making the contribution of low-confidence capability dimensions to the distance smaller; the network state distance and historical execution data distance respectively use normalized Euclidean distance (dividing each dimension by the corresponding global standard deviation before calculating the L2 norm), eliminating the distortion of distance calculation caused by different units of measurement. After the four distance components are calculated separately, they are weighted and summed according to the same weights for each dimension in the dynamic weighted fusion output to obtain the final mixed distance.

[0063] All samples in the historical sample library are sorted from smallest to largest according to their mixture distance, and the N historical samples with the smallest mixture distance are selected as the most similar cases (N is a preset positive integer, such as 10). The smaller the mixture distance, the higher the overall similarity between the historical sample and the current scene in terms of four-dimensional features, and the higher the reference value of the corresponding historical adaptation scheme in the current scene. The purpose of selecting N cases instead of 1 case is to avoid the bias caused by the particularity of a single case. A single most similar case may happen to correspond to an abnormal execution result, while N cases can effectively filter out such individual noise through subsequent majority voting, improving the robustness of the degradation output. The mixture distance metric not only considers the characteristic differences of different data types, but also ensures that the degradation path is consistent with the main model's judgment on "what is most important in the current scene". This makes the temporary adaptation scheme output by the degradation path not an isolated result that completely deviates from the logic of the main model, but a conservative decision made within the same contextual understanding framework.

[0064] Sub-step S34: Take the historical adaptation scheme corresponding to each sample in the N historical samples as a candidate scheme, count the number of times each candidate scheme appears in the N historical samples as the vote count, take the candidate scheme with the highest vote count as the temporary adaptation scheme, and take the temporary adaptation scheme as the adaptation scheme.

[0065] In this embodiment of the invention, N most similar historical samples are selected. Each sample contains the actual or manually labeled adaptation scheme used in that historical scenario (e.g., {target_protocol: "MQTT", qos: 1, timeout_ms: 2000, retry: 1, ...}). These N historical adaptation schemes are used as candidate schemes. The number of times each candidate scheme appears in the N samples is counted as the vote count. The candidate scheme with the highest number of votes is selected as the temporary adaptation scheme, and this temporary adaptation scheme is output as the adaptation scheme. For example, assuming N=10, the adaptation schemes corresponding to the 10 most similar historical samples are: scheme A appears 6 times, scheme B appears 3 times, and scheme C appears 1 time. Then, scheme A is selected as the temporary adaptation scheme. When a tie occurs (e.g., scheme A appears 5 times and scheme B appears 5 times), distance-weighted voting can be further introduced, with historical samples that are closer in distance having higher weights, in order to break the tie. The majority voting mechanism can effectively filter out noise or anomalies that may exist in a single historical sample. Although a sample may have similar characteristics, its corresponding adaptation scheme may not be optimal due to instantaneous network fluctuations or temporary equipment failures. By taking the majority through voting, the influence of such individual biases can be suppressed, and the stability of the degraded output can be improved.

[0066] In some embodiments, the adaptation rule engine employs a hybrid architecture of hierarchical attention networks and differentiable rule decision trees; step 202 may include the following sub-steps: Sub-step S41 involves sequentially performing intra-dimensional self-attention interaction, cross-dimensional cross-attention calculation with protocol type as the query vector, and gated aggregation on the context feature vector through the hierarchical attention network, and outputting a policy latent vector; the policy latent vector is an intermediate representation of the context feature vector obtained after being encoded by the hierarchical attention network and used as input to the differentiable rule decision tree; In some embodiments, step S41 may include the following sub-steps: Sub-step S411 involves grouping the context feature vector into four-dimensional features to obtain protocol type feature sub-vectors, target device capability feature sub-vectors, network status feature sub-vectors, and historical execution data feature sub-vectors. Within each group of sub-vectors, multi-head self-attention is used to capture the correlation between different sub-features within the same dimension, resulting in sub-vectors enhanced by in-dimensional self-attention. Each group of sub-vectors includes multiple sub-features. The sub-features of the protocol type feature sub-vector include at least one of the one-hot encoded bits, protocol version number, and extended flag bits for each protocol type. The sub-features of the target device capability feature sub-vector include at least one of the protocol support bits, cipher suite support bits, and normalized values ​​for each continuous capability. The sub-features of the network status feature sub-vector include at least one of round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor. The sub-features of the historical execution data feature sub-vector include at least one of weighted success rate and statistical values ​​for each type of failure cause. In sub-step S412, using the protocol type feature sub-vector as the query matrix, the key matrix and value matrix are obtained by concatenating the target device capability feature sub-vector, network state feature sub-vector, and historical execution data feature sub-vector after in-dimensional self-attention enhancement for each group, and cross-attention is calculated. The cross-attention is used to select the feature component most relevant to the protocol type feature sub-vector from the target device capability feature sub-vector, the network state feature sub-vector, and the historical execution data feature sub-vector as the output. In sub-step S413, the output corresponding to the cross attention is added to the context feature vector through a residual connection to obtain the residual connection feature. The residual connection feature is then input into the gating unit of the hierarchical attention network for feature selection, and the policy latent vector is output.

[0067] The concatenation involves three sub-vectors enhanced with in-dimensional self-attention: the target device capability feature sub-vector (32-dimensional), the network state feature sub-vector (32-dimensional), and the historical execution data feature sub-vector (32-dimensional). These three sub-vectors have already completed self-attention interactions between their respective in-dimensional sub-features. Each element in each sub-vector has incorporated information from other in-dimensional sub-features; for example, the "packet loss rate" element in the network state sub-vector now includes jitter information and is no longer an isolated value. The concatenation method involves joining these three 32-dimensional sub-vectors sequentially end-to-end to form a single 96-dimensional vector. This 96-dimensional vector serves simultaneously as the key matrix (Key) and value matrix (Value) in the cross-dimensional cross-attention computation.

[0068] In standard attention mechanisms, the Key is used to calculate the matching degree with the query matrix Query (i.e., the "attention score"), and the Value is used to obtain the final output by weighted summation based on the attention scores. When the Key and Value use the same input (i.e., self-attention), the "correlation between positions within the input sequence" is calculated, and the output is a weighted fusion of information from each position. In this embodiment of the invention, the three-dimensional enhancement sub-vectors are concatenated and used as both Key and Value, in conjunction with the Query (protocol type feature sub-vector), to achieve "using the protocol type as an anchor point, selecting the most relevant components from the three dimensions of device capability, network status, and historical execution." The Query and Key calculate attention scores to determine which positions (which dimensional components) are most relevant to the current protocol type, and then these scores are used to weighted sum the Value, amplifying the protocol-related feature components in the output and suppressing the irrelevant ones. If the Key and Value use different inputs, this effect of "weighted fusion of other dimensional information based on the matching degree with the protocol" cannot be achieved.

[0069] In this embodiment of the invention, the context feature vector is grouped according to the original four-dimensional features to obtain four 32-dimensional sub-vectors: protocol type feature sub-vector, target device capability feature sub-vector, network status feature sub-vector, and historical execution data feature sub-vector. Then, within each group of sub-vectors, multi-head self-attention (number of heads = 4) is used to capture the correlation between different sub-features within the same dimension. Each group of sub-vectors contains multiple sub-features: the protocol type feature sub-vector includes one-hot encoded bits (16 bits) for each protocol type, normalized value of protocol version number (1 bit), and extended flag bits (whether QoS is supported, whether reserved messages are supported, a total of 2 bits); the target device capability feature sub-vector includes protocol support bits (multi-hot encoding), encryption suite support bits, and normalized values ​​of continuous capabilities (memory size, power consumption, CPU load, storage space); the network status feature sub-vector includes round-trip time (RTT), packet loss rate, jitter, bandwidth estimation, and network trend factor; the historical execution data feature sub-vector includes weighted success rate and statistical values ​​of various failure reasons (timeout, protocol rejection, parameter error).

[0070] Taking the network state feature sub-vector as an example, it contains five sub-features: RTT, packet loss rate, jitter, bandwidth estimation, and network trend factor. The self-attention mechanism can learn the correlations between these sub-features. For instance, when the packet loss rate increases, jitter often increases as well, indicating a statistical coupling between the two; when the bandwidth estimation decreases, RTT usually increases, showing a negative correlation. Through self-attention calculation, the output of each sub-feature incorporates information from other sub-features, so that the output value of the packet loss rate not only includes its original value but also information related to jitter and RTT. This information interaction between sub-features within the same dimension makes the representation of each sub-feature richer and more accurate.

[0071] The query matrix is ​​Query, using the protocol type feature sub-vector. The key matrix (Key) and value matrix (Value) are concatenated using the target device capability feature sub-vector, network state feature sub-vector, and historical execution data feature sub-vector (all enhanced with in-dimension self-attention). Cross-attention is then calculated. Protocol type is the primary driver of adaptation decisions. Different source protocols have varying sensitivities and requirements regarding device capabilities, network conditions, and historical performance. For example, when the source protocol is HTTP, adaptation decisions focus more on whether the target device supports persistent connections (device capability dimension) and whether the current bandwidth is sufficient (network state dimension), because HTTP requires maintaining connection status and has certain bandwidth requirements. When the source protocol is CoAP, adaptation decisions focus more on packet loss rate and jitter (network state dimension), because CoAP runs on top of UDP and is more sensitive to network quality fluctuations. When the source protocol is MQTT, adaptation decisions focus more on whether the device supports the MQTT protocol and its historical success rate (device capability and historical dimensions), because MQTT requires the device to have the corresponding protocol stack support. By using protocol type features as queries, the cross-attention mechanism can learn the mapping relationship between protocols and the focus of attention, select the most relevant feature components from other dimensions as output, and automatically suppress feature components that are not relevant to the current protocol.

[0072] The output of cross-attention is added to the original context feature vector via a residual connection. This residually connected feature is then input into the gating unit of the hierarchical attention network for feature selection, outputting a 64-dimensional policy latent vector. The residual connection preserves the original information. While cross-attention filters out the most relevant cross-dimensional features for the protocol, some information in the original context feature vector may be weakened or lost during attention computation. By adding the output of cross-attention to the original input (output = AttentionOutput + OriginalInput), information from the original features is preserved. The network can selectively utilize information between the original features and the attention-enhanced features, avoiding the information decay problem in deep networks.

[0073] A Gated Linear Unit (GLU) is a lightweight feature selection mechanism that independently controls each dimension of the input features through a learnable gating vector, determining which features to retain and which to suppress. Each element of the gating vector is between 0 and 1, with values ​​closer to 1 indicating retention of that dimension's information and closer to 0 indicating suppression. After gating, the 128-dimensional input features are compressed into a 64-dimensional policy latent vector output. This 64-dimensional vector condenses the contextual semantic information most relevant to the adaptation decision, filtering out redundant and noisy features, and serves as the input for subsequent differentiable rule-based decision trees. The first layer achieves information interaction between sub-features within the same dimension through intra-dimensional self-attention, enriching the representation of each sub-feature. The second layer achieves the ability to select the most relevant feature components from other dimensions based on protocol type through cross-dimensional cross-attention, giving the network protocol-aware feature selection capabilities. The third layer, through residual connections and gating units, preserves the original information while achieving feature selection, outputting a compact policy latent vector, realizing high-quality contextual semantic encoding, and providing accurate input for subsequent rule activation and adaptation scheme generation.

[0074] Sub-step S42 involves using the differentiable rule decision tree based on the policy latent vector to output the activation weights of each rule in the predefined rule template library and the offsets of continuous parameters in each rule; the activation weights represent the strength of the adoption of the corresponding rule in the current context; and the offsets are used to adjust the continuous parameters based on the preset values ​​of the rules. Sub-step S43: Apply the activation weight and continuous parameter offset of each rule to the rule template corresponding to the rule to obtain multiple candidate rule suggestions; each candidate rule suggestion includes the suggested adaptation parameter values; In this embodiment of the invention, the generated 128-dimensional context feature vector is encoded into a 64-dimensional policy latent vector through a hierarchical attention network. The hierarchical attention network contains a three-layer lightweight attention structure, and the three layers, rather than directly stacking Transformers, are multi-layer encoders, in order to avoid excessive latency while maintaining high inference performance.

[0075] The first layer employs intra-dimensional self-attention interaction: the 128-dimensional context feature vector is grouped according to the original four-dimensional features, resulting in protocol type feature sub-vectors (32-dimensional), target device capability feature sub-vectors (32-dimensional), network state feature sub-vectors (32-dimensional), and historical execution data feature sub-vectors (32-dimensional). Multi-head self-attention (4 heads) is then applied within each sub-vector group to capture the correlations between different sub-features within the same dimension. For example, the network state feature sub-vector contains multiple sub-features such as RTT, packet loss rate, jitter, bandwidth estimation, and network trend factor. This layer of self-attention can learn the coupling relationship between packet loss rate and jitter; when the packet loss rate increases, jitter often increases as well, indicating a statistical correlation between the two. The self-attention mechanism can automatically discover and encode this relationship. The specific meanings of each sub-feature include: the sub-features of the protocol type feature sub-vector are the one-hot encoded bits, protocol version number, and extended flag bits of each protocol type; the sub-features of the target device capability feature sub-vector are the protocol support bits, the encryption suite support bits, and the normalized values ​​of each continuous capability; the sub-features of the network status feature sub-vector are RTT, packet loss rate, jitter, bandwidth estimation, and network trend factor; and the sub-features of the historical execution data feature sub-vector are the weighted success rate and the statistical values ​​of failure reasons for each type.

[0076] The second layer is cross-dimensional attention: using the protocol type feature sub-vector as the query matrix, and concatenating the target device capability feature sub-vector, network state feature sub-vector, and historical execution data feature sub-vector (enhanced by intra-dimensional self-attention) as the key matrix and value matrix, cross-attention is calculated. This layer achieves "dynamically focusing on other dimensions most relevant to the protocol, using the protocol type as an anchor." For example, when the source protocol is HTTP, cross-attention will focus more on the "whether it supports long connections" sub-feature in the target device capability features and the "bandwidth estimation" sub-feature in the network state features, because the HTTP protocol has high requirements for connection persistence and bandwidth; when the source protocol is CoAP, cross-attention will focus more on the "packet loss rate" and "jitter" in the network state features, because the CoAP protocol runs on top of UDP and relies on reliable transmission mechanisms, making it more sensitive to network quality. The essence of the output of this layer is: selecting the feature components most relevant to the current protocol type from device capabilities, network state, and historical execution data as the main source of information for the policy latent vector.

[0077] The third layer is gated aggregation: the cross-attention output is added to the original context feature vector through a residual connection (preserving the original information and avoiding information loss due to excessive network depth), and then input into a lightweight gating unit for feature selection, outputting a 64-dimensional policy latent vector. The gating unit filters each feature dimension through a learnable gating mechanism, retaining the features most relevant to the adaptation decision and suppressing redundant and noisy features, making the policy latent vector a compact feature representation oriented towards adaptation decision optimization. Traditional Transformer architectures typically require stacking 6-12 encoder layers to achieve good feature extraction results, resulting in high inference latency. This embodiment of the invention uses a three-layer targeted attention structure: an intra-dimensional self-attention layer, a cross-dimensional cross-attention layer with protocol type as the query vector, and a gated aggregation layer. Through the step-by-step processing of the above three layers, the input features are effectively encoded, completing the effective encoding of 128-dimensional input features and keeping the inference latency at an extremely low level.

[0078] The output 64-dimensional policy latent vector is input into the differentiable rule decision tree, which outputs the activation weights of each rule in the predefined rule template library and the offsets of continuous parameters in each rule. The predefined rule template library is a set of pre-designed business rules, each containing a rule trigger condition and a rule action. For example: "If the packet loss rate is >5%, increase the number of retransmissions," "If the device battery level is <20%, disable encryption," "If the device supports MQTT and the network packet loss rate is <1%, prioritize using MQTT, QoS=1." Each rule corresponds to a confidence score (representing the prior reliability of the rule, with initial values ​​divided into three levels: 0.8 / 0.5 / 0.3, based on the engineering consensus strength). The rule adapter (a two-layer fully connected network) takes the policy latent vector as input and outputs activation weights (scalars between 0 and 1, representing the strength of the rule's adoption in the current context) and offsets of continuous parameters (such as the adjustment amount of the number of retransmissions within ±2 of the rule's preset value). The activation weights are multiplied by the rule confidence score to obtain the rule's overall adoption strength, which is used for subsequent multi-rule aggregation and conflict resolution.

[0079] The activation weight and offset of each rule are applied to the corresponding rule template to generate multiple candidate rule suggestions. Specifically, each rule template already contains the rule action, i.e., the suggested values ​​or ranges for each adaptation parameter. For example, a rule template might be "If the device supports MQTT and the network packet loss rate is <1%, then prioritize using MQTT, QoS=1, timeout 2000ms," where `target_protocol` suggests MQTT, `qos_level` suggests 1, and `timeout_ms` suggests 2000. The activation weight represents the strength at which the rule should be adopted in the current context (e.g., 0.9), and the offset fine-tunes the continuous parameter (e.g., `timeout_ms`) based on a preset value (e.g., +100ms to 2100ms). After applying these activation weights and offsets to the rule template, a complete candidate rule suggestion is obtained, containing the suggested values ​​for each adaptation parameter and the overall adoption strength of the rule. After undergoing the above processing, multiple rule templates are transformed into multiple candidate rule suggestions, which serve as inputs for subsequent conflict resolution and adaptation scheme generation. A hierarchical attention network enables efficient encoding of contextual feature vectors, and a differentiable rule decision tree maps the deep learning-encoded policy latent vectors into interpretable rule activation weights and parameter offsets. This ensures high fitting capability for complex scenarios while preserving the interpretability and safety boundary constraints of business rules through rule templates.

[0080] In some embodiments, the rule template library includes multiple rules, each rule containing a rule triggering condition and a rule action, the rule action including a suggested value for at least one adaptation parameter, and each rule corresponding to a confidence score; step S43 may include the following sub-steps: Sub-step S431: Based on the activation weight and the confidence score, determine the adoption strength of each rule; the adoption strength is used to represent the overall recommendation strength of the corresponding rule in the current context; Sub-step S432: For each rule, add the suggested value of each adaptation parameter in the rule action to the corresponding offset to obtain the value of each adaptation parameter after rule correction, and use the adoption strength as the confidence weight of the adaptation parameter value. Based on the value of each adaptation parameter after rule correction and the confidence weight of the adaptation parameter value, multiple candidate rule suggestions are obtained.

[0081] In this embodiment of the invention, the adoption strength of each rule is determined based on its activation weight and confidence score. The activation weight is a value between 0 and 1 (e.g., 0.9) dynamically output by the rule adapter based on the current policy latent vector, representing the degree of activation of the rule in the current context. The confidence score is a pre-set learnable parameter in the rule template, representing the prior reliability of the rule (initial values ​​are divided into three levels: 0.8 / 0.5 / 0.3 according to the engineering consensus strength, and are continuously optimized with incremental training). The adoption strength combines the two to represent the overall recommendation strength of the corresponding rule in the current context, considering not only "whether the rule is activated in the current scenario" (activation weight) but also "how reliable the rule itself is" (confidence score). For example, a rule with an activation weight of 0.9 but a confidence score of 0.3 (a C-level heuristic inference rule) has an adoption strength of 0.27, which is lower than a rule with an activation weight of 0.6 but a confidence score of 0.8 (an A-level strong consensus rule). The role of adoption strength is to comprehensively weigh the dynamic activation level and static reliability of the rule, so that high-confidence rules can obtain a high overall recommendation strength even if their activation level is slightly low, while low-confidence rules will not be blindly adopted even if their activation level is very high.

[0082] For each rule, the suggested values ​​for each adaptation parameter in the rule action are added to their corresponding offsets to obtain the corrected values ​​for each adaptation parameter. The adoption strength is then used as the confidence weight for each adaptation parameter value, and these are combined to obtain a complete candidate rule suggestion. The "Rule Action" section of each rule template already contains the suggested values ​​for each adaptation parameter. For example, the rule action for rule R is "target_protocol=MQTT, qos_level=1, retry_count=2, timeout_ms=2000". Here, target_protocol and qos_level are discrete enumeration types and do not require offset adjustment; retry_count and timeout_ms are continuous numerical types. The rule adapter outputs the corresponding offsets based on the policy implicit vector—the retry_count offset is +1, and the timeout_ms offset is +200ms. Therefore, the corrected values ​​are retry_count=2+1=3, and timeout_ms=2000+200=2200ms (the offsets are constrained by preset boundaries to ensure that the values ​​do not exceed the legal range). Then, the adoption strength of the rule (e.g., 0.72) is used as the confidence weight for these modified values, and combined into a candidate rule suggestion: "Suggestion target_protocol=MQTT, qos_level=1, retry_count=3, timeout_ms=2200, confidence weight 0.72".

[0083] The confidence weights in candidate rule proposals are used for subsequent rule conflict resolution. For example, in weighted voting, the proposal `target_protocol=MQTT` receives 0.72 votes instead of 1; in weighted summation, the contribution of the proposal `retry_count=3` is its proposed value multiplied by 0.72 before being included in the weighted summation. This makes high-confidence rule proposals have a greater influence in conflict resolution, while low-confidence rule proposals have a smaller influence, making the entire adaptation scheme more robust and reliable.

[0084] Sub-step S44: Select the optimal rule suggestion from the multiple candidate rule suggestions to generate the adaptation scheme.

[0085] In this embodiment of the invention, multiple candidate rule suggestions may conflict. For example, rule A suggests `target_protocol=MQTT, qos_level=1` based on "device supports MQTT and network packet loss rate <1%"; rule B suggests `disable encryption to save power` based on "device battery <20%"; rule C suggests `timeout_ms=2000, retry_count=1` based on "historical success rate >95%". These suggestions may conflict with each other in the same adaptation scheme. The MQTT protocol requires that the authentication mechanism cannot be empty, but rule B suggests disabling encryption; MQTT messages with QoS=1 require at least one retransmission, but rule C suggests retry_count=1 to match QoS=1. If another rule suggests retry_count=0, a contradiction will arise. Sub-step S44 resolves these contradictions through a four-layer progressive resolution mechanism.

[0086] First, determine the data type of each adaptation parameter. For discrete enumeration types (such as `target_protocol`, `qos_level`, `auth_method`), a weighted voting method is used. The suggested values ​​for these parameters from the candidate rule suggestions are used as candidates, and the adoption strength of the corresponding rule is used as the vote count. The suggested value with the highest weighted vote count is taken as the first output value for that parameter. For example, if `target_protocol` has three candidate suggestions: MQTT (adoption strength 0.72), CoAP (adoption strength 0.45), and HTTP (adoption strength 0.30), then MQTT is taken as the first output value. This is a "choose the majority" approach, suitable for discrete selection scenarios where there is no intermediate value. For numerical types (such as `retry_count`, `timeout_ms`), a weighted summation with boundary constraints is used. Each candidate suggestion value is multiplied by its corresponding adoption strength, summed, and then constrained to a valid range (e.g., `retry_count` is constrained to integers between 0 and 5).

[0087] Security parameters (authentication method, encryption switch) do not participate in the ordinary voting or summation of the first layer; instead, a hard security priority decision is adopted. The decision logic is that enabling security mechanisms (Token / X.509 authentication, encryption enabled) takes precedence over disabling them. Even if the cumulative weight of the rule suggestion to disable security is higher, as long as the cumulative weight of the rule suggestion to enable security exceeds a preset threshold (e.g., 0.3), the final value is forced to be enabled. This decision is only allowed to disable security mechanisms in extreme scenarios (e.g., the cumulative weight of all suggestions to disable security > 0.8, and the device battery level < 5%). Security priority essentially treats security constraints as hard constraints in an optimization problem, while rule weights are soft objectives that can be optimized and adjusted; security priority is an insurmountable hard boundary, and no rule suggestion can be violated.

[0088] When the difference in weighted votes between two candidate suggestions in the first-layer weighted voting is less than a preset vote threshold (e.g., Δ=0.15), the system does not randomly select or default to the lower value. Instead, it backtracks to the dimension most relevant to that parameter in the four-dimensional context features for adjudication. For example, in the candidate suggestions for `qos_level`, QoS=1 (0.48 votes) and QoS=2 (0.42 votes) are present, with a difference of 0.06, which is less than 0.15, resulting in a tie. In this case, the system calls the packet loss rate feature of the network state dimension for adjudication. If the current packet loss rate is >5%, QoS=2 (reliability priority) is selected; if the packet loss rate is <1%, QoS=1 (efficiency priority) is selected. The key significance of this layer is that rule conflict resolution itself relies on context awareness, realizing a two-way information flow from context to rule (forward) and from rule adjudication back to context (reverse), ensuring that each decision can be traced back to a specific context dimension, rather than being handled randomly or by default.

[0089] After parameter-by-parameter resolution in the first three layers, logical inconsistencies may exist between different parameters. Validation and automatic correction are performed according to a predefined lightweight dependency graph (approximately 20 rules). For example, if `target_protocol=MQTT, qos_level=2`, the MQTT protocol specification requires messages with QoS=2 to be retransmitted at least once; if `retry_count` is currently 0, it is forcibly corrected to ≥1. If `auth_method` is "no authentication" while `target_protocol=HTTPS`, the HTTPS protocol requires an authentication mechanism; therefore, `auth_method` is forcibly overwritten with "Token". If `timeout_ms=500` and `retry_count=3`, the total time for 3 retransmissions may exceed the target response time; therefore, `timeout_ms` is increased to the target response time divided by the number of retransmissions. After four layers of resolution, a conflict-free, security-constrained, and logically consistent structured adaptation scheme is obtained, which includes complete parameters such as target protocol type, QoS level, payload mapping rules, authentication method, retransmission count, and timeout, and is accompanied by a `reasoning` field (briefly explaining the main activated rules and their weights to facilitate debugging by operations and maintenance personnel).

[0090] In some embodiments, the adaptation scheme consists of multiple adaptation parameters, which are various independent configuration items in the adaptation scheme used to describe the instruction conversion format and transmission strategy, including at least one of target protocol type, QoS level, payload mapping rule, authentication method, retransmission count, and timeout time; step S44 may include the following sub-steps: Sub-step S441: All suggested values ​​from the multiple candidate rule suggestions are categorized and aggregated according to parameter data type to obtain the first output value of the adaptation parameter. In some embodiments, the data type includes discrete enumeration type and numeric type; step S441 may include the following sub-steps: In sub-step S4411, if the adaptation parameter is of discrete enumeration type, the suggested values ​​of the adaptation parameter in each candidate rule suggestion are weighted by the activation weight of the corresponding rule, and the suggested value with the highest weighted vote is taken as the first output value of the adaptation parameter; if the adaptation parameter is of numerical type, the sum of the products of the suggested values ​​of the adaptation parameter in each candidate rule suggestion and the activation weight of the corresponding rule is taken as the weighted sum value, and the weighted sum value is subject to boundary constraints, and the constrained value is taken as the first output value of the adaptation parameter.

[0091] In this embodiment of the invention, when the adaptation parameter is a discrete enumeration type (e.g., `target_protocol` takes the value MQTT / CoAP / HTTP, `qos_level` takes the value 0 / 1 / 2, and `auth_method` takes the value Token / X.509 / no authentication), a weighted voting method is used for aggregation. Specifically, the suggested values ​​for the adaptation parameter in each candidate rule suggestion are taken as candidate options, the activation weight of the corresponding rule is taken as the votes, the sum of the weighted votes obtained by each candidate option is counted, and the suggested value with the highest weighted votes is taken as the first output value of the adaptation parameter.

[0092] Taking `target_protocol` as an example: Suppose there are three candidate rule suggestions: Rule A (activation weight 0.7) suggests MQTT, Rule B (activation weight 0.5) suggests CoAP, and Rule C (activation weight 0.4) suggests MQTT. Then MQTT receives a weighted vote of 0.7 + 0.4 = 1.1, CoAP receives a weighted vote of 0.5, and HTTP receives a weighted vote of 0. The highest weighted vote, MQTT, is taken as the first output value of `target_protocol`. The reason why weighted voting is used instead of weighted summation for discrete enumeration types is that there is no numerical continuity or additivity between the values ​​of this type of parameter. There is no concept of an "intermediate protocol between MQTT and HTTP." Weighted summation would yield a physically meaningless intermediate value (e.g., if MQTT is encoded as 0 and HTTP as 2, then 0.5 × 0 + 0.5 × 2 = 1, and encoding 1 has no corresponding protocol). Weighted voting selects the one that best represents the consensus of the rule from multiple discrete candidate values, avoiding the generation of meaningless intermediate values.

[0093] When the adaptation parameter is a numeric type (e.g., `retry_count` takes the value of an integer from 0 to 5, and `timeout_ms` takes the value of an integer from 500 to 10000), aggregation is performed using a weighted summation method with boundary constraints. Specifically, the suggested value for this parameter in each candidate rule suggestion is multiplied by the activation weight of the corresponding rule, and then summed to obtain a weighted summation value. Boundary constraints are then applied to this weighted summation value (e.g., rounding to the nearest integer, or cropping to a preset minimum and maximum value), and the constrained value is used as the first output value for this adaptation parameter. For example, with `retry_count`: assuming there are three candidate rule suggestions, rule A (activation weight 0.8) suggests retry_count=2, rule B (activation weight 0.5) suggests retry_count=3, and rule C (activation weight 0.3) suggests retry_count=1. The weighted sum is 0.8×2+0.5×3+0.3×1=1.6+1.5+0.3=3.4. The system rounds this value to 3 and constrains it to the preset range of 0~5 (3 is within this range in this example, so no pruning is needed). The final first output value of `retry_count` is 3. Numerical values ​​can be compromised between different rule suggestions (for example, if one rule suggests retransmitting 2 times and another suggests retransmitting 4 times, a compromise of 3 times is reasonable). The weighted summation can smoothly integrate the suggestions of multiple rules, ensuring the result takes into account all activated rules.

[0094] Discrete enumeration types avoid generating meaningless intermediate values ​​through weighted voting, while numerical types achieve smooth fusion of multiple rule suggestions through weighted summation, jointly ensuring the rationality of the first-level aggregation result. Compared to aggregation methods such as fixed priority or simple averaging, activating weights through rules allows the aggregation result to dynamically adjust the influence of each rule according to the context, achieving context-aware adaptation.

[0095] Sub-step S442: For the security-related parameters in the adaptation parameters, the sum of the adoption strengths of the candidate rule suggestions that recommend enabling security mechanisms in each candidate rule suggestion is used as the cumulative weight for enabling security, and the sum of the adoption strengths of the candidate rule suggestions that recommend disabling security mechanisms is used as the cumulative weight for disabling security. The cumulative weight for enabling security is compared with the cumulative weight for disabling security, and the suggestion value for the security-related parameter in the candidate rule suggestions corresponding to the cumulative weight is taken as the second output value of the security-related parameter. The adaptation parameters include security-related parameters, which are adaptation parameters that affect communication security, including authentication methods. Sub-step S443: When the difference in weighted votes of multiple suggested values ​​after classification and aggregation is less than a preset vote threshold, the dimensional feature value that has a mapping relationship with the adaptation parameter in the four-dimensional feature is used as the decision basis, and the suggested value with a higher matching degree with the dimensional feature value is determined from the multiple suggested values ​​as the third output value of the adaptation parameter. Sub-step S444: merge the first output value, the second output value and the third output value, and perform consistency verification on the combination relationship between each adaptation parameter, and correct the values ​​of parameters that violate the predefined consistency constraints to meet the consistency constraints. Sub-step S445: Generate the adaptation scheme based on each adaptation parameter after consistency verification and correction.

[0096] In this embodiment of the invention, the adaptation scheme is the final output in complete JSON format, containing several fields: `target_protocol` (target protocol type), `qos_level` (QoS level), `payload_mapping_rules` (payload mapping rules), `auth_method` (authentication method), `retry_count` (number of retransmissions), and `timeout_ms` (timeout period). Each field is called an "adaptation parameter," and the adaptation scheme is composed of these adaptation parameters. For example, the final adaptation scheme is `{target_protocol: "MQTT", qos_level: 1, payload_mapping_rules: {...}, auth_method: "Token", retry_count: 1, timeout_ms: 2000}`, where `target_protocol`, `qos_level`, etc., are all adaptation parameters.

[0097] This embodiment addresses the problem of "how to aggregate multiple rules with different suggested values ​​for the same parameter into a single value." First, all candidate rule suggestions for the appropriate parameter are categorized by data type: discrete enumeration types (e.g., `target_protocol` takes values ​​of MQTT / CoAP / HTTP, `qos_level` takes values ​​of 0 / 1 / 2, and `auth_method` takes values ​​of Token / X.509 / no authentication) and numeric types (e.g., `retry_count`, `timeout_ms`). For discrete enumeration types, a weighted voting method is used: the suggested value corresponding to the parameter from each candidate rule suggestion is used as a candidate, and the adoption strength of the corresponding rule is used as the vote. The suggested value with the highest weighted vote is taken as the "first output value" for that parameter. For numerical types, a weighted summation is used. The suggested value for this parameter in each candidate rule proposal is multiplied by the adoption strength of the corresponding rule, and then summed. Boundary constraints are then applied to the summation result (e.g., `retry_count` is constrained to an integer between 0 and 5, `timeout_ms` is constrained to between 500 and 10000). The constrained value is used as the "first output value" for this parameter. The first output value of this layer is the initial value of each adaptation parameter after aggregation calculation.

[0098] Security parameters refer to adaptation parameters that affect communication security (including authentication method `auth_method`, encryption switch, etc.). They do not participate in the ordinary voting or summation of the first layer; instead, they are decided solely by security priority. The sum of the adoption strengths of candidate rule suggestions that recommend enabling security mechanisms is used as the "cumulative weight of security enabling" (e.g., the sum of the adoption strengths of all rules suggesting "enable Token authentication" is 1.2), and the sum of the adoption strengths of candidate rule suggestions that recommend disabling security mechanisms is used as the "cumulative weight of security disabling" (e.g., the sum of the adoption strengths of all rules suggesting "no authentication" is 0.5). These two are then compared, and the suggestion value corresponding to the greater cumulative weight is taken as the "second output value" of that security parameter. For example, if the cumulative weight of security enabling (1.2) > the cumulative weight of security disabling (0.5), then `auth_method` will ultimately be "Token authentication". Security priority is an insurmountable hard constraint boundary; even if most rules recommend disabling security mechanisms for power saving reasons, as long as the cumulative weight of enabling security still exceeds the threshold, security takes priority.

[0099] When a tie occurs in the weighted voting of the first-level discrete enumeration type, if the difference in the weighted votes of the two candidate suggestions is less than a preset vote threshold (e.g., Δ=0.15), instead of randomly selecting or defaulting to the lower value, the decision is made by backtracking to the dimension feature value in the extracted four-dimensional context features that has a mapping relationship with the adaptation parameter. The candidate value with a higher matching degree to the dimension feature value is determined from the tied candidate values ​​as the "third output value" of that parameter. For example, if the candidate suggestions for `qos_level` include QoS=1 (0.48 votes) and QoS=2 (0.42 votes), and the difference between them is 0.06, which is less than 0.15, the packet loss rate feature of the network state dimension is used for decision-making. If the current packet loss rate is >5%, QoS=2 (reliability priority) is selected; if the packet loss rate is <1%, QoS=1 (efficiency priority) is selected.

[0100] The first, second, and third output values ​​are merged according to parameters (i.e., each parameter takes the latest value after processing through all applicable levels) to obtain the initial values ​​of each adaptation parameter. Then, the consistency of the combination relationship between the adaptation parameters is checked. For example, if `target_protocol=MQTT` and `qos_level=2`, the MQTT protocol specification requires that messages with QoS=2 must be retransmitted at least once. If the current `retry_count` is 0, the consistency constraint is violated, and the system will force `retry_count` to be ≥1. If `auth_method` is "no authentication" and `target_protocol=HTTPS`, the HTTPS protocol requires an authentication mechanism, and the system will force `auth_method` to be overwritten with "Token". If `timeout_ms=500` and `retry_count=3`, 3 retransmissions may cause the total time to exceed the target response time, so `timeout_ms` is increased to the target response time divided by the number of retransmissions. Consistency constraints are encoded using a lightweight dependency graph (approximately 20 rules), which can be completed in a single O(n) traversal during verification. Based on the fully processed adaptation parameter set (each parameter undergoes data type aggregation, security resolution, tie-breaker, and consistency verification), the final adaptation scheme is generated as a structured JSON object containing fields such as `target_protocol`, `qos_level`, `payload_mapping_rules`, `auth_method`, `retry_count`, and `timeout_ms`, along with a `reasoning` field describing the main activated rules and their weights, facilitating debugging by operations personnel. The generated adaptation scheme will be sent to the instruction conversion module and load balancing module for protocol format conversion and instruction distribution scheduling, respectively.

[0101] The aforementioned four-layer conflict resolution mechanism resolves various potential contradictions among multiple candidate rule suggestions through parameter type diversion, hard security constraints, context backtracking adjudication, and cross-parameter consistency verification. This ensures that the value of each parameter in the adaptation scheme has a clear source and traceable decision basis. Discrete parameters are resolved through voting, numerical parameters through weighted summation, security parameters through hard constraint coverage, ties through context backtracking adjudication, and cross-parameter conflicts through dependency graph verification and correction, thus ensuring the reliability of the final adaptation scheme in terms of security compliance, parameter consistency, and context adaptability.

[0102] Step 203: According to the adaptation scheme, convert the source protocol instruction into the target protocol instruction; In this embodiment of the invention, based on the specific instructions of each parameter in the generated adaptation scheme, the source protocol instructions are converted from their original format to an instruction format conforming to the target protocol specification, i.e., a "translation" is performed between protocols. A structured adaptation scheme (containing parameters such as target protocol type, QoS level, payload mapping rules, authentication method, retransmission count, and timeout) is received from the adaptation rule engine, and the conversion operation is completed based on these parameters: the source protocol request URL is parsed into the subject or path format of the target protocol; then, the key-value pairs in the source protocol payload are mapped and formatted according to the `payload_mapping_rules` in the adaptation scheme; next, the transmission behavior of the target protocol is configured according to the transmission strategy parameters such as QoS level, retransmission count, and timeout set in the adaptation scheme; finally, the converted instructions are sent out through the corresponding protocol client.

[0103] Step 204: Collect the current load statistics of each target device, and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but unconfirmed instructions, the number of confirmed instructions still waiting in the queue, and the number of instructions being executed. In this embodiment of the invention, the number of issued but unconfirmed instructions, the number of confirmed and received instructions still waiting in the queue, and the number of instructions being executed are weighted and summed according to a preset weight, and then divided by the maximum equivalent processing capacity of the device to obtain the equivalent load rate of each device. Based on the equivalent load rate, when the equivalent load rate of the target device is less than or equal to a preset load rate threshold and the current latency is less than or equal to a preset latency threshold, the device is marked as an available device, the instruction issuance time is set to the current time, and the instruction is issued immediately; when the equivalent load rate exceeds 80% or the latency exceeds 200ms, the device is marked as an unavailable device, and the instruction issuance time is postponed to the first available time after the device's load rate and latency have both recovered to below the threshold. During this period, newly arriving instructions will not be sent to the device.

[0104] In some embodiments, step 204 may include the following sub-steps: Sub-step S51: Determine the equivalent load rate of each target device based on the number of issued but unconfirmed instructions, the number of confirmed and received instructions still waiting in the queue, the number of instructions being executed, and the corresponding preset weights. Sub-step S52: Obtain the current latency value of each target device; the latency value is used to characterize the current network communication latency of the target device; Sub-step S53: If the equivalent load rate of the target device is less than or equal to a preset load rate threshold and the current delay value is less than or equal to a preset delay threshold, then the target device is determined to be an available device, and the instruction issuance time of the target device is set to the current time. In sub-step S54, if the equivalent load rate of the target device is greater than the preset load rate threshold or the delay is greater than the preset delay threshold, the target device is marked as an unavailable device, and the instruction issuance time of the target device is postponed until the first available time after the equivalent load rate of the target device recovers to below the preset load rate threshold and the delay recovers to below the preset delay threshold.

[0105] In this embodiment of the invention, the equivalent load rate of each target device is determined based on the number of issued but unconfirmed instructions (`N_inflight`), the number of confirmed and received instructions still waiting in the queue (`N_queued`), and the number of instructions being executed (`N_executing`), as well as the corresponding preset weights (α=0.4, β=0.35, γ=0.25). `N_inflight` is maintained locally in real-time by the instruction conversion module; the counter increments by 1 for each issued instruction and decrements by 1 for each received confirmation or timeout notification, resulting in zero network overhead and the highest real-time performance. `N_queued` and `N_executing` are reported by the target device every 30 seconds via heartbeat messages (corresponding to the `queue_len` and `exec_count` fields, respectively), resulting in a maximum information delay of 30 seconds. The three counts reflect the pressure on the device at different levels: `N_inflight` reflects protocol layer pressure (consuming retransmission resources at the sending end), `N_queued` reflects queue layer pressure (consuming device memory; queue overflow can lead to new instructions being rejected), and `N_executing` reflects processing layer pressure (consuming CPU resources, but instruction execution time is short and less volatile). The different weights of the three reflect their varying degrees of impact on the overall system pressure. The formula for calculating the equivalent load rate is: Equivalent Load Rate = (0.4 × N_inflight + 0.35 × N_queued + 0.25 × N_executing) / L_max, where L_max is the device's maximum equivalent processing capacity, determined by the static capacity field in the device's capacity database: L_max = number of CPU cores × parallelism coefficient + maximum queue capacity × 0.3. The default value for the parallelism coefficient is 2, and it can be adaptively adjusted based on the actual measured performance of the device. When a device heartbeat is continuously missing, it enters a conservative estimation mode. When one heartbeat cycle (30 seconds) is missing, N_queued and N_executing are multiplied by the previous value and a decay factor of 0.8; when two cycles (60 seconds) are missing, they are multiplied by 0.5; when three cycles (90 seconds) are missing, a health check is triggered and the device is removed from the candidate list.

[0106] Obtain the current latency value of each target device to characterize the current network communication latency of the target device. This latency value can be the round-trip time (RTT) obtained through active probing (calculated as a smoothed average by sending a lightweight Ping / ICMP timestamp request every 5 seconds), or the response latency observed from the most recent command interaction. The latency value is a second independent dimension for determining the availability of a device. Even if the equivalent load rate is not high, if the network latency is too high (e.g., exceeding 200ms), it indicates a problem with the communication link, and sending commands to that device in this case may also result in timeout failure.

[0107] If the effective load rate of the target device is less than or equal to a preset load rate threshold (e.g., 80%) and the current latency is less than or equal to a preset latency threshold (e.g., 200ms), the target device is determined to be an available device, and the instruction delivery time for the target device is set to the current time. This means that instructions do not need to wait and are immediately delivered through the device. Only when both conditions of no overload and normal network latency are met simultaneously is the device considered healthy and able to immediately receive new instructions. If one condition is met but the other condition is not (e.g., low load but high latency or low latency but high load), the device is considered unavailable. If the effective load rate of the target device is greater than the preset load rate threshold (exceeding 80%) or the latency is greater than the preset latency threshold (exceeding 200ms), the target device is marked as an unavailable device, and the instruction delivery time for the target device is postponed until the first available time after the effective load rate and latency of the target device recover to below the preset load rate threshold. During this period, newly arrived instructions will not be sent to the device, and instructions that have arrived but not yet been delivered will remain in the delivery queue waiting for their turn. When the device load or latency returns to normal, the system re-marks it as available, and a queuing instruction is then issued.

[0108] The instruction issuance timing determination mechanism based on equivalent load rate and dual threshold judgment can distinguish the different pressures that instructions exert on device resources at different stages, thereby making more precise load judgments. It effectively avoids sending instructions to overloaded or poorly networked devices, and prevents device queue overflow and instruction timeout failures.

[0109] Step 205: At the time when the instructions are issued by each target device, the target protocol instructions are sent to the target device.

[0110] In this embodiment of the invention, during actual execution, a queue of instructions to be sent is maintained. Each instruction in the queue is sorted and scheduled according to a determined sending time. Instructions with a sending time of "the current time" enter the immediate sending channel, while instructions with delayed sending times remain in the queue awaiting their turn. Secondly, during sending, a secure session is established with the target device according to the authentication method (Token or X.509 certificate) specified in the adaptation scheme, or an existing long connection is reused. Then, the target protocol instruction is sent to the target device through the selected physical channel. After sending is completed, the number of sent but unconfirmed instructions (Zone 1) is incremented by 1, and a timeout timer is started to wait for confirmation messages or execution result feedback from the target device.

[0111] Step 206: Monitor the execution result of the target device executing the target protocol instruction, generate training samples based on the execution result, and perform incremental training on the adaptation rule engine based on the training samples to fine-tune the parameters of the adaptation rule engine.

[0112] In this embodiment of the invention, the actual results of the target device executing the target protocol instructions are monitored, and the execution results are transformed into training samples. Based on these samples, the adaptation rule engine is incrementally trained to achieve continuous evolution. The execution results of each target protocol instruction are monitored in real time. If the instruction is executed successfully, the system records the response time and compares it with the historical average response time of the target device. If the current response time is lower than the historical average, it indicates that the current adaptation scheme performs well in terms of efficiency. The context feature vector corresponding to the instruction and the adaptation scheme are then labeled as positive samples and stored in the training set.

[0113] If the instruction execution fails, the failure cause analysis process begins: The first layer parses the native error code of the protocol (e.g., 0x81 Refused for MQTT) to obtain a preliminary classification direction; the second layer calls the extracted four-dimensional features to verify the preliminary hypotheses dimension by dimension: protocol type dimension verifies whether the current protocol is included in the device's known protocol list (verifying the "protocol incompatibility" hypothesis); device capability dimension verifies whether the converted payload parameters are within the device's capability boundaries (verifying the "parameter out of range" hypothesis); network status dimension verifies whether the device's most recent heartbeat time is within the normal window (verifying the "device offline" hypothesis); the third layer uses multi-cause Bayesian attribution to output the primary cause of failure and its confidence level, as well as secondary causes and their confidence levels (e.g., "Primary cause: Protocol incompatibility, confidence level 0.85; Secondary cause: Device offline, confidence level 0.30"). After attribution, the context feature vector, adaptation scheme, and primary cause of failure are labeled as negative samples and stored in the training set.

[0114] Incremental model training is triggered every time a predetermined number of new samples (e.g., 1000) are collected. Incremental training employs Mini-batch Stochastic Gradient Descent (SGD) with a batch size of 32, a learning rate of 0.0001, and 5 training epochs. During training, the parameters of the hierarchical attention network are frozen, and only the parameters of the rule adapter layer in the differentiable rule decision tree are updated. This preserves the basic feature representation capabilities already learned by the model, and only fine-tunes the rule adapter layer, ensuring that the model absorbs new knowledge without losing historical knowledge. After training, the new model is deployed using a blue-green deployment strategy. Specifically, two environments are maintained: a blue environment running the current stable version of the model, and a green environment deploying the newly trained model. The new model is first tested in a gray-scale environment with 10% of the traffic to observe whether the adaptation accuracy is stable (e.g., whether it reaches an accuracy of over 95%). Once confirmed to be correct, the system switches to 100% traffic, and the old model is immediately taken offline. If abnormal accuracy is found during gray-scale testing, the system immediately rolls back to the old model to prevent a defective model from affecting all users. By incrementally training based on the execution results, the adaptation rule engine acquires the ability to continuously learn and self-evolve, ensuring the stability and continuous improvement of the model in long-term operation.

[0115] Reference Figure 3 The diagram illustrates a flowchart of a cross-protocol instruction adaptation and distribution method provided by an embodiment of the present invention. Figure 3 This demonstrates the complete process of an embodiment of the present invention. Upon receiving the source protocol instruction stream, the system first extracts the four-dimensional features of the target device (protocol type, device capabilities, network status, and historical execution data) and fuses them to generate a context feature vector. Then, an adaptation scheme (including target protocol conversion parameters, data format, and authentication method) is generated through the adaptation rule engine. Subsequently, the instruction is converted into the target protocol format according to the adaptation scheme. The load balancing module selects the optimal target device based on the load and network latency of each device before issuing the instruction. After issuance, the system continuously monitors the execution results of the target device and generates positive and negative samples for successful or failed results. These samples are then fed back to the adaptation rule engine through incremental training to achieve continuous optimization of the model.

[0116] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0117] Reference Figure 4 The diagram illustrates a structural block diagram of a cross-protocol instruction adaptation and distribution device provided in an embodiment of the present invention. The device specifically includes the following modules: The feature vector generation module 301 is used to receive a source protocol instruction stream, extract four-dimensional features of the target device based on the source protocol instruction stream, and perform weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; The adaptation scheme generation module 302 is used to input the context feature vector into the adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; The protocol instruction conversion module 303 is used to convert the source protocol instruction into the target protocol instruction according to the adaptation scheme; The instruction issuance time determination module 304 is used to collect the current load statistics of each target device and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but not yet confirmed instructions, the number of confirmed instructions still waiting in the queue, and the number of instructions being executed. The target instruction sending module 305 is used to send the target protocol instruction to the target device at the instruction sending time of each target device.

[0118] In some embodiments, the apparatus further includes: The feedback optimization module is used to monitor the instruction execution result of the target device executing the target protocol instruction, generate training samples based on the instruction execution result, and perform incremental training on the adaptation rule engine based on the training samples to fine-tune the parameters of the adaptation rule engine.

[0119] In some embodiments, the adaptation rule engine employs a hybrid architecture of hierarchical attention networks and differentiable rule decision trees; the adaptation scheme generation module 302 includes: The policy latent vector output submodule is used to sequentially perform intra-dimensional self-attention interaction, cross-dimensional cross-attention calculation with protocol type as the query vector, and gated aggregation on the context feature vector through the hierarchical attention network, and output the policy latent vector; the policy latent vector is an intermediate representation of the context feature vector after being encoded by the hierarchical attention network and used as input to the differentiable rule decision tree; The rule activation submodule is used to output the activation weight of each rule in the predefined rule template library and the offset of the continuous parameters in each rule based on the policy latent vector through the differentiable rule decision tree; the activation weight represents the strength of the adoption of the corresponding rule in the current context; the offset is used to adjust the continuous parameters based on the rule preset value; The candidate suggestion generation submodule is used to apply the activation weight and the offset of continuous parameters of each rule to the rule template corresponding to the rule, so as to obtain multiple candidate rule suggestions; each candidate rule suggestion includes the suggested adaptation parameter values; The adaptation scheme generation submodule is used to select the optimal rule suggestion from the multiple candidate rule suggestions and generate the adaptation scheme.

[0120] In some embodiments, the policy latent vector output submodule includes: An intra-dimensional self-attention unit is used to group the context feature vector according to four-dimensional features, obtaining protocol type feature sub-vectors, target device capability feature sub-vectors, network status feature sub-vectors, and historical execution data feature sub-vectors. Multi-head self-attention is used within each group of sub-vectors to capture the correlation between different sub-features within the same dimension, resulting in sub-vectors enhanced by intra-dimensional self-attention. Each group of sub-vectors includes multiple sub-features. The sub-features of the protocol type feature sub-vector include at least one of the one-hot encoded bits of each protocol type, protocol version number, and extended flag bits. The sub-features of the target device capability feature sub-vector include at least one of the protocol support bits, cipher suite support bits, and continuous capability normalized values. The sub-features of the network status feature sub-vector include at least one of round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor. The sub-features of the historical execution data feature sub-vector include at least one of weighted success rate and statistical values ​​of various failure reasons. The cross-dimensional cross-attention unit is used to calculate cross-attention by concatenating the target device capability feature vector, network state feature vector, and historical execution data feature vector (all enhanced by in-dimensional self-attention) into a key matrix and a value matrix. The cross-attention is used to select the feature component most relevant to the protocol type feature vector from the target device capability feature vector, the network state feature vector, and the historical execution data feature vector as the output. The gated aggregation unit is used to add the output corresponding to the cross-attention to the context feature vector through a residual connection to obtain the residual connected features, and input the residual connected features into the gated unit of the hierarchical attention network for feature selection, and output the policy latent vector.

[0121] In some embodiments, the rule template library includes multiple rules, each rule containing a rule triggering condition and a rule action, the rule action including a suggested value for at least one adaptation parameter, and each rule corresponding to a confidence score; the candidate suggestion generation submodule includes: The adoption strength determination unit is used to determine the adoption strength of each rule based on the activation weight and the confidence score; the adoption strength is used to represent the overall recommendation strength of the corresponding rule in the current context; The candidate suggestion combination unit is used to, for each rule, add the suggested value of each adaptation parameter in the rule action to the corresponding offset to obtain the value of each adaptation parameter after rule correction, and use the adoption strength as the confidence weight of the adaptation parameter value. Based on the value of each adaptation parameter after rule correction and the confidence weight of the adaptation parameter value, multiple candidate rule suggestions are obtained.

[0122] In some embodiments, the adaptation scheme comprises multiple adaptation parameters, which are various independent configuration items in the adaptation scheme used to describe the instruction conversion format and transmission strategy, including at least one of target protocol type, QoS level, payload mapping rules, authentication method, retransmission count, and timeout period; the adaptation scheme generation submodule includes: The parameter classification and aggregation unit is used to classify and aggregate all suggestion values ​​from the multiple candidate rule suggestions according to the parameter data type, and obtain the first output value of the adaptation parameter: A security constraint unit is used to, for the security-related parameters in the adaptation parameters, take the sum of the adoption strengths of candidate rule suggestions that recommend enabling security mechanisms as the cumulative weight for security enabling, and the sum of the adoption strengths of candidate rule suggestions that recommend disabling security mechanisms as the cumulative weight for security disabling. The unit compares the cumulative weights for security enabling and disabling, and takes the recommended value for the security-related parameter in the candidate rule suggestions corresponding to the cumulative weight as the second output value of the security-related parameter. The adaptation parameters include security-related parameters, which are adaptation parameters affecting communication security, including authentication methods. The candidate suggestion value adjudication unit is used to determine the suggestion value with a higher matching degree with the dimension feature value as the third output value of the adaptation parameter when the difference of the weighted votes of multiple suggestion values ​​after classification and aggregation is less than a preset vote threshold. The unit uses the dimension feature value of the four-dimensional feature that has a mapping relationship with the adaptation parameter as the adjudication basis. The consistency verification unit is used to merge the first output value, the second output value and the third output value, and to perform consistency verification on the combination relationship between each adaptation parameter, and to correct the values ​​of parameters that violate the predefined consistency constraints to meet the consistency constraints. The adaptation scheme output unit is used to generate the adaptation scheme based on each adaptation parameter after consistency verification and correction.

[0123] In some embodiments, the data type includes discrete enumeration type and numeric type; the parameter classification aggregation unit includes: The suggestion value weighting submodule is used to perform weighted voting on the suggested values ​​of the adaptation parameter in each candidate rule suggestion if the adaptation parameter is of discrete enumeration type, using the activation weight of the corresponding rule as the vote, and taking the suggestion value with the highest weighted vote as the first output value of the adaptation parameter; if the adaptation parameter is of numerical type, the sum of the products of the suggested values ​​of the adaptation parameter in each candidate rule suggestion and the activation weight of the corresponding rule is used as the weighted sum value, and the weighted sum value is subject to boundary constraints, and the constrained value is used as the first output value of the adaptation parameter.

[0124] In some embodiments, the protocol type feature includes at least one of the following: multidimensional one-hot encoding of the protocol type, normalized value of the protocol version number, and extended flag bit; the target device capability feature includes static capabilities and dynamic capabilities, wherein the static capabilities include at least one of CPU architecture, memory size, list of available protocols, supported cipher suites, and maximum message fragment length, and the dynamic capabilities include at least one of current remaining battery power, CPU load, and available storage space; the network status feature includes at least one of round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor; the historical execution data feature includes weighted success rate and failure mode vector, wherein the failure mode vector includes at least one of timeout, protocol rejection, and parameter error; The feature vector generation module 301 includes: The protocol type feature extraction submodule is used to perform protocol fingerprint recognition on the source protocol instruction stream to determine the source protocol type, generate the multi-dimensional one-hot code according to the source protocol type, parse the normalized value of the protocol version number from the protocol header of the source protocol instruction stream, and parse the extended flag bit from the protocol header of the source protocol instruction stream. The device capability feature extraction submodule is used to query the device capability database based on the target device identifier in the source protocol instruction stream, read the static and dynamic capabilities of the target device, and obtain the target device capability features based on the static and dynamic capabilities. The network state feature extraction submodule is used to send probe messages to the target device to obtain the round-trip time based on the target device identifier or target device address in the source protocol instruction stream, listen to the transport layer retransmission event and communication quality feedback report of the target device to obtain the packet loss rate and jitter, use the sliding window message pair algorithm to obtain the bandwidth estimate, and obtain the slope of the packet loss rate change in the past time window to determine the network trend factor. The historical execution data feature extraction submodule is used to query the historical execution database based on the target device identifier in the source protocol instruction stream, read the historical execution records of the target device within a preset time range, determine the weighted success rate based on the historical execution records using an exponential decay time window, statistically analyze the distribution of reasons for the most recent preset number of failures, and generate a failure mode vector.

[0125] In some embodiments, the protocol fingerprinting includes parallel execution of port number identification, first byte feature identification, and finite state machine deep parsing; the protocol type feature extraction submodule includes: The identification result acquisition unit is used to perform port number identification, first byte feature identification and finite state machine deep analysis in parallel on the source protocol instruction stream, and obtain the port number identification result and corresponding port confidence, the first byte feature identification result and corresponding first byte confidence, and the finite state machine deep analysis result and corresponding structure matching confidence, respectively. The protocol type identification unit is used to identify the protocol type of the source protocol instruction stream if the finite state machine deep parsing result is a complete syntax structure verification of a certain protocol. The protocol type determination unit is used to determine the port number identification result and the first byte feature identification result as candidate protocols if the finite state machine deep parsing result fails to complete the complete syntax structure verification. The port confidence, the first byte confidence and the structure matching confidence are multiplied by their respective preset weights and summed to obtain the weighted confidence of each candidate protocol. The candidate protocol with the highest weighted confidence is selected as the protocol type of the source protocol instruction stream.

[0126] In some embodiments, the feature vector generation module 301 includes: The sub-vector mapping submodule is used to input the protocol type feature, the target device capability feature, the network status feature and the historical execution data feature into the first fully connected layer corresponding to each dimension, and map the original features of each dimension into sub-vectors of fixed dimensions respectively. The dynamic weight calculation submodule is used to concatenate the subvectors and input them into the multilayer perceptron, and output the weights of each dimension. The weighted fusion and dimensionality reduction submodule is used to multiply the subvectors by their respective weights and then concatenate them, reducing the dimensionality of the concatenated vectors to a preset dimension to generate the context feature vector.

[0127] In some embodiments, the instruction issuance time determination module 304 includes: The equivalent load rate calculation submodule is used to determine the equivalent load rate of each target device based on the number of issued but unconfirmed instructions, the number of confirmed and received instructions still waiting in the queue, the number of instructions being executed, and the corresponding preset weights. The latency acquisition submodule is used to acquire the current latency value of each target device; the latency value is used to characterize the current network communication latency of the target device. The instruction issuance time determination submodule is used to determine the target device as an available device and set the instruction issuance time of the target device to the current time if the equivalent load rate of the target device is less than or equal to a preset load rate threshold and the current delay value is less than or equal to a preset delay threshold; if the equivalent load rate of the target device is greater than the preset load rate threshold or the delay is greater than the preset delay threshold, the target device is marked as an unavailable device and the instruction issuance time of the target device is postponed to the first available time after the equivalent load rate of the target device recovers to below the preset load rate threshold and the delay recovers to below the preset delay threshold.

[0128] In some embodiments, the adaptation scheme generation module 302 further includes: The Mahalanobis distance detection submodule is used to determine the Mahalanobis distance between the context feature vector and the feature distribution of the training set; The main model processing submodule is used to input the context feature vector into the adaptation rule engine to generate an adaptation scheme if the Mahalanobis distance does not exceed a preset threshold. The downgrade processing submodule is used to retrieve N historical samples from the historical sample library that are most similar to the context feature vector if the Mahalanobis distance exceeds the preset threshold. Each historical sample contains a historical context feature vector and a corresponding historical adaptation scheme, where N is a positive integer. The historical adaptation scheme corresponding to each of the N historical samples is taken as a candidate scheme, and the number of times each candidate scheme appears in the N historical samples is counted as the vote count. The candidate scheme with the highest vote count is taken as a temporary adaptation scheme, and the temporary adaptation scheme is taken as the adaptation scheme.

[0129] In some embodiments, the degradation processing submodule includes: A hybrid distance calculation unit is used to determine the hybrid distance between the context feature vector and each historical sample in the historical sample library; the hybrid distance is obtained by weighted summation based on protocol type distance, target device capability distance, network status distance, and historical execution data distance. The similar sample selection unit is used to sort the historical samples in the historical sample library according to the mixed distance and select the N historical samples with the smallest distance.

[0130] In some embodiments, the hybrid distance calculation unit includes: The protocol type distance determination subunit is used to compare the multidimensional one-hot encoding of the protocol type feature in the context feature vector with the multidimensional one-hot encoding of the protocol type feature in the historical samples bit by bit, count the number of different bits, and obtain the protocol type distance. The device capability distance determination subunit is used to calculate the difference between the target device capability feature subvector in the context feature vector and the target device capability feature subvector in the historical samples according to each dimension, and determine the target device capability distance based on the confidence of each difference and the corresponding dimension in the target device capability feature subvector. The network state distance determination subunit is used to calculate the difference between the network state feature subvector in the current context feature vector and the network state feature subvector in the historical samples item by item according to each dimension, and determine the network state distance based on each difference and the global standard deviation of the corresponding dimension of the network state feature. The execution data distance determination subunit is used to calculate the difference between the historical execution data feature subvector in the current context feature vector and the historical execution data feature subvector in the historical samples according to each dimension, and determine the historical execution data distance based on each difference and the global standard deviation of the corresponding dimension of the historical execution data feature.

[0131] As the apparatus embodiment is basically similar to the method embodiment, it is described in a relatively simple manner. For relevant details, please refer to the description of the method embodiment.

[0132] This invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the various processes of the cross-protocol instruction adaptation and distribution method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0133] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the cross-protocol instruction adaptation and distribution method embodiments described above, and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0134] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0135] Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present invention is not limited to performing functions in the order shown or discussed. It may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0137] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A cross-protocol instruction adaptation and distribution method, characterized in that, The method includes: The system receives a source protocol instruction stream, extracts four-dimensional features of the target device based on the source protocol instruction stream, and performs weighted fusion of the four-dimensional features to generate a context feature vector. The source protocol instruction stream contains multiple instructions pointing to different target devices. The four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features. The context feature vector is input into the adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to determine the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; According to the adaptation scheme, the source protocol instructions are converted into the target protocol instructions; Collect the current load statistics of each target device, and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but unacknowledged instructions, the number of acknowledged instructions still waiting in the queue, and the number of instructions being executed. At the time when the instruction is issued to each target device, the target protocol instruction is sent to the target device.

2. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The method further includes: The system monitors the execution results of the target device's execution of the target protocol instructions, generates training samples based on the execution results, and performs incremental training on the adaptation rule engine based on the training samples to fine-tune the parameters of the adaptation rule engine.

3. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The adaptation rule engine adopts a hybrid architecture of hierarchical attention network and differentiable rule decision tree; the step of inputting the context feature vector into the adaptation rule engine to generate an adaptation scheme includes: The hierarchical attention network sequentially performs intra-dimensional self-attention interaction, cross-dimensional cross-attention calculation with protocol type as the query vector, and gated aggregation on the context feature vector to output a policy latent vector; the policy latent vector is an intermediate representation of the context feature vector after being encoded by the hierarchical attention network and used as input to the differentiable rule decision tree. Based on the policy latent vector, the differentiable rule decision tree outputs the activation weights of each rule in the predefined rule template library and the offsets of continuous parameters in each rule; the activation weights represent the strength of the adoption of the corresponding rule in the current context; the offsets are used to adjust the continuous parameters based on the preset values ​​of the rules. The activation weight and the offset of the continuous parameters of each rule are applied to the rule template corresponding to the rule to obtain multiple candidate rule suggestions; each candidate rule suggestion includes the suggested values ​​of the adaptation parameters. The optimal rule suggestion is selected from the multiple candidate rule suggestions to generate the adaptation scheme.

4. The cross-protocol instruction adaptation and distribution method according to claim 3, characterized in that, The process of sequentially performing intra-dimensional self-attention interaction, cross-dimensional cross-attention calculation with protocol type as the query vector, and gating aggregation on the context feature vector through the hierarchical attention network to output a policy latent vector includes: The context feature vectors are grouped into four-dimensional feature sub-vectors, resulting in protocol type feature sub-vectors, target device capability feature sub-vectors, network status feature sub-vectors, and historical execution data feature sub-vectors. Within each group of sub-vectors, multi-head self-attention is used to capture the correlation between different sub-features within the same dimension, resulting in sub-vectors enhanced by in-dimensional self-attention. Each group of sub-vectors includes multiple sub-features. The sub-features of the protocol type feature sub-vector include at least one of the following: one-hot encoded bits for each protocol type, protocol version number, and extended flag bits. The sub-features of the target device capability feature sub-vector include at least one of the following: protocol support bits, cipher suite support bits, and continuous capability normalized values. The sub-features of the network status feature sub-vector include at least one of the following: round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor. The sub-features of the historical execution data feature sub-vector include at least one of the following: weighted success rate and statistical values ​​of various failure causes. Using the protocol type feature sub-vector as the query matrix, the key matrix and value matrix are obtained by concatenating the target device capability feature sub-vector, network state feature sub-vector, and historical execution data feature sub-vector after in-dimensional self-attention enhancement for each group, and cross-attention is calculated. The cross-attention is used to select the feature component most relevant to the protocol type feature sub-vector from the target device capability feature sub-vector, the network state feature sub-vector, and the historical execution data feature sub-vector as the output. The output corresponding to the cross attention is added to the context feature vector through a residual connection to obtain the residual connection feature. The residual connection feature is then input into the gating unit of the hierarchical attention network for feature selection, and the policy latent vector is output.

5. The cross-protocol instruction adaptation and distribution method according to claim 3, characterized in that, The rule template library includes multiple rules, each rule contains a rule triggering condition and a rule action, the rule action includes a suggested value for at least one adaptation parameter, and each rule corresponds to a confidence score; The activation weight and continuous parameter offset of each rule are applied to the rule template corresponding to that rule to obtain multiple candidate rule suggestions, including: Based on the activation weight and the confidence score, the adoption strength of each rule is determined; the adoption strength is used to represent the overall recommendation strength of the corresponding rule in the current context. For each rule, the suggested value of each adaptation parameter in the rule action is added to the corresponding offset to obtain the corrected values ​​of each adaptation parameter. The adoption strength is used as the confidence weight of the adaptation parameter value. Multiple candidate rule suggestions are obtained by combining the corrected values ​​of each adaptation parameter and the confidence weight of the adaptation parameter values.

6. The cross-protocol instruction adaptation and distribution method according to claim 3, characterized in that, The adaptation scheme consists of multiple adaptation parameters, which are various independent configuration items in the adaptation scheme used to describe the instruction conversion format and transmission strategy, including at least one of the following: target protocol type, QoS level, payload mapping rules, authentication method, number of retransmissions, and timeout time. The step of selecting the optimal rule suggestion from the multiple candidate rule suggestions to generate the adaptation scheme includes: The first output value of the adaptation parameter is obtained by categorizing and aggregating all suggested values ​​from the multiple candidate rule suggestions according to the parameter data type: For the security-related parameters in the adaptation parameters, the sum of the adoption strengths of candidate rule suggestions that recommend enabling security mechanisms is used as the cumulative weight for enabling security, and the sum of the adoption strengths of candidate rule suggestions that recommend disabling security mechanisms is used as the cumulative weight for disabling security. The cumulative weight for enabling security is compared with the cumulative weight for disabling security, and the suggested value for the security-related parameter in the candidate rule suggestions corresponding to the cumulative weight is taken as the second output value of the security-related parameter. The adaptation parameters include security-related parameters, which are adaptation parameters that affect communication security, including authentication methods. When the weighted vote difference of multiple suggested values ​​after classification and aggregation is less than a preset vote threshold, the dimensional feature value that has a mapping relationship with the adaptation parameter in the four-dimensional features is used as the adjudication basis, and the suggested value with a higher matching degree with the dimensional feature value is determined as the third output value of the adaptation parameter from the multiple suggested values. The first output value, the second output value, and the third output value are merged, and the combination relationship between each adaptation parameter is checked for consistency. The values ​​of parameters that violate the predefined consistency constraints are corrected to meet the consistency constraints. The adaptation scheme is generated based on the adaptation parameters after consistency verification and correction.

7. The cross-protocol instruction adaptation and distribution method according to claim 6, characterized in that, The data types include discrete enumeration types and numeric types; the step of classifying and aggregating all suggested values ​​from the multiple candidate rule suggestions according to the parameter data type to obtain the first output value of the adaptation parameter includes: If the adaptation parameter is a discrete enumeration type, then for the suggested values ​​of the adaptation parameter in each candidate rule suggestion, a weighted vote is performed using the activation weight of the corresponding rule as the vote, and the suggested value with the highest weighted vote is taken as the first output value of the adaptation parameter. If the adaptation parameter is a numerical type, the sum of the products of the suggested value of the adaptation parameter and the activation weight of the corresponding rule in each candidate rule suggestion is used as a weighted sum value, and the weighted sum value is subject to boundary constraints. The constrained value is then used as the first output value of the adaptation parameter.

8. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The protocol type features include at least one of the following: multidimensional one-hot encoding of the protocol type, normalized value of the protocol version number, and extended flag bits; the target device capability features include static capabilities and dynamic capabilities, wherein the static capabilities include at least one of the following: CPU architecture, memory size, list of available protocols, supported encryption suites, and maximum message fragment length, and the dynamic capabilities include at least one of the following: current remaining battery power, CPU load, and available storage space; the network status features include at least one of the following: round-trip time, packet loss rate, jitter, bandwidth estimation, and network trend factor; the historical execution data features include weighted success rate and failure mode vector, wherein the failure mode vector includes at least one of the following: timeout, protocol rejection, and parameter error; The extraction of four-dimensional features of the target device based on the source protocol instruction stream includes: The source protocol instruction stream is fingerprinted to determine the source protocol type. The multidimensional one-hot encoding is generated based on the source protocol type. The normalized value of the protocol version number is parsed from the protocol header of the source protocol instruction stream. The extended flag bits are parsed from the protocol header of the source protocol instruction stream. The target device identifier in the source protocol instruction stream is used to query the device capability database, and the static and dynamic capabilities of the target device are read. Based on the static and dynamic capabilities, the capability characteristics of the target device are obtained. Based on the target device identifier or target device address in the source protocol instruction stream, a probe message is sent to the target device to obtain the round-trip time. The packet loss rate and jitter are obtained by listening to the transport layer retransmission event and communication quality feedback report of the target device. The bandwidth estimate is obtained by using a sliding window message pair algorithm. The slope of the packet loss rate change in the past time window is obtained to determine the network trend factor. Based on the target device identifier in the source protocol instruction stream, the historical execution database is queried, and the historical execution records of the target device within a preset time range are read. Based on the historical execution records, the weighted success rate is determined using an exponential decay time window. The distribution of reasons for the most recent preset number of failures is statistically analyzed, and the failure mode vector is generated.

9. The cross-protocol instruction adaptation and distribution method according to claim 8, characterized in that, The protocol fingerprinting includes parallel execution port number identification, first byte feature identification, and finite state machine deep parsing; the process of determining the source protocol type by performing protocol fingerprinting on the source protocol instruction stream includes: The source protocol instruction stream is subjected to parallel execution of port number identification, first byte feature identification, and finite state machine deep parsing, respectively obtaining port number identification results and corresponding port confidence, first byte feature identification results and corresponding first byte confidence, and finite state machine deep parsing results and corresponding structure matching confidence. If the result of the finite state machine deep parsing is to complete the full syntax structure verification of a certain protocol, then the protocol type identified by the finite state machine shall be used as the protocol type of the source protocol instruction stream; If the finite state machine deep parsing result is that the complete syntax structure verification cannot be completed, then the port number identification result and the first byte feature identification result are used as candidate protocols. The port confidence, the first byte confidence and the structure matching confidence are multiplied by their respective preset weights and summed to obtain the weighted confidence of each candidate protocol. The candidate protocol with the highest weighted confidence is taken as the protocol type of the source protocol instruction stream.

10. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The weighted fusion of the four-dimensional features to generate a context feature vector includes: The protocol type feature, the target device capability feature, the network status feature, and the historical execution data feature are respectively input into the first fully connected layer corresponding to each dimension, and the original features of each dimension are respectively mapped into sub-vectors of fixed dimensions; The concatenated subvectors are then input into a multilayer perceptron, which outputs the weights of each dimension. The sub-vectors are multiplied by their respective weights and then concatenated. The concatenated vector is then reduced to a preset dimension to generate the context feature vector.

11. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The step of determining the instruction issuance time for each target device based on the current load statistics includes: The equivalent load rate of each target device is determined based on the number of issued but unconfirmed instructions, the number of confirmed instructions still waiting in the queue, the number of instructions being executed, and the corresponding preset weights. Obtain the current latency value of each target device; the latency value is used to characterize the current network communication latency of the target device. If the equivalent load rate of the target device is less than or equal to a preset load rate threshold and the current latency value is less than or equal to a preset latency threshold, then the target device is determined to be an available device, and the instruction issuance time of the target device is set to the current time. If the equivalent load rate of the target device is greater than the preset load rate threshold or the delay is greater than the preset delay threshold, the target device is marked as an unavailable device, and the instruction issuance time of the target device is postponed until the first available time after the equivalent load rate of the target device recovers to below the preset load rate threshold and the delay recovers to below the preset delay threshold.

12. The cross-protocol instruction adaptation and distribution method according to claim 1, characterized in that, The step of inputting the context feature vector into the adaptation rule engine to generate an adaptation scheme further includes: Determine the Mahalanobis distance between the context feature vector and the feature distribution of the training set; If the Mahalanobis distance does not exceed the preset threshold, the context feature vector is input into the adaptation rule engine to generate an adaptation scheme. If the Mahalanobis distance exceeds the preset threshold, then retrieve the N historical samples most similar to the context feature vector from the historical sample library. Each historical sample contains a historical context feature vector and a corresponding historical adaptation scheme, where N is a positive integer. The historical adaptation scheme corresponding to each of the N historical samples is taken as a candidate scheme. The number of times each candidate scheme appears in the N historical samples is counted as the number of votes. The candidate scheme with the highest number of votes is taken as the temporary adaptation scheme, and the temporary adaptation scheme is taken as the adaptation scheme.

13. The cross-protocol instruction adaptation and distribution method according to claim 12, characterized in that, The step of retrieving the N historical samples most similar to the context feature vector from the historical sample database includes: Determine the mixed distance between the context feature vector and each historical sample in the historical sample library; the mixed distance is obtained by weighted summation based on protocol type distance, target device capability distance, network status distance, and historical execution data distance. The historical samples in the historical sample database are sorted according to the mixed distance, and the N historical samples with the smallest distance are selected.

14. The cross-protocol instruction adaptation and distribution method according to claim 13, characterized in that, Determining the mixing distance between the context feature vector and each historical sample in the historical sample database includes: The multidimensional one-hot encoding of the protocol type feature in the context feature vector is compared bit by bit with the multidimensional one-hot encoding of the protocol type feature in the historical samples. The number of different bits is counted to obtain the protocol type distance. The difference between the target device capability feature sub-vector in the context feature vector and the target device capability feature sub-vector in the historical samples is calculated item by item according to each dimension. Based on the confidence of each difference and the corresponding dimension in the target device capability feature sub-vector, the target device capability distance is determined. The network state feature subvector in the current context feature vector is compared with the network state feature subvector in the historical samples by calculating the difference item by item in each dimension. The network state distance is determined based on each difference and the global standard deviation of the corresponding dimension of the network state feature. The difference between the historical execution data feature subvector in the current context feature vector and the historical execution data feature subvector in the historical samples is calculated item by item according to each dimension. The distance of the historical execution data is determined based on each difference and the global standard deviation of the corresponding dimension of the historical execution data feature.

15. A cross-protocol instruction adaptation and distribution device, characterized in that, The device includes: The feature vector generation module is used to receive a source protocol instruction stream, extract four-dimensional features of the target device based on the source protocol instruction stream, and perform weighted fusion of the four-dimensional features to generate a context feature vector; the source protocol instruction stream contains multiple instructions pointing to different target devices; the four-dimensional features include protocol type features, target device capability features, network status features, and historical execution data features; An adaptation scheme generation module is used to input the context feature vector into an adaptation rule engine to generate an adaptation scheme; the adaptation scheme is used to indicate the protocol format and transmission strategy for converting the source protocol instruction into the target protocol instruction; The protocol instruction conversion module is used to convert the source protocol instruction into the target protocol instruction according to the adaptation scheme. The instruction issuance time determination module is used to collect the current load statistics of each target device and determine the instruction issuance time of each target device based on the current load statistics; the load statistics include the number of issued but not yet confirmed instructions, the number of confirmed instructions still waiting in the queue, and the number of instructions being executed. The target instruction delivery module is used to deliver the target protocol instruction to the target device at the instruction delivery time of each target device.

16. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the cross-protocol instruction adaptation and distribution method as described in any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the cross-protocol instruction adaptation and distribution method as described in any one of claims 1-14.

Images