Device protocol adaptive analysis and instruction scheduling method of intelligent central control system

Abstract

The invention relates to the technical field of computers, and discloses an equipment protocol adaptive analysis and instruction scheduling method for an intelligent central control system, and the method comprises the steps: obtaining an original communication data flow of heterogeneous equipment, and extracting a protocol feature fingerprint to recognize a protocol type; calling a corresponding pluggable protocol parser to generate a standardized instruction object; analyzing instruction semantics and dynamically calculating priorities in combination with a system load; and performing non-blocking scheduling and execution monitoring on the instruction based on a resource token bucket mechanism. The system comprises a data acquisition module, a protocol identification module, a self-adaptive analysis module, a semantic analysis module, a priority calculation module, an instruction sorting module, a token management module, a scheduling execution module, an execution monitoring module and a response generation module. According to the method, through protocol self-learning, dynamic priority quantification and multi-dimensional resource isolation scheduling, the response certainty, expansibility and operation stability of the system in a high-concurrency scene are remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a method for adaptive parsing of device protocols and instruction scheduling in intelligent central control systems. Background Technology

[0002] With the widespread application of intelligent central control systems in smart homes, industrial IoT, and smart buildings, these systems need to simultaneously interface with a diverse range of terminal devices using heterogeneous protocols, such as lighting, air conditioning, security, and audio / video equipment. These devices often employ different communication protocols (e.g., Zigbee, Modbus, KNX, MQTT), and their control commands frequently interact under high concurrency scenarios. Traditional central control systems typically rely on static protocol mapping tables and fixed priority queues for command parsing and scheduling. Their scheduling logic is based on preset rules and lacks the ability to perceive and respond to dynamic operating environments. When multiple user operations or automated scenarios trigger a large number of concurrent commands, system resources (such as CPU, network bandwidth, and device channels) are easily congested due to disordered competition, leading to delays in critical command responses, accumulation of non-critical commands, and even system-level blocking, severely impacting user experience and system reliability.

[0003] The core challenge of intelligent central control systems lies in achieving an efficient, conflict-free, and adaptive instruction scheduling mechanism in complex environments with multiple protocols coexisting and multiple instructions running concurrently. This mechanism not only needs to accurately parse the semantics of instructions from different protocol stacks but also needs to dynamically adjust the scheduling strategy based on the real-time system status to balance the conflict between response speed, resource utilization, and task urgency. Existing scheduling methods mostly employ classic algorithms such as round-robin, priority preemption, or shortest job first. While these can alleviate resource contention to some extent, their static decision-making models struggle to cope with real-world scenarios such as sudden changes in device load, dynamic network topology reconfiguration, or changes in the urgency of user intent, failing to fundamentally avoid problems such as deadlock, livelock, or local resource exhaustion.

[0004] Machine learning models are introduced to predict device response time or optimize scheduling sequences, but their training relies on a large amount of historical data, limiting their generalization ability, and the inference process itself consumes additional computational resources. Other solutions use centralized arbitrators to coordinate instruction conflicts, but these become performance bottlenecks under high concurrency and pose significant single-point failure risks. More importantly, current methods generally treat instructions as passive task units, ignoring their inherent initiative and interactivity, and fail to construct a scheduling scheme that can autonomously negotiate, dynamically play games, and achieve a globally stable state. Summary of the Invention

[0005] This invention provides a device protocol adaptive parsing and instruction scheduling method for intelligent central control systems, aiming to solve the response delay and system blocking problems caused by resource contention when multiple instructions are concurrent. This method achieves real-time parsing, conflict prediction, and non-blocking distribution of instructions from heterogeneous devices by constructing a dynamic identification mechanism based on device communication protocol characteristics, an instruction priority quantification model, and a resource isolation scheduling architecture. This ensures the deterministic response capability and system stability of the intelligent central control system in high-concurrency scenarios.

[0006] This invention provides a method for adaptive parsing of device protocols and instruction scheduling in an intelligent central control system, comprising: Acquire raw communication data streams from multiple heterogeneous terminal devices; The original communication data stream is subjected to protocol feature fingerprint extraction to generate a device protocol type identifier; Based on the device protocol type identifier, the corresponding protocol parser is invoked to perform structured parsing of the original communication data stream to obtain a standardized instruction object; Perform instruction semantic analysis on the standardized instruction object to extract instruction operation type, target device address, resource usage type and expected execution time; Based on the preset instruction priority quantification rules, combined with the current system load status, the urgency of instruction operation type and the service level of the target device, the dynamic priority value of each standardized instruction is calculated. All standardized instructions are arranged in descending order of dynamic priority value to form a queue of instructions to be scheduled; In the instruction execution engine, an independent resource token bucket is allocated for each type of resource usage, and each resource token bucket generates execution tokens at a fixed rate. When the first instruction in the queue of instructions to be scheduled requests a specific resource, if there is an available execution token in the corresponding resource token bucket, an execution token is consumed and the execution process of the instruction is started; otherwise, the instruction is moved to the resource waiting sub-queue. During instruction execution, the actual resource usage time is monitored in real time. If it exceeds the preset threshold, the instruction is forcibly terminated and the resources it occupies are released. After the command is executed, a structured response message is returned to the source device, and the system resource status table is updated.

[0007] As one embodiment of the present invention, the protocol feature fingerprint extraction specifically includes: performing joint feature encoding on the preamble length, frame start character byte sequence, check algorithm type, data field length distribution, and end character pattern of the original communication data stream to generate a 16-dimensional binary feature vector; inputting the feature vector into a pre-trained lightweight decision tree classification model to output a device protocol type identifier, wherein the device protocol type identifier includes, but is not limited to, Modbus RTU, BACnetMS / TP, KNX TP1, Zigbee HA, and proprietary infrared control protocols.

[0008] As one embodiment of the present invention, the protocol parser is a pluggable modular component. Each protocol parser encapsulates complete frame synchronization logic, field unpacking rules, verification functions, and error recovery strategies. When a new device is connected to the system, if the protocol feature fingerprint matching fails, the protocol learning mode is triggered, the complete communication session sample is recorded, and after the system administrator marks the protocol structure, a new protocol parser is automatically generated and registered in the parser repository.

[0009] As one embodiment of the present invention, the instruction priority quantization rule is defined as follows: the dynamic priority value is equal to the basic priority weight multiplied by the system load correction factor; wherein, the basic priority weight is set according to the instruction operation type, the weight of the emergency stop instruction is 100, the weight of the status query instruction is 10, the weight of the configuration write instruction is 30, and the weight of the periodic polling instruction is 5; the system load correction factor is equal to 1 minus the weighted average of the current CPU utilization and memory occupancy, with weights of 0.6 and 0.4 respectively, and the lower limit of the system load correction factor is 0.2.

[0010] As one embodiment of the present invention, the resource occupancy types include central processing unit computing unit, network communication bandwidth, serial communication port, infrared transmission channel and storage read / write buffer; each type of resource occupancy corresponds to an independent resource token bucket, and the token generation rate is set according to historical instruction execution statistics. For example, the token generation rate of the serial communication port is 20 per second, the infrared transmission channel is 50 per second, and the network communication bandwidth generates tokens in units of 1000 bytes per millisecond.

[0011] In one embodiment of the present invention, the resource waiting sub-queue adopts a first-in-first-out structure and sets a maximum waiting time limit; if the instruction stays in the resource waiting sub-queue for a longer period than the maximum waiting time limit, the instruction is marked as timed out and a resource busy error code is returned to the source device; at the same time, the system records the event for subsequent resource capacity planning.

[0012] As one embodiment of the present invention, the structured response message includes an instruction execution status code, actual execution time, resource release confirmation flag, and optional device feedback data; the response message is returned through the same communication channel as the request instruction, ensuring end-to-end instruction closed loop.

[0013] This invention also provides a device protocol adaptive parsing and command scheduling system for an intelligent central control system, comprising: The raw data acquisition module is used to acquire raw communication data streams from multiple heterogeneous terminal devices; The protocol fingerprinting module is used to extract protocol feature fingerprints from the original communication data stream and generate a device protocol type identifier. The protocol adaptive parsing module is used to call the corresponding protocol parser to perform structured parsing of the original communication data stream based on the device protocol type identifier, and obtain standardized instruction objects; The instruction semantic analysis module is used to perform instruction semantic analysis on the standardized instruction object and extract the instruction operation type, target device address, resource usage type and expected execution time. The dynamic priority calculation module is used to calculate the dynamic priority value of each standardized instruction based on preset instruction priority quantification rules, combined with the current system load status, the urgency of the instruction operation type, and the service level of the target device. The instruction sorting module is used to sort all standardized instructions in descending order according to their dynamic priority values ​​to form a queue of instructions to be scheduled. The resource token management module is used to allocate independent resource token buckets for each type of resource usage and generate execution tokens at a fixed rate. The instruction scheduling and execution module is used to determine whether there is an available execution token in the corresponding resource token bucket when the first instruction in the instruction queue requests a specific resource. If there is, the token is consumed and execution is started; otherwise, the instruction is moved to the resource waiting sub-queue. The execution monitoring module is used to monitor the actual resource usage time in real time during instruction execution. If the preset threshold is exceeded, the instruction will be forcibly terminated and the resources will be released. The response generation module is used to return a structured response message to the source device and update the system resource status table after the instruction is executed.

[0014] As one embodiment of the present invention, the protocol fingerprinting module has a built-in feature extraction unit. This unit performs joint feature encoding on the preamble length, frame start character byte sequence, verification algorithm type, data field length distribution and end character pattern of the original communication data stream to generate a 16-dimensional binary feature vector, and inputs it into the lightweight decision tree classification model to output the device protocol type identifier.

[0015] As one embodiment of the present invention, the protocol adaptive parsing module maintains a protocol parser repository. Each protocol parser in the repository is an independently loaded dynamic link library, which includes frame synchronization logic, field unpacking rules, verification functions, and error recovery strategies. When the protocol fingerprinting module cannot match a known protocol, the system enters the protocol learning mode, records complete communication session samples for manual annotation, and then automatically generates a new parser.

[0016] As one embodiment of the present invention, the dynamic priority calculation module has a built-in priority calculation unit. This unit assigns basic priority weights according to the instruction operation type, and calculates the system load correction factor in combination with the CPU utilization and memory usage, and finally outputs the dynamic priority value.

[0017] As one embodiment of the present invention, the resource token management module configures independent token buckets for the central processing unit, network communication bandwidth, serial communication port, infrared transmission channel and storage read / write buffer, and the token generation rate of each token bucket is statically configured according to historical instruction execution statistics or dynamically adjusted by the system administrator.

[0018] In one embodiment of the present invention, the instruction scheduling and execution module maintains multiple resource waiting sub-queues, each sub-queue corresponding to a type of resource, adopts a first-in-first-out structure and sets a maximum waiting time limit, and timed-out instructions are marked as invalid and trigger an error response.

[0019] As one embodiment of the present invention, the structured response message constructed by the response generation module includes a 4-bit status code, execution time in microseconds, resource release confirmation bit, and variable-length device feedback data segment, which is returned through the original request channel to ensure the integrity and traceability of instruction interaction.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention achieves rapid adaptation to unknown or newly added device protocols through protocol feature fingerprint recognition and pluggable parser mechanism, avoiding the scalability bottleneck caused by protocol fixation in traditional central control systems; by introducing an instruction priority quantification model based on dynamic system load correction, high-urgency instructions can still obtain priority execution rights under high load, effectively suppressing the response delay of critical instructions. 2. By establishing independent token bucket scheduling mechanisms for different resource types, the originally coupled resource competition is decoupled into multiple orthogonal resource channels, fundamentally eliminating global system blocking caused by contention for a single resource. 3. By executing timeout forced termination and automatic resource reclamation mechanisms, inefficient or abnormal instructions are prevented from occupying system resources for a long time, ensuring the stability and availability of the system under continuous high concurrency pressure. 4. Without increasing hardware costs, the overall solution significantly improves the concurrent processing capability, response determinism, and operational robustness of the intelligent central control system in complex multi-device environments. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the overall technical solution architecture of the present invention; Figure 2 This is a schematic diagram of the core principle framework of protocol feature fingerprint recognition and dynamic priority quantization in this invention; Figure 3 This is a flowchart illustrating the protocol feature extraction and adaptive parsing logic of the original communication data stream in this invention. Figure 4 This is a flowchart illustrating the semantic analysis, priority calculation, and queue sorting logic of standardized instructions in this invention. Figure 5 This is a flowchart illustrating the isolation scheduling and execution control logic based on multi-type resource token buckets in this invention. Figure 6 This is a schematic diagram of the multi-level interaction relationship and data flow between the intelligent central control system and heterogeneous terminal devices in this invention. Detailed Implementation

[0022] Please refer to the attached document. Figure 1 To be continued Figure 6 This invention provides a device protocol adaptive parsing and instruction scheduling method for intelligent central control systems, aiming to solve the response delay and system blocking problems caused by resource contention in multi-instruction concurrent scenarios. This method achieves real-time parsing, conflict prediction, and non-blocking distribution of instructions from heterogeneous devices by constructing a dynamic identification mechanism based on device communication protocol characteristics, an instruction priority quantification model, and a resource isolation scheduling architecture. This ensures the deterministic response capability and system stability of the intelligent central control system in high-concurrency scenarios.

[0023] In this embodiment, the method includes the following steps: acquiring raw communication data streams from multiple heterogeneous terminal devices; extracting protocol feature fingerprints from the raw communication data streams to generate device protocol type identifiers; based on the device protocol type identifiers, calling the corresponding protocol parser to perform structured parsing of the raw communication data streams to obtain standardized instruction objects; performing instruction semantic analysis on the standardized instruction objects to extract instruction operation type, target device address, resource occupancy type, and expected execution time; calculating the dynamic priority value of each standardized instruction according to preset instruction priority quantification rules, combined with the current system load status, the urgency of instruction operation type, and the service level of the target device; and then... Standardized instructions are arranged in descending order of dynamic priority values ​​to form a queue of instructions to be scheduled. In the instruction execution engine, an independent resource token bucket is allocated for each type of resource occupancy, and each resource token bucket generates execution tokens at a fixed rate. When the first instruction in the queue of instructions to be scheduled requests a specific resource, if there is an available execution token in the corresponding resource token bucket, an execution token is consumed and the execution process of the instruction is started; otherwise, the instruction is moved to the resource waiting sub-queue. During the execution of the instruction, its actual resource occupancy time is monitored in real time. If it exceeds a preset threshold, the instruction is forcibly terminated and the resources it occupies are released. After the instruction is executed, a structured response message is returned to the source device, and the system resource status table is updated.

[0024] Step S1 involves acquiring raw communication data streams from multiple heterogeneous terminal devices. This step is executed by the raw data acquisition module, deployed at the input interface layer of the intelligent central control system, directly connecting to various physical communication channels, including but not limited to serial communication ports, infrared receivers, Ethernet controllers, wireless RF transceivers, and power line carrier modems. The raw communication data stream is continuously input in byte sequence form, with its timestamp synchronized by the system's high-precision clock to ensure timing consistency in subsequent processing. Each communication channel is configured with an independent data buffer, employing a circular queue structure with a maximum capacity of 64 kilobytes. When the buffer write pointer catches up with the read pointer and has not been consumed, an overflow alarm is triggered, and the oldest data frame is discarded to prevent memory exhaustion. The data acquisition process operates in non-blocking mode, capturing newly arriving data packets through interrupt-driven or polling mechanisms to ensure timely response to sudden high-frequency communication events.

[0025] Step S2 involves extracting protocol feature fingerprints from the original communication data stream to generate a device protocol type identifier. This step is executed by the protocol fingerprint recognition module, which internally includes a feature extraction unit and a classification decision unit. The feature extraction unit performs joint feature encoding on the preamble length, frame start character byte sequence, checksum algorithm type, data field length distribution, and end character pattern of the original communication data stream. The preamble length is counted starting from the first valid bit after a series of idle bits until the start-of-frame (FOB) character appears, typically ranging from 0 to 25 bytes. The FOB character byte sequence is defined as a fixed length of 1 to 4 bytes; for example, the Modbus RTU protocol uses the device address as an implicit start, while the KNX TP1 protocol uses hexadecimal 0x10 as an explicit start. The checksum algorithm type is determined by analyzing the mathematical characteristics of the frame end checksum field, including parity check, cumulative check, 8-bit cyclic redundancy check, and 16-bit cyclic redundancy check. The data field length distribution is inferred by parsing the length field or based on the fixed frame structure, recording the minimum, maximum, and average lengths. The end-of-frame pattern identifies the frame end delimiter, such as a carriage return / line feed, specific control characters, or timeout silence intervals. These five types of features are normalized and binarized, then concatenated into a 16-dimensional binary feature vector. The input vector is a pre-trained lightweight decision tree classification model, which is trained offline using historical device communication samples. Node splitting follows the principle of maximizing information gain, with a depth not exceeding eight layers and an inference latency of less than 50 microseconds. The output is a device protocol type identifier, including known categories such as Modbus RTU, BACnet MS / TP, KNXTP1, Zigbee HA, and proprietary infrared control protocols. If the confidence score of all leaf nodes is below a preset threshold of 0.9, the protocol is determined to be unknown.

[0026] Step S3 involves calling the corresponding protocol parser based on the device protocol type identifier to perform structured parsing of the original communication data stream, obtaining standardized instruction objects. This step is executed by the protocol adaptive parsing module, which maintains a protocol parser repository. Each protocol parser in the repository is encapsulated as an independently loaded dynamic link library, containing complete frame synchronization logic, field unpacking rules, verification functions, and error recovery strategies. The frame synchronization logic is responsible for accurately segmenting complete data frames from the continuous byte stream, using a sliding window mechanism to match the start character and length field, tolerating noise interference of up to 3 bytes. The field unpacking rules map the byte sequence to structured fields, such as function codes, register addresses, and data values, according to the protocol specification. The verification function recalculates the checksum and compares it with the frame's internal checksum field; if they do not match, the frame is discarded and an error count is recorded. Error recovery strategies include retransmission requests, status rollback, or skipping abnormal frames. When the output of step S2 is a known protocol type identifier, the system loads the corresponding parser from the repository and performs parsing. If it is an unknown protocol, the protocol learning mode is triggered: the system records complete communication session samples, including bidirectional data streams of at least 10 complete interaction cycles, and marks them with timestamps and channel information; the system administrator annotates the semantics of each field and the frame structure through a graphical interface, and the system automatically generates new protocol parser code based on this, compiles it, registers it in the parser repository, and updates the training set of the decision tree model. Standardized instruction objects are represented using a unified data structure, including a unique instruction identifier, source device address, target device address, operation type code, parameter list, expected execution duration, and protocol context reference.

[0027] Step S4 involves performing instruction semantic analysis on the standardized instruction object to extract the instruction operation type, target device address, resource usage type, and expected execution time. This step is executed by the instruction semantic analysis module, which uses a built-in semantic mapping table to convert operation type codes into high-level semantic tags, such as emergency stop, status query, configuration write, and periodic polling. The target device address is converted into an internal device handle via the address resolution service, and associated with device metadata, including device type, service capabilities, resource requirement templates, and service level. The resource usage type is determined jointly based on the operation semantics and device type: for example, sending a configuration write instruction to a serial port device requires the use of the serial communication port and the central processing unit; infrared remote control instructions require the use of the infrared transmission channel; and large-capacity firmware upgrades require the use of network communication bandwidth and storage read / write buffers. The expected execution time is derived from historical statistics of similar instruction executions, using the 95th percentile value as a conservative estimate. If no historical data is available, a preset default value is used, such as 10 milliseconds for status query, 50 milliseconds for configuration write, and 5 milliseconds for emergency stop.

[0028] Step S5 calculates the dynamic priority value of each standardized instruction based on preset instruction priority quantization rules, combined with the current system load status, the urgency of the instruction operation type, and the service level of the target device. This step is executed by the dynamic priority calculation module. The instruction priority quantization rule is defined as follows: the dynamic priority value equals the base priority weight multiplied by the system load correction factor. The base priority weight is set according to the instruction operation type: emergency stop instruction weight is 100, status query instruction weight is 10, configuration write instruction weight is 30, and periodic polling instruction weight is 5. The service level of the target device is used as a weight adjustment factor, divided into 4 levels: critical device × 1.5, important device × 1.2, ordinary device × 1, and low priority device × 0.8. The system load correction factor equals 1 minus the weighted average of the current CPU utilization and memory usage. The CPU utilization weight is 0.6, the memory usage weight is 0.4, and the lower limit of the system load correction factor is 0.2 to prevent the priority from completely failing under extremely high load. CPU utilization is calculated by sampling the system idle task runtime, and memory usage is obtained by querying the kernel memory manager. The dynamic priority value is a floating-point number, with 3 decimal places retained for subsequent precise sorting.

[0029] Step S6 involves sorting all standardized instructions in descending order of their dynamic priority values ​​to form a queue of instructions to be scheduled. This step is executed by the instruction sorting module. The queue of instructions to be scheduled is implemented using a balanced binary search tree structure, with dynamic priority values ​​as keys, supporting insertion, deletion, and sequential traversal operations, with a time complexity of logarithmic order. When a new instruction completes step S5, it is immediately inserted into the queue; when an instruction is executed or times out, it is removed from the queue. The queue has a maximum capacity of 1000 instructions; if this limit is exceeded, the lowest priority instruction is discarded and an alarm is recorded. The head of the queue always points to the highest priority instruction, allowing the scheduling engine to access it in real time.

[0030] Step S7 involves allocating independent resource token buckets for each resource occupancy type within the instruction execution engine. Each resource token bucket generates execution tokens at a fixed rate. This step is executed by the resource token management module. Resource occupancy types include CPU computing units, network communication bandwidth, serial communication ports, infrared transmission channels, and storage read / write buffers. Each resource type corresponds to an independent token bucket, with the bucket capacity equal to the token generation rate multiplied by the maximum burst factor, which is set to 2. The token generation rate is statically configured based on historical instruction execution statistics: the serial communication port generates 20 tokens per second, corresponding to a minimum interval of 50 milliseconds; the infrared transmission channel generates 50 tokens per second, corresponding to a minimum interval of 20 milliseconds; network communication bandwidth generates tokens at a rate of 1000 bytes per millisecond, or 1 million bytes per second; CPU computing units generate one computing unit token per millisecond, corresponding to a kilohertz scheduling granularity; and storage read / write buffers generate one token every 10 milliseconds. Token generation is driven by a high-precision timer with an error of less than 1 microsecond. The token bucket status is updated in real time, including the current number of tokens, the last generation time, and the cumulative total number of tokens generated.

[0031] Step S8 involves the first instruction in the queue of instructions requesting a specific resource. If an available execution token exists in the corresponding resource token bucket, an execution token is consumed, and the execution process of the instruction is initiated. Otherwise, the instruction is moved to the resource waiting sub-queue. This step is performed by the instruction scheduling and execution module. The scheduling engine polls the head of the queue of instructions at a fixed interval of 1 millisecond. For the first instruction, its required resource set is parsed, and the corresponding token buckets are checked one by one. If all required resources have at least one token, one token is atomically deducted from each bucket, and the instruction is transferred to the execution pipeline. If any resource token is insufficient, the instruction is removed from the queue of instructions and added to the resource waiting sub-queue of the corresponding resource. Each resource waiting sub-queue adopts a first-in, first-out (FIFO) structure, is maintained independently, and has a maximum waiting time limit of 2 seconds. When a new token is added to a resource token bucket, it is immediately checked whether the instructions at the head of its waiting sub-queue meet all resource requirements. If they do, an execution token is deducted, and execution is initiated.

[0032] Step S9 involves real-time monitoring of the actual resource usage time during instruction execution. If the usage exceeds a preset threshold, the instruction is forcibly terminated and its occupied resources are released. This step is performed by the execution monitoring module. Each executing instruction is associated with a watchdog timer, initially set to twice the expected execution time extracted in step S4, with an upper limit of 5 seconds. The timer is implemented using a hardware counter with microsecond precision. If the instruction is not completed before the timer expires, a timeout interrupt is triggered. The execution monitoring module immediately terminates the instruction's execution thread, rolls back its modified system state, releases all resource tokens it occupies (by returning tokens to the corresponding token bucket), and marks the instruction status as execution timeout. Simultaneously, a timeout event log is recorded, including the instruction identifier, target device, resource type, and actual execution time, for subsequent performance analysis and resource planning.

[0033] Step S10 involves returning a structured response message to the source device and updating the system resource status table after the instruction execution is complete. This step is performed by the response generation module. The structured response message includes a 4-bit status code (zero indicates success, non-zero indicates various errors), the actual execution time (in microseconds), a resource release confirmation flag (Boolean value), and an optional device feedback data segment (variable length). The response message is returned through the same communication channel as the request instruction, ensuring end-to-end instruction closure. The system resource status table records the current utilization rate, average waiting time, timeout rate, and token bucket fill rate of various resources, used for calculating the system load correction factor in step S5 and for providing token rate dynamic adjustment suggestions in step S7.

[0034] In this embodiment, the entire method flow forms a closed-loop control, with the end-to-end latency from data acquisition to response return being less than 100 milliseconds under normal load, and deterministic responses to critical instructions still guaranteed even under high concurrency peaks. The protocol adaptive mechanism supports hot-swappable expansion, allowing integration of new device protocols without restarting the system. The resource token bucket mechanism decouples the originally coupled resource contention into multiple positive traffic channels, avoiding system-level blocking caused by global locks. The dynamic priority model ensures that high-urgency instructions still have execution opportunities under high load, improving system service quality. The execution timeout forced termination mechanism prevents abnormal instructions from occupying resources for extended periods, ensuring long-term system stability.

[0035] As a necessary support for the above methods, this embodiment also discloses a device protocol adaptive parsing and instruction scheduling system for an intelligent central control system. This system includes a raw data acquisition module, a protocol fingerprint recognition module, a protocol adaptive parsing module, an instruction semantic analysis module, a dynamic priority calculation module, an instruction sorting module, a resource token management module, an instruction scheduling and execution module, an execution monitoring module, and a response generation module. Data exchange between modules occurs via message queues and shared memory, employing lock-free programming technology to prevent inter-module communication from becoming a performance bottleneck. The raw data acquisition module is deployed at the system edge, directly interfacing with physical interfaces; the protocol fingerprint recognition module and the protocol adaptive parsing module run on dedicated coprocessors, reducing the burden on the main CPU; the instruction scheduling and execution module and the execution monitoring module run in the real-time operating system kernel mode, ensuring scheduling determinism; the remaining modules run in user mode, interacting with the kernel through system calls. The system resource status table is stored in non-volatile memory, supporting recovery after power failure. The protocol parser repository is managed using a version control system, supporting rollback and canary releases. The entire system architecture supports horizontal scaling; protocol parsing throughput can be increased by adding coprocessor instances, or more resource types can be supported by adding token bucket instances.

[0036] The method and system described in this embodiment work together to solve the problem of response delay and system blocking caused by resource contention when multiple instructions are concurrent, and realize the high concurrency, low latency and high reliability operation of the intelligent central control system in a complex heterogeneous equipment environment.

Claims

1. A method for adaptive parsing of device protocols and instruction scheduling in an intelligent central control system, characterized in that, include: Acquire raw communication data streams from multiple heterogeneous terminal devices; The original communication data stream is subjected to protocol feature fingerprint extraction to generate a device protocol type identifier; Based on the device protocol type identifier, the corresponding protocol parser is invoked to perform structured parsing of the original communication data stream to obtain a standardized instruction object; Perform instruction semantic analysis on the standardized instruction object to extract instruction operation type, target device address, resource usage type and expected execution time; Based on the preset instruction priority quantification rules, combined with the current system load status, the urgency of instruction operation type and the service level of the target device, the dynamic priority value of each standardized instruction is calculated. All standardized instructions are arranged in descending order of dynamic priority value to form a queue of instructions to be scheduled; In the instruction execution engine, an independent resource token bucket is allocated for each type of resource usage, and each resource token bucket generates execution tokens at a fixed rate. When the first instruction in the queue of instructions to be scheduled requests a specific resource, if there is an available execution token in the corresponding resource token bucket, an execution token is consumed and the execution process of the instruction is started; otherwise, the instruction is moved to the resource waiting sub-queue. During instruction execution, the actual resource usage time is monitored in real time. If it exceeds the preset threshold, the instruction is forcibly terminated and the resources it occupies are released. After the command is executed, a structured response message is returned to the source device, and the system resource status table is updated.

2. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 1, characterized in that, The original communication data stream is subjected to protocol feature fingerprint extraction to generate a device protocol type identifier, including: The preamble length, frame start character byte sequence, check algorithm type, data field length distribution, and end character pattern of the original communication data stream are jointly feature-encoded to generate a 16-dimensional binary feature vector. The 16-dimensional binary feature vector is input into a pre-trained lightweight decision tree classification model, which outputs a device protocol type identifier. The device protocol type identifier includes Modbus RTU, BACnet MS / TP, KNX TP1, Zigbee HA, and proprietary infrared control protocols.

3. The device protocol adaptive parsing and instruction scheduling method for the intelligent central control system according to claim 2, characterized in that, Based on the device protocol type identifier, the corresponding protocol parser is invoked to perform structured parsing of the original communication data stream, resulting in standardized instruction objects, including: Load the protocol parser corresponding to the device protocol type identifier from the protocol parser repository. The protocol parser encapsulates frame synchronization logic, field unpacking rules, verification functions, and error recovery strategies. The protocol parser is used to perform frame synchronization, field unpacking, verification, and error recovery on the original communication data stream, and outputs standardized instruction objects.

4. The device protocol adaptive parsing and instruction scheduling method for the intelligent central control system according to claim 3, characterized in that, Perform instruction semantic analysis on the standardized instruction object to extract instruction operation type, target device address, resource usage type, and expected execution time, including: The operation type code is converted into a high-level semantic label through a semantic mapping table. The high-level semantic label includes emergency stop, status query, configuration write and periodic polling. Query device metadata based on the target device address to obtain device type, service capabilities, resource requirement template and service level; Resource occupancy type is determined by combining operation semantic tags and device type. The resource occupancy type includes central processing unit computing unit, network communication bandwidth, serial communication port, infrared transmission channel and storage read / write buffer. The expected execution time is determined based on the 95th percentile of historical execution statistics for similar instructions.

5. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 4, characterized in that, Based on preset instruction priority quantification rules, and considering the current system load status, the urgency of the instruction operation type, and the service level of the target device, the dynamic priority value of each standardized instruction is calculated, including: Set basic priority weights, where the weight of the emergency stop command is 100, the weight of the status query command is 10, the weight of the configuration write command is 30, and the weight of the periodic polling command is 5. The basic priority weights are adjusted according to the service level of the target equipment: critical equipment ×1.5, important equipment ×1.2, ordinary equipment ×1, and low priority equipment ×0.

8. Calculate the system load correction factor, which is equal to 1 minus the weighted average of the current CPU utilization and memory usage. The CPU utilization weight is 0.6, the memory usage weight is 0.4, and the lower limit of the system load correction factor is 0.

2. The adjusted base priority weight is multiplied by the system load correction factor to obtain the dynamic priority value.

6. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 5, characterized in that, All standardized instructions are arranged in descending order of dynamic priority value to form a queue of instructions to be scheduled, including: A balanced binary search tree structure is used to construct a queue of instructions to be scheduled, with dynamic priority values ​​as keys. The newly generated standardized instructions are inserted into the queue of instructions to be scheduled, and the order of the queue is maintained. When an instruction is executed or expires, the instruction is removed from the queue of instructions to be scheduled.

7. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 6, characterized in that, In the instruction execution engine, an independent resource token bucket is allocated for each type of resource usage. Each resource token bucket generates execution tokens at a fixed rate, including: Configure independent resource token buckets for the central processing unit, network communication bandwidth, serial communication port, infrared transmission channel, and storage read / write buffer; Set the token generation rate for each resource token bucket, with the serial communication port at 20 tokens per second, the infrared transmission channel at 50 tokens per second, the network communication bandwidth at 1000 bytes per millisecond, the central processing unit at one token per millisecond, and the storage read / write buffer at one token per 10 milliseconds. The token generation process is driven by a high-precision timer with an error of less than 1 microsecond.

8. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 7, characterized in that, When the first instruction in the pending instruction queue requests a specific resource, if an available execution token exists in the corresponding resource token bucket, an execution token is consumed and the execution process of the instruction is initiated; otherwise, the instruction is moved to the resource waiting sub-queue, including: Poll the head instruction of the pending instruction queue at 1-millisecond intervals; Parse the set of resources required by the instruction and check the number of available tokens in the corresponding resource token bucket one by one; If all required resources have at least one available token, then atomically deduct one token from each bucket and start execution; If any resource token is insufficient, the instruction is moved to the resource waiting sub-queue of the corresponding resource, which adopts a first-in-first-out structure.

9. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 8, characterized in that, During instruction execution, the actual resource usage time is monitored in real time. If it exceeds a preset threshold, the instruction is forcibly terminated and its occupied resources are released, including: Associate a watchdog timer with each executing instruction, with an initial value set to twice the expected execution time and an upper limit of 5 seconds; If the instruction is not completed before the timer expires, a timeout interrupt is triggered, terminating the execution thread; Roll back the modified system state, return the occupied tokens to the corresponding resource token bucket, and mark the instruction status as execution timeout.

10. The device protocol adaptive parsing and instruction scheduling method for an intelligent central control system according to claim 9, characterized in that, After the command is executed, a structured response message is returned to the source device, and the system resource status table is updated, including: Construct a structured response message containing a 4-bit status code, actual execution time, resource release confirmation flag, and optional device feedback data segment; The structured response message is returned via the same communication channel as the request instruction. Update the system resource status table to record the current resource utilization rate, average waiting time, timeout rate, and token bucket fill rate.

Images