Communication processing method of equipment and storage medium

Abstract

The invention discloses a communication processing method of equipment and a storage medium. The communication processing method of the equipment comprises the following steps: establishing a main event loop and an event queue, establishing a communication task for data to be sent by a main controller, and storing the communication task in a task queue according to a task priority; the communication tasks are taken out regularly, asynchronous requests are sent, the taken-out communication tasks are stored in an in-transit task set, and meanwhile an asynchronous timer is started; after an asynchronous request of each communication task is initiated, returning to a main event cycle without waiting for a response result so as to continue to process other events; when other parts send response data, a communication receiving event is generated, and the main event circularly adds a target response into a response set; and when the overtime expiration event or the communication receiving event is triggered, matching the communication task with the response data, if the matching is successful, judging that the communication task is successful, and if the matching is failed, reinserting the communication task into the task queue. The communication process is processed in an event triggering mode, and blocking can be avoided.

Description

Technical Field

[0001] This invention relates to the technical field of industrial control and equipment communication, and in particular to a communication processing method for communication between a main controller of an equipment and peripheral components. Background Technology

[0002] Currently, the communication architecture between the main controller and peripheral components of a device typically employs a blocking polling architecture. The main thread or communication thread continuously polls multiple communication objects (e.g., serial / 485, Ethernet socket, CAN, etc.) using a while loop, and uses system-level select / poll I / O multiplexing interfaces to listen for readable events. Under this architecture, the communication processing flow is typically: call select to wait for several file descriptors (socket / serial port handles) to become readable → read data → parse the protocol → execute business processing → return to select to wait. While this solution is simple to implement, it has the following key drawbacks in scenarios like central air conditioning systems, which involve "multi-tasking, multi-device, and high real-time demands." The reasons and mechanisms for these defects are as follows.

[0003] `select` is a blocking system call. Essentially, it causes a thread to enter a kernel waiting queue, returning only after certain conditions are met: data becomes available, a timeout occurs, or an exception occurs. During the blocking period, the thread cannot execute other logic within the same thread. Even setting a timeout for `select` only means the thread will be awakened at the timeout point; other business events occurring before the timeout cannot be responded to in a timely manner.

[0004] Taking a central air conditioning unit as an example, a central air conditioning unit is usually composed of a main control board, a frequency converter drive board, a sensor acquisition module, an actuator, and a human-machine interface / host computer interface. Each functional unit needs to complete tasks such as reporting operating parameters, issuing control commands, fault diagnosis, and remote operation and maintenance through a communication module.

[0005] In the communication modules of existing central air conditioning units, the common implementation method is also a blocking polling architecture, which leads to the following problems in the central air conditioning unit system.

[0006] The system uses a while loop in conjunction with system-level select calls for communication monitoring. However, the select call blocks the thread, preventing it from responding to other events until a timeout is set. Furthermore, all communication tasks must be processed sequentially; if one task is not completed, subsequent tasks cannot start. Task processing time is linearly related to the number of tasks, resulting in low communication throughput. When the corresponding component in the communication fails to respond, the thread is permanently blocked. For example, if a communication failure occurs, the thread may wait indefinitely during a blocking call, causing the entire system to become unresponsive, scheduled tasks to fail, and ultimately, the system to completely crash.

[0007] Therefore, how to provide a new non-blocking communication task processing method is a technical problem to be solved. Summary of the Invention

[0008] In order to solve the technical problem of the blocking architecture used in the prior art for communication tasks, the present invention proposes a communication processing method and a storage medium for the device.

[0009] The communication processing method for the device proposed in this invention includes: Establish a main event loop and an event queue. The main event loop is in an event waiting state when no events arrive, and retrieves the event from the event queue when an event arrives to trigger the corresponding processing flow. Establish communication tasks for the data to be sent by the device's main controller, and store them in the task queue according to task priority; Communication tasks are periodically retrieved from the task queue in descending order of priority, asynchronous requests are sent to the corresponding components, and the retrieved communication tasks are stored in the in-transit task set. At the same time, the asynchronous timer of the communication task is started to form the corresponding timeout event. After each communication task initiates an asynchronous request, it returns to the main event loop without waiting for a response result to continue processing other events in the event queue. When other components send response data based on the corresponding asynchronous request, a communication receiving event is generated. When the main event loop processes the communication receiving event, it parses the response data and determines whether it is the target response. If it is, it adds it to the response set. When a timeout event or a communication reception event is triggered, the corresponding communication task is matched with the response data in the response set. If the match is successful, the corresponding communication task is determined to have responded successfully, and the communication task is removed from the in-transit task set or updated to the completed status. If the match fails, the communication task is reinserted into the task queue.

[0010] Furthermore, when a timeout event or a communication reception event is triggered, at least one of the following information is recorded or updated in the in-transit task set: the first execution event, the final completion event, whether it was successful, the number of executions, and the response delay time of the corresponding communication task.

[0011] Furthermore, the initial value of the priority of the communication tasks in the task queue is a preset priority; When the execution status of a communication task and / or the load status of the main controller differs from historical data over a recent period, the priority of the communication task is dynamically adjusted according to at least one of the following adjustment strategies: If the execution status of a communication task exceeds the historical execution status within a recent period, its priority should be increased. When the load on the main controller is higher than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold will be reduced. When the load on the main controller is lower than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold is increased.

[0012] Furthermore, the execution status of the communication task includes at least one of the execution time of the communication task and the response delay time; the historical execution status refers to the execution status of the previous communication task.

[0013] Furthermore, the load status of the main controller includes at least one of the following: CPU utilization, memory usage, and task queue length; the historical load status refers to the load status of the main controller in the previous instance.

[0014] In one embodiment, the priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Delay Factor) × (1 + Failure Factor) × (1 - Load Factor); Where: Delay coefficient = (Task delay / Expected delay) × Weighting coefficient; Failure coefficient = Failure rate × Weighting coefficient; The load factor is adjusted by multiplying the system load rate by the weighting factor.

[0015] In another embodiment, the priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Adjustment Factor); Adjustment factor = (Task delay / Expected delay) × a + Failure rate (frequent timeouts) × b - System load rate × c; a, b, and c are weights, all greater than 0 and less than 1.

[0016] Furthermore, the basic priority is the preset priority corresponding to the communication task.

[0017] Furthermore, the equipment includes a central air conditioning system.

[0018] The present invention proposes a computer-readable storage medium storing a computer program thereon, wherein when the computer program is executed by a processor, the processor performs the communication processing method of the device described in any of the above technical solutions.

[0019] In this invention, all transactions handled by the communication module are integrated into the main event loop, eliminating the need for independent thread management. All communication processing is triggered by an event mechanism, and the sending and responding processes are decoupled. This allows the system to remain responsive after sending a request, ready to await new events, rather than blocking while waiting for response data. When a communication event occurs, the system immediately retrieves the task from the event queue and initiates the corresponding processing flow. By introducing event-driven mechanisms, task queues, and timeout management, this invention achieves non-blocking and automated communication, solving problems such as thread blocking, low throughput, and poor system stability caused by traditional polling mechanisms. It not only significantly improves communication efficiency and response speed but, more importantly, possesses self-healing capabilities to cope with communication failures, greatly enhancing the reliability of the equipment in industrial environments. Attached Figure Description

[0020] The present invention will now be described in detail with reference to the embodiments and accompanying drawings, wherein: Figure 1 This is a flowchart of the main event loop processing according to an embodiment of the present invention.

[0021] Figure 2 This is a flowchart of communication task processing according to an embodiment of the present invention.

[0022] Figure 3 This is a flowchart of response data processing according to an embodiment of the present invention.

[0023] Figure 4 This is a flowchart illustrating the matching process between communication tasks and response data according to an embodiment of the present invention.

[0024] Figure 5 This is an overall flowchart of an embodiment of the present invention.

[0025] Figure 6 This is a flowchart of a communication task processing according to an embodiment of the present invention. Detailed Implementation

[0026] To make the technical problems to be solved, the technical solutions, and the beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0027] Therefore, a feature pointed out in this specification is used to describe one feature of one embodiment of the invention, and does not imply that every embodiment of the invention must have the described feature. Furthermore, it should be noted that this specification describes many features. Although certain features may be combined to illustrate possible system designs, these features may also be used in other combinations not explicitly stated. Therefore, unless otherwise stated, the described combinations are not intended to be limiting.

[0028] Since existing devices all use blocking communication architectures, the purpose of this invention is to provide an event-based device communication processing method. This method enables the device's main controller to avoid blocking the execution path during communication by waiting for a response. Instead, it uses event triggering and asynchronous timer mechanisms to achieve asynchronous sending of communication requests, response event processing, timeout retransmission, and queue self-recovery. At the same time, it dynamically adjusts task priorities based on task execution status and main controller load, thereby improving communication throughput and system responsiveness.

[0029] The following describes various embodiments of the present invention, each of which can achieve at least one of the above-mentioned objectives.

[0030] In one embodiment, the communication processing method of the device of the present invention includes the following steps.

[0031] like Figure 1 As shown, a main event loop and an event queue are established. When no events arrive, the main event loop is in an event waiting state, and when an event arrives, it retrieves the event from the event queue to trigger the corresponding processing flow. Establish communication tasks for the data to be sent by the device's main controller, and store them in the task queue according to task priority; like Figure 2 As shown, scheduling events are generated periodically. Based on these events, the main event loop periodically (e.g., at preset time intervals) retrieves communication tasks from the task queue in descending order of task priority, sends asynchronous requests to the corresponding components, and stores the retrieved communication tasks in the in-transit task set. After each communication task initiates an asynchronous request, it returns to the main event loop without waiting for a response, in order to continue processing other events in the event queue.

[0032] While sending the asynchronous request, start the asynchronous timer for the retrieved communication task to generate the corresponding timeout event.

[0033] like Figure 3As shown, when other components send response data based on the corresponding asynchronous request, a communication receive event is generated. When the main event loop processes the communication receive event, it parses the response data and determines whether it is the target response. If it is, it adds it to the response set. The target response here refers to determining whether the receiving object is the main controller or another component. If it is another component, the main controller does not need to process it. If it is the main controller, the main controller puts the response data into the response set.

[0034] In practice, the unique identifier of the target device, such as the address, in the data frame of the received response data can be analyzed to distinguish whether the data is received by the main controller.

[0035] like Figure 4 As shown, when a timeout event or a communication reception event is triggered, the communication task corresponding to the timeout event or the communication reception event is matched with the response data in the response set. If the match is successful, the corresponding communication task is determined to have responded successfully, and the communication task is deleted from the in-transit task set or updated to the completed status. If the match fails, the communication task is reinserted into the task queue.

[0036] In the above technical solution, the main event loop is the unified event scheduling execution path in the main controller, which can be implemented as the main thread, the RTOS main task, or the system scheduling task. When there are no events, it is in a waiting state (e.g., blocking and waiting for message queues / event flags / semaphores). When an event arrives, it retrieves the event, dispatches it for execution, and returns to the waiting state after processing.

[0037] An event queue is a queue structure used to cache system events. Event sources may include asynchronous timers, serial port receive interrupts / driver callbacks, task enqueue actions, system load sampling, etc.

[0038] The task queue is used to cache priority queues or multi-level queue structures for communication tasks to be sent. A task includes at least: target component identifier / address, request data (request frame), task priority, and identification or association information for matching response data.

[0039] The in-transit task set is used to store communication tasks that have been initiated but have not yet received a response, so as to support multiple tasks being in transit at the same time.

[0040] The response set is used to store response data that is "identified as the target response" and can be indexed by associated information for quick matching.

[0041] Asynchronous timers or timeout events are implemented by starting a timer for each in-transit task. Upon timeout, a timeout event is generated and posted to the event queue. When an asynchronous request is initiated based on a communication task, an asynchronous timer is automatically started for each task, and a timeout threshold is set. If no response is received within the preset time, the system automatically determines that the communication has failed. The timeout threshold should be set within a reasonable range, such as around 100ms, to avoid false positives due to normal delays while allowing for timely handling of communication failures. After timeout processing, the system automatically re-inserts the failed task into the queue to resend the request, achieving self-repair of the communication.

[0042] This invention modifies the communication mechanism to an event-based architecture. When a device's peripheral components return data, the device's internal system automatically triggers a message notification. This mechanism replaces the traditional polling method, eliminating the need for the system to actively check the data status. After a communication reception event is triggered, the system immediately initiates a response process, parses the received response data, performs matching, determines whether a match is successful, and processes it accordingly. Because a main event loop is used, a single main thread can handle communication tasks and response data processing promptly. After processing one event, the main thread does not need to wait for a result and can respond to other system events at any time; the entire process requires no blocking or waiting.

[0043] Based on the above embodiments, when a communication task is inserted into the task queue, the insertion position of the communication task is determined according to the current priority of the communication task, and not all communication tasks inserted into the task queue are inserted at the end.

[0044] In a further embodiment, when a timeout event or a communication reception event is triggered, at least one of the following information is recorded or updated in the in-transit task set: the first execution time, the final completion time, whether it was successful, the number of executions, and the response delay time of the corresponding communication task.

[0045] This information can be used to monitor task execution, so as to adjust task priorities in a timely manner and achieve appropriate dynamic priority adjustments.

[0046] In a further embodiment, the initial priority of communication tasks in the task queue is a preset priority. Different devices have different communication data, and the priorities of communication tasks corresponding to different communication data are also different. Taking a central air conditioner as an example, the priority of communication tasks related to motor control is higher than the priority of communication tasks corresponding to temperature and humidity data reading. Those skilled in the art can set the initial priority of the communication tasks of the device as needed.

[0047] When the execution status of communication tasks and / or the load status of the main controller differ from historical data over a recent period, the priority of communication tasks shall be dynamically adjusted according to at least one of the following adjustment strategies: If the execution status of a communication task exceeds the historical execution status within a recent period, its priority should be increased. When the load on the main controller is higher than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold will be reduced. When the load on the main controller is lower than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold is increased.

[0048] For example, if the delay of a communication task is too long, its priority is increased. If there are three communication tasks in the task queue, the priority of the first communication task is 100, the priority of the second communication task is 80, and the priority of the third communication task is 60.

[0049] If the delay time of the third communication task is relatively long, then when the communication reception event corresponding to the third communication task is triggered, based on the response delay time of the third communication task, the priority of the third communication task is increased according to the adjustment strategy of "if the delay time of the communication task exceeds the previous delay time of the communication task, the priority is increased". Assume the priority of the third communication task is adjusted to 81. Then, when another third communication task is generated, the execution order of the communication tasks in the communication queue will become: first communication task, third communication task, and second communication task.

[0050] If the system load of the main controller is higher than the historical load at this time, the priority of the second communication task will be further reduced in order to facilitate the smooth execution of the first and second communication tasks.

[0051] The first communication task, the second communication task, and the third communication task mentioned above refer to a specific type of communication task, rather than a single communication task.

[0052] In one specific embodiment, the execution status of the communication task includes at least one of the following: execution time, success rate, and response latency. Historical execution status refers to the execution status of the previous communication task. Historical execution status can also refer to the execution status of several previous communication tasks, such as taking the average, the highest value, or the lowest value. For example, when the execution status of the communication task is the execution time, the highest value from the previous few attempts can be used; when the execution status of the communication task is the success rate, the lowest value from the previous few attempts can be used.

[0053] For example, if the execution time of a communication task is too long, or the response delay is too long, then the priority of the communication task needs to be increased.

[0054] When the success rate of a communication task is low and it fails multiple times, it is necessary to increase the priority of the communication task so that it can be executed smoothly.

[0055] By meticulously monitoring data on the various execution statuses of communication tasks, task priorities can be adjusted in a timely manner.

[0056] In a further embodiment, the load status of the main controller includes at least one of the following: CPU utilization, memory utilization, and task queue length. Historical load status refers to the load status of the main controller at a previous time. Historical load status can also be the load status of the main controller over several previous periods, such as the average, minimum, or maximum value of the load status over several previous periods. When it is determined that the load status of the main controller is lower than the historical load status over a recent period, the lowest historical load status over a recent period can be selected; when it is determined that the load status of the main controller is higher than the historical load status over a recent period, the highest historical load status over a recent period can be selected.

[0057] When CPU utilization is low, the priority of communication tasks can be increased so that they can be processed as quickly as possible, thus ensuring smooth communication with other components.

[0058] When CPU utilization is high, the priority of low-priority communication tasks can be reduced to ensure the execution of other communication tasks.

[0059] The same applies to memory usage and task queue length, which facilitates stable and smooth system operation.

[0060] In a further embodiment, the priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Delay Factor) × (1 + Failure Factor) × (1 - Load Factor); Where: Delay coefficient = (Task delay / Expected delay) × Weighting coefficient; Failure coefficient = Failure rate × Weighting coefficient; The load factor is adjusted by multiplying the system load rate by the weighting factor.

[0061] The above formula takes into account the load of the device's main controller and the execution status of each communication task, so that the priority adjustment basis of all communication tasks is consistent. It can increase the priority of communication tasks with poor performance and decrease the priority of communication tasks with good performance as appropriate.

[0062] In one embodiment, the basic priority in the above technical solution can be the same basic priority for all communication tasks, or it can be a preset priority corresponding to each communication task.

[0063] In another embodiment, the priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Adjustment Factor); Adjustment factor = (Task delay / Expected delay) × a + Failure rate (frequent timeouts) × b - System load rate × c; a, b, and c are weights, all greater than 0 and less than 1.

[0064] Although this embodiment also considers system load and the execution status of the communication task itself, its adjustment effect is not as good as the previous embodiment. However, compared with the prior art, this embodiment also considers both the overall situation and the execution status of the communication task itself, which can help to adjust the priority of the communication task appropriately.

[0065] In the above embodiments, the base priority can be the same for all communication tasks, or it can be a preset priority corresponding to each communication task.

[0066] In a further embodiment, the base priority is a preset priority corresponding to the communication task.

[0067] Since the preset priority of communication tasks is based on the communication needs of the device, using the preset priority as a basis to adjust the priority of communication tasks can ensure that the priority of important communication tasks is not over-adjusted, thus ensuring the stable operation of the system.

[0068] Other components of the present invention may be components in the equipment, such as the main controller and motor drive unit of the central air conditioning system, the sensor acquisition unit, the valve control unit, etc., or peripheral components connected to the equipment through interfaces such as serial ports, such as the touch screen of the central air conditioning system.

[0069] This invention achieves event-driven scheduling through a main event loop and an event queue, asynchronous sending and response matching through a task queue, a set of tasks in transit, and a set of responses, self-recovery through re-entry queues through timeout events, and dynamic priority adjustment by combining execution data and main controller load, thereby achieving non-blocking communication, increased throughput, and enhanced reliability.

[0070] In one embodiment, the aforementioned equipment includes, but is not limited to, a central air conditioning system.

[0071] When the equipment is a central air conditioning system, motor control tasks and fault alarm communication tasks can be set to a higher initial priority. Communication tasks such as temperature or pressure readings can be set to a medium initial priority. When the system load is high or communication is abnormal, the scheduling weight of critical control or alarm tasks can be further increased through priority strategies. When a certain type of data collection task experiences increased latency or more timeouts, a priority-increasing strategy is used to encourage it to be scheduled more quickly, thereby accelerating anomaly recovery and state convergence.

[0072] Therefore, the present invention can significantly improve the communication efficiency and system stability of central air conditioning systems in environments with concurrent communication of multiple components and industrial interference.

[0073] like Figure 5 , Figure 6 As shown, the following explanation uses a central air conditioning system as an example. The main controller communicates with multiple components via a serial port, including but not limited to: a motor drive module, a fan control module, a valve control module, a sensor acquisition module, a fault detection module, and an operation panel module.

[0074] To achieve non-blocking communication and high-throughput scheduling, the main controller should establish at least the following data structures.

[0075] An event queue is used to cache system events; events include at least scheduling events, communication reception events, and timeout events.

[0076] The task queue is used to store communication tasks to be sent. Each communication task includes at least the task priority, target component identifier, request data (which can be a request frame or command parameters), and associated information for identifying the target response.

[0077] The in-transit task set is used to store communication tasks that have been initiated asynchronously and are waiting for a response. The in-transit task set can be indexed by associated information to facilitate subsequent matching.

[0078] The response set is used to temporarily store response data that has been identified as the "target response"; the response set can also be indexed by related information to support fast matching.

[0079] The main event loop is a unified event handling execution path within the main controller.

[0080] When no events arrive, the main event loop is in an event waiting state and does not perform busy-wait polling; When an event arrives, the main event loop retrieves the event from the event queue, executes the corresponding processing flow according to the event type, and returns to the event waiting state after processing is complete.

[0081] In this way, communication processing and other system processing can be uniformly scheduled through the event mechanism, achieving overall non-blocking and high responsiveness.

[0082] The system periodically generates scheduling events and posts them to the event queue. After retrieving scheduling events from the main event loop, the system retrieves communication tasks from the task queue in descending order of task priority and sends asynchronous requests to the corresponding components. Asynchronous transmission can use non-blocking serial port transmission methods, such as calling a non-blocking write interface, DMA transmission, or a transmission buffer queuing mechanism, so that the transmission action returns immediately after initiation.

[0083] For each communication task that receives an asynchronous request, the task is added to the in-transit task set. Simultaneously, an asynchronous timer for the task is started to generate a corresponding timeout event. The main event loop returns without waiting for a response, allowing it to continue processing other events in the event queue, thus achieving non-blocking communication.

[0084] When other components send response data frames to the main controller, the system generates a communication receive event. When the main event loop processes the communication receive event, it parses the response data frame (e.g., parses the address / function code / serial number / transaction identifier / verification field, etc.); it determines whether the response data is the target response, usually by checking whether the target address in the response data frame is the main controller. If so, it is the target response, and the response data is added to the response set.

[0085] When a communication receive event is triggered, a matching process will be performed, which involves matching the response data in the response set with the communication tasks in the in-transit task set.

[0086] If a match is successful, the corresponding communication task is deemed to have responded successfully, and the communication task is removed from the in-transit task set or updated to a completed status; at the same time, the execution data of the communication task can be recorded. Matching is triggered by communication reception events, which can complete task determination as soon as the response arrives, reducing the end-to-end latency between control commands and acquisition tasks.

[0087] In the communication tasks of the main controller, the initial priority or preset priority of communication tasks such as motor control tasks and fault alarm tasks can be the highest priority.

[0088] The initial or preset priority of communication tasks such as reading temperature data and reading pressure data can be medium priority.

[0089] Subsequently, during the operation of the central air conditioning unit, the priority of communication tasks can be dynamically adjusted based on the specific dynamic priority calculation method of the aforementioned technical solution, thereby improving the communication efficiency and system stability of the central air conditioning system in the context of concurrent communication of multiple components and industrial interference.

[0090] This invention achieves event-driven scheduling through a main event loop and an event queue, asynchronous sending and response matching through a task queue, a set of tasks in transit, and a set of responses, self-recovery through re-entry queues through timeout events, and dynamic priority adjustment by combining execution data and main controller load, thereby achieving non-blocking communication, increased throughput, and enhanced reliability.

[0091] The present invention also protects a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform a communication processing method of the device according to any of the above-described technical solutions.

[0092] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A communication processing method for a device, characterized in that, include: Establish a main event loop and an event queue. The main event loop is in an event waiting state when no events arrive, and retrieves the event from the event queue when an event arrives to trigger the corresponding processing flow. Establish communication tasks for the data to be sent by the device's main controller, and store them in the task queue according to task priority; Communication tasks are periodically retrieved from the task queue in descending order of priority, asynchronous requests are sent to the corresponding components, and the retrieved communication tasks are stored in the in-transit task set. At the same time, the asynchronous timer of the communication task is started to form the corresponding timeout event. After each communication task initiates an asynchronous request, it returns to the main event loop without waiting for a response result to continue processing other events in the event queue. When other components send response data based on the corresponding asynchronous request, a communication receiving event is generated. When the main event loop processes the communication receiving event, it parses the response data and determines whether it is the target response. If it is, it adds it to the response set. When a timeout event or a communication reception event is triggered, the corresponding communication task is matched with the response data in the response set. If the match is successful, the corresponding communication task is determined to have responded successfully, and the communication task is removed from the in-transit task set or updated to the completed status. If the match fails, the communication task is reinserted into the task queue.

2. The communication processing method of the device as described in claim 1, characterized in that, When a timeout event or a communication reception event is triggered, record or update at least one of the following information for the corresponding communication task in the in-transit task set: first execution event, final completion event, success status, number of executions, and response delay time.

3. The communication processing method of the device as described in claim 2, characterized in that, The initial value of the priority of the communication tasks in the task queue is a preset priority; When the execution status of a communication task and / or the load status of the main controller differs from historical data over a recent period, the priority of the communication task is dynamically adjusted according to at least one of the following adjustment strategies: If the execution status of a communication task exceeds the historical execution status within a recent period, its priority should be increased. When the load on the main controller is higher than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold will be reduced. When the load on the main controller is lower than the historical load over a recent period, the priority of communication tasks whose priority is below the priority threshold is increased.

4. The communication processing method of the device as described in claim 3, characterized in that, The execution status of the communication task includes at least one of the execution time of the communication task and the response delay time; the historical execution status refers to the execution status of the previous communication task.

5. The communication processing method of the device as described in claim 3, characterized in that, The load status of the main controller includes at least one of the following: CPU utilization, memory usage, and task queue length; the historical load status refers to the load status of the main controller in the previous instance.

6. The communication processing method of the device as described in claim 3, characterized in that, The priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Delay Factor) × (1 + Failure Factor) × (1 - Load Factor); Where: Delay coefficient = (Task delay / Expected delay) × Weighting coefficient; Failure coefficient = Failure rate × Weighting coefficient; The load factor is adjusted by multiplying the system load rate by the weighting factor.

7. The communication processing method of the device as described in claim 3, characterized in that, The priority of the communication task is calculated according to the following formula: Priority = Base Priority × (1 + Adjustment Factor); Adjustment factor = (Task delay / Expected delay) × a + Failure rate (frequent timeouts) × b - System load rate × c; a, b, and c are weights, all greater than 0 and less than 1.

8. The communication processing method of the device as described in claim 6 or 7, characterized in that, The basic priority is the preset priority corresponding to the communication task.

9. The communication processing method of the device according to any one of claims 1 to 7, characterized in that, The equipment includes a central air conditioning system.

10. A computer-readable storage medium having a computer program stored thereon, wherein when executed by a processor, the computer program causes the processor to perform a communication processing method of the device according to any one of claims 1 to 8.

Images