Multi-connected system firmware upgrading method and device, multi-connected equipment and storage medium

Abstract

Embodiments of the present application relate to a multi-split system firmware upgrading method and device, a multi-split system equipment and a storage medium. The firmware upgrading method comprises the following steps: obtaining upgrading task information of a plurality of firmware upgrading tasks in a multi-split system, and determining task priorities between the plurality of firmware upgrading tasks according to the upgrading task information; when a target firmware upgrading task with a higher priority than a current firmware upgrading task is detected during execution of the current firmware upgrading task, stopping the current firmware upgrading task, and determining a waiting time according to an upgrading progress and a data transmission state of the target firmware upgrading task; and resuming execution of the current firmware upgrading task when no firmware data corresponding to the target firmware upgrading task is detected within the waiting time. Thus, concurrent firmware upgrading tasks can be orderly coordinated, data conflicts caused by simultaneous occupation of communication resources by different upgrading tasks can be reduced, and the coordination reliability of firmware upgrading tasks in the multi-split system and the accuracy of the resumption timing of interrupted firmware upgrading tasks can be improved.

Description

Technical Field

[0001] This application relates to the field of multi-split air conditioning system control technology, and in particular to a firmware upgrade method, apparatus, multi-split equipment and storage medium for multi-split systems. Background Technology

[0002] Multi-split energy-saving air conditioning systems typically include an outdoor unit, multiple indoor units, and control equipment for controlling and maintaining the indoor and outdoor units. As the functions of multi-split air conditioning systems are continuously updated, firmware upgrades are usually required in the indoor or outdoor units to achieve functional iteration, fault repair, and after-sales maintenance. In practical applications, firmware upgrade tasks can be initiated through devices such as centralized controllers, wired controllers, or debuggers, and firmware data can be transmitted to the indoor or outdoor unit to be upgraded via the corresponding communication network.

[0003] When multiple devices are capable of initiating firmware upgrade tasks, these tasks may overlap in execution time and compete for communication resources in a multi-split air conditioning system. For example, while the central controller or wired controller is executing a background firmware upgrade task, the debugger may initiate a new firmware upgrade task due to on-site debugging or troubleshooting; the central controller and wired controller may also simultaneously send firmware data to the indoor or outdoor unit. If multiple firmware upgrade tasks lack effective coordination, it may cause mutual interference between upgrade data, data loss, or upgrade failure.

[0004] Therefore, how to reasonably coordinate the execution of various firmware upgrade tasks when there are multiple firmware upgrade tasks in a multi-split air conditioning system has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, this application provides a firmware upgrade method, apparatus, multi-unit device and storage medium for multi-unit systems.

[0006] In a first aspect, embodiments of this application provide a firmware upgrade method for a multi-unit system, including: Obtain upgrade task information for multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information; If a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and the waiting time is determined based on the upgrade progress and data transmission status of the target firmware upgrade task. If no firmware data corresponding to the target firmware upgrade task is detected within the waiting period, the current firmware upgrade task is resumed.

[0007] In one possible implementation, obtaining upgrade task information for multiple firmware upgrade tasks in a multi-connector system includes: Monitor upgrade frames used for transmitting firmware data in the communication network of the multi-unit system; The source device type and target device address in the upgrade frame are obtained. The device type of the upgrade initiating device for the firmware upgrade task is determined according to the source device type, and the upgrade object of the firmware upgrade task is determined according to the target device address. The device type of the upgrade initiating device and the upgrade object are used as the upgrade task information of the corresponding firmware upgrade task. The upgrade initiating device includes a debugger, a central controller and a wired controller. The upgrade object includes the indoor unit and the outdoor unit in the multi-split air conditioning system.

[0008] In one possible implementation, determining the task priority among the plurality of firmware upgrade tasks based on the upgrade task information includes: For any two firmware upgrade tasks among the plurality of firmware upgrade tasks, the task priority between the two firmware upgrade tasks is determined based on the device type and upgrade target of the upgrade initiating device in the upgrade task information of the two firmware upgrade tasks, including: When one of the two firmware upgrade tasks is initiated by a debugger and the other is initiated by a central controller or a wired controller, the firmware upgrade task initiated by the debugger has a higher priority than the firmware upgrade task initiated by the central controller or the wired controller. When the two firmware upgrade tasks are initiated by a central controller and a wired controller respectively, if the upgrade target of both firmware upgrade tasks is an outdoor unit, then the firmware upgrade task initiated by the central controller is determined to have a higher priority than the firmware upgrade task initiated by the wired controller. If the upgrade target of both firmware upgrade tasks is an indoor unit, then the firmware upgrade task initiated by the wired controller is determined to have a higher priority than the firmware upgrade task initiated by the central controller.

[0009] In one possible implementation, the multi-split air conditioning system includes one outdoor unit and multiple indoor units. The communication network includes a first communication network and a second communication network. The central controller, the debugger, the multiple indoor units, and the outdoor unit are connected to the first communication network. Each indoor unit is connected to a wired controller, and the wired controller communicates with the corresponding indoor unit through the second communication network. The method further includes: When the upgrade initiating device is a centralized controller or debugger, the firmware data of the corresponding firmware upgrade task is sent to the indoor or outdoor unit that is the target of the upgrade through the first communication network. When the upgrade initiating device is a wired controller and the upgrade target is an indoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network. When the upgrade initiating device is a wired controller and the upgrade target is an outdoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network, so that the indoor unit forwards the firmware data to the outdoor unit through the first communication network.

[0010] In one possible implementation, the method further includes: When the firmware upgrade task initiated by the central controller targets the outdoor unit, and the firmware upgrade task initiated by the wired controller targets the indoor unit corresponding to the wired controller, the firmware upgrade task initiated by the central controller and the firmware upgrade task initiated by the wired controller are executed in parallel.

[0011] In one possible implementation, determining the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task includes: The remaining number of upgrade frames for the target firmware upgrade task is determined based on the complete firmware size corresponding to the target firmware upgrade task, the firmware data size transmitted in a single upgrade frame, and the current upgrade frame sequence number. The average transmission rate is determined based on the number of upgrade frames sent and the corresponding transmission duration of the target firmware upgrade task, and the redundancy coefficient is determined based on the number of repeatedly sent upgrade frames and the current upgrade frame sequence number. The waiting time is determined based on the preset base waiting time, the remaining number of upgrade frames, the average transmission rate, and the redundancy coefficient.

[0012] In one possible implementation, resuming the execution of the current firmware upgrade task when no firmware data corresponding to the target firmware upgrade task is detected within the waiting period includes: After stopping the current firmware upgrade task, continuously monitor upgrade frames in the communication network; When an upgrade frame corresponding to the target firmware upgrade task is detected, the current firmware upgrade task remains stopped, and the waiting time is restarted. If no upgrade frame corresponding to the target firmware upgrade task is detected within the specified waiting time, the current firmware upgrade task is resumed.

[0013] Secondly, embodiments of this application provide a firmware upgrade device for a multi-unit system, comprising: The determination module is used to obtain upgrade task information of multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information. The first control module is used to stop the current firmware upgrade task when a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, and to determine the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task. The second control module is used to resume the execution of the current firmware upgrade task when no firmware data corresponding to the target firmware upgrade task is detected within the waiting time.

[0014] Thirdly, embodiments of this application provide a multi-unit device, including: a processor and a memory, wherein the processor is used to execute a multi-unit system firmware upgrade program stored in the memory to implement the multi-unit system firmware upgrade method described in any one of the first aspects above.

[0015] Fourthly, embodiments of this application provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the multi-unit system firmware upgrade method described in any of the first aspects above.

[0016] The firmware upgrade scheme for multi-unit systems provided in this application obtains upgrade task information for multiple firmware upgrade tasks in the multi-unit system and determines the task priority among the multiple firmware upgrade tasks based on the upgrade task information. When a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and a waiting time is determined based on the upgrade progress and data transmission status of the target firmware upgrade task. If no firmware data corresponding to the target firmware upgrade task is detected within the waiting time, the execution of the current firmware upgrade task is resumed. Therefore, by determining task priorities based on the upgrade task information of multiple firmware upgrade tasks and stopping the current firmware upgrade task when a higher-priority target firmware upgrade task is detected, concurrent firmware upgrade tasks can be coordinated in an orderly manner, reducing data conflicts caused by different upgrade tasks occupying communication resources simultaneously. At the same time, the waiting time is dynamically determined based on the upgrade progress and data transmission status of the target firmware upgrade task, and the current firmware upgrade task is resumed after the corresponding waiting conditions are met. This ensures that the resumption timing matches the actual execution status of the target firmware upgrade task, avoiding conflicts from recurring due to excessively short waiting times or idle communication resources due to excessively long waiting times. This improves the coordination reliability of firmware upgrade tasks in multi-unit systems and the accuracy of the resumption timing of interrupted firmware upgrade tasks. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a firmware upgrade method for a multi-unit system provided in this application embodiment; Figure 2 A flowchart illustrating another firmware upgrade method for a multi-unit system provided in this application embodiment; Figure 3 A structural diagram of a firmware upgrade system for a multi-unit system provided in this application embodiment; Figure 4 A structural diagram of a firmware upgrade device for a multi-unit system provided in this application embodiment; Figure 5 This is a structural diagram of a multi-unit air conditioning system provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0020] This application provides a firmware upgrade method for a multi-connector system. By arbitrating the priority of multiple firmware upgrade tasks existing simultaneously in the system, the method stops low-priority firmware upgrade tasks when a high-priority task appears. The waiting time for low-priority tasks is dynamically determined based on the actual upgrade progress and data transmission status of the high-priority task, allowing them to resume after the high-priority task releases its communication resources. Furthermore, the method can also utilize the communication paths between different upgrade initiating devices and upgrade targets within the multi-connector system to process firmware upgrade tasks that can utilize different communication paths in parallel.

[0021] It should be noted that the firmware involved in the embodiments of this application can be program data, program images, or other data that can be written to the device storage area and used to update the device's operating program, used to control the operation of devices such as indoor units and outdoor units. The firmware upgrade task can involve sending the target version of firmware data to the corresponding upgrade object, so that the upgrade object can perform a program update task based on the received firmware data.

[0022] Figure 1A flowchart of a firmware upgrade method for a multi-unit system provided in this application embodiment is shown below. Figure 1 As shown, the specific implementation steps of the firmware upgrade method are as follows: Step S101: Obtain upgrade task information for multiple firmware upgrade tasks in the multi-unit system, and determine the task priority among multiple firmware upgrade tasks based on the upgrade task information.

[0023] A multi-split air conditioning system can be an air conditioning system consisting of at least one outdoor unit, multiple indoor units, and equipment for controlling, maintaining, or debugging the indoor and / or outdoor units. A firmware upgrade task can be initiated by an upgrade initiating device in the multi-split system, used to transmit firmware data to the corresponding upgrade target and control the upgrade target to perform a firmware upgrade. Upgrade task information can be used to characterize the source of the firmware upgrade task, the upgrade target, or other information related to task scheduling. Task priority can be used to characterize the execution order of multiple firmware upgrade tasks when they compete for the same or related communication resources.

[0024] In this embodiment, the firmware upgrade method can be applied to firmware upgrade scenarios in multi-split air conditioning systems, such as routine version updates, silent background upgrades, on-site installation and debugging, and after-sales fault repair. Multi-split air conditioning systems can include, but are not limited to, energy-saving multi-split air conditioning systems. The executing entity of this method can be a multi-split air conditioning device with data processing and firmware upgrade scheduling capabilities. The multi-split air conditioning device can be a centralized controller, wired controller, or other device capable of monitoring and controlling the firmware upgrade process within the multi-split air conditioning system, or it can be an independent computer device communicatively connected to the multi-split air conditioning system. An upgrade control module can be set up in the multi-split air conditioning device. This module obtains upgrade task information for multiple firmware upgrade tasks, determines task priorities, and controls the corresponding firmware upgrade tasks based on task priorities and the execution status of the firmware upgrade tasks. For ease of description, the following example illustrates the execution entity as a preset upgrade control module controlling the currently executing firmware upgrade task and monitoring other firmware upgrade tasks in the communication network.

[0025] During the firmware upgrade process, the upgrade control module can obtain upgrade task information corresponding to multiple firmware upgrade tasks that already exist, are being executed, or are requested to be executed in the communication network, and compare different firmware upgrade tasks according to the pre-set task priority rules to determine the task priority among different firmware upgrade tasks.

[0026] Specifically, task priority rules can be pre-configured based on at least one of the following: the urgency of the firmware upgrade task, the priority of the device initiating the upgrade, the priority of the target device, and the communication path traversed by the firmware data. For example, firmware upgrade tasks for on-site after-sales debugging typically need to be completed as quickly as possible and have a higher priority, while firmware upgrade tasks automatically triggered by other devices during routine operation can be treated as background upgrade tasks and have a lower priority. Different task priorities are set for different upgrade task information. Therefore, different task priorities can be configured for the above-mentioned different types of firmware upgrade tasks.

[0027] Therefore, when there are multiple firmware upgrade tasks, the upgrade control module can determine the priority relationship between tasks based on the upgrade task information corresponding to each firmware upgrade task, without allowing multiple firmware upgrade tasks that compete for communication resources to send firmware data in an disorderly manner at the same time.

[0028] Step S102: When a target firmware upgrade task with a higher priority than the current firmware upgrade task is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and the waiting time is determined according to the upgrade progress and data transmission status of the target firmware upgrade task.

[0029] The current firmware upgrade task can be a firmware upgrade task that the executing entity is currently executing or is currently controlling to send firmware data. The target firmware upgrade task can be another firmware upgrade task detected during the execution of the current firmware upgrade task, which has a higher priority than the current firmware upgrade task. The upgrade progress can be used to characterize the firmware data transmission status of the target firmware upgrade task, including completed and incomplete data transmissions. The data transmission status can be used to characterize the data transmission efficiency and communication quality of the target firmware upgrade task during actual communication, and may be related to data transmission rate, data duplication, etc. The waiting time can be a dynamic waiting time set after the current firmware upgrade task is stopped, before it is allowed to resume.

[0030] In this embodiment, during the execution of the current firmware upgrade task, the upgrade control module can continuously monitor firmware data or communication data related to firmware upgrades in the communication network. When it is determined from the detected data that a target firmware upgrade task with a higher priority than the current firmware upgrade task exists, the current firmware upgrade task can be paused from sending firmware data to the communication network, so as to allocate the competing communication resources to the target firmware upgrade task.

[0031] Optionally, when stopping the current firmware upgrade task, the task status such as the amount of firmware data already sent, the current sending position, or the current upgrade frame sequence number can be retained, so that when the current firmware upgrade task is resumed later, it can continue from the stopped position without resending all the firmware data that has been transmitted.

[0032] Furthermore, instead of setting a fixed waiting time after stopping the current firmware upgrade task, the upgrade control module obtains the current upgrade progress and actual data transmission status of the target firmware upgrade task, and calculates the time required for the target firmware upgrade task to complete the remaining firmware data transmission based on the above information using a preset calculation method, thereby determining the waiting time.

[0033] For example, the waiting time can be set based on the remaining firmware data in the target firmware upgrade task. When the data transmission rate of the target firmware upgrade task is high, the waiting time can be shortened accordingly; when there are many data retransmissions in the target firmware upgrade task, it indicates that the current communication quality is relatively poor, and the waiting time can be extended accordingly. This allows the waiting time to change according to the real-time execution status of the target firmware upgrade task.

[0034] Optionally, historical upgrade data corresponding to multiple historical firmware upgrade tasks can be pre-acquired. Training samples are constructed based on the upgrade progress and data transmission status of each historical firmware upgrade task at different upgrade stages. The historical remaining upgrade time corresponding to each training sample is used as a sample label to train the initial waiting time prediction model, resulting in a target waiting time prediction model. When a higher-priority target firmware upgrade task is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, the current upgrade progress and data transmission status of the target firmware upgrade task are acquired, and the upgrade progress and data transmission status are input into the target waiting time prediction model. The target waiting time prediction model then outputs the corresponding waiting time. The upgrade progress can be represented, for example, by the number of remaining upgrade frames, and the data transmission status can include, for example, the average transmission rate and upgrade frame retransmission status, so that the waiting time output by the model can dynamically change with the actual remaining data volume and communication status of the target firmware upgrade task.

[0035] Step S103: If no firmware data corresponding to the target firmware upgrade task is detected within the waiting time, resume the execution of the current firmware upgrade task.

[0036] The firmware data corresponding to the target firmware upgrade task can be data sent by the upgrade-initiating device of the target firmware upgrade task to enable the corresponding upgrade object to perform a firmware upgrade. Resuming the execution of the current firmware upgrade task can involve removing the data transmission restrictions for the current firmware upgrade task and continuing to send the firmware data that the current firmware upgrade task has not yet completed to the corresponding upgrade object.

[0037] In this embodiment, after the current firmware upgrade task stops, the upgrade control module continues to monitor the firmware data corresponding to the target firmware upgrade task in the communication network. While the target firmware upgrade task continues to send firmware data, the current firmware upgrade task remains stopped to prevent it from re-occupying the communication resources currently being used by the target firmware upgrade task.

[0038] If no firmware data corresponding to the target firmware upgrade task is detected after the waiting time determined based on the actual status of the target firmware upgrade task, it can be considered that the target firmware upgrade task has completed firmware data transmission or has released the communication resources required by the current firmware upgrade task, and therefore the current firmware upgrade task is resumed.

[0039] For example, if the current firmware upgrade task is preempted by the target firmware upgrade task when it reaches the 300th upgrade frame, the task progress corresponding to the 300th upgrade frame can be recorded. After the recovery conditions are met, subsequent firmware data can be sent based on the recorded task progress, thus avoiding restarting the entire firmware upgrade process.

[0040] As can be seen from the above, the embodiments of this application determine the task priority among different firmware upgrade tasks based on the upgrade task information, and can perform orderly arbitration of tasks when multiple firmware upgrade tasks occur concurrently; after the target firmware upgrade task with higher priority appears, the current firmware upgrade task is stopped, and the waiting time is dynamically determined in combination with the upgrade progress and data transmission status of the target firmware upgrade task. This can avoid communication conflicts caused by a fixed waiting time that is too short, and can also avoid communication resources being idle due to a fixed waiting time that is too long, thereby improving the reliability and upgrade efficiency of the firmware upgrade process of the multi-unit system.

[0041] In one possible implementation, a specific process for obtaining upgrade task information for multiple firmware upgrade tasks in a multi-connector system is described. The specific process for obtaining the upgrade task information is as follows: Step S201: Listen for upgrade frames used to transmit firmware data in the communication network of the multi-unit system.

[0042] The communication network can be a communication link in a multi-unit system used to transmit control information, status information, and firmware data between different devices. An upgrade frame can be a data frame organized according to a preset communication protocol and used to carry firmware upgrade-related data. A complete firmware file can be divided into multiple data parts, which are then sent separately through multiple upgrade frames.

[0043] In this embodiment, the upgrade control module can monitor the data frames in the multi-unit system communication network in real time or according to a preset detection cycle, and identify the upgrade frame from the data frames in the communication network based on the frame type, function field or other information used to identify the firmware upgrade service in the data frame.

[0044] For example, the data volume of a complete firmware is usually greater than the data volume that a single communication frame can carry. Therefore, the complete firmware can be split into multiple firmware data blocks, and multiple upgrade frames can be constructed and sent sequentially. In addition to carrying the current firmware data, each upgrade frame can also carry information describing the corresponding firmware upgrade task.

[0045] Step S202: Obtain the source device type and target device address in the upgrade frame, determine the device type of the firmware upgrade task initiating device based on the source device type, and determine the upgrade object of the firmware upgrade task based on the target device address, and use the device type and upgrade object of the upgrade initiating device as the upgrade task information of the corresponding firmware upgrade task.

[0046] The source device type can be information characterizing the type of device sending the upgrade frame. The target device address can be address information used to uniquely identify, or at least determine, the upgrade object corresponding to the upgrade frame in the current multi-split system. The upgrade initiating device can be a device that initiates a firmware upgrade task and sends or triggers the transmission of firmware data to the communication network; it can include debuggers, central controllers, and wired controllers. The upgrade object can be a device that receives the corresponding firmware data and performs a firmware update; it can include indoor and outdoor units in the multi-split system.

[0047] In this embodiment, after recognizing an upgrade frame, the upgrade control module can parse the preset fields of the upgrade frame to obtain the source device type and target device address recorded therein. Based on the pre-established correspondence between the source device type and the device type, the upgrade initiating device corresponding to the firmware upgrade task to which the upgrade frame belongs can be determined; at the same time, the specific device corresponding to the target device address can be queried according to the device address table in the multi-connector system, thereby determining the upgrade target of the firmware upgrade task.

[0048] For example, when the source device type of an upgrade frame is parsed to be a debugger and the target device address corresponds to the first indoor unit, it can be determined that the firmware upgrade task corresponding to the upgrade frame is a firmware upgrade task initiated by the debugger and targeting the first indoor unit. The information corresponding to the debugger and the first indoor unit is then used as the upgrade task information for the firmware upgrade task.

[0049] For example, when the source device type represents a wired controller and the target device address corresponds to an outdoor unit, the wired controller can be used as the upgrade initiator and the outdoor unit as the upgrade target, thereby forming the upgrade task information corresponding to the firmware upgrade task.

[0050] Optionally, in addition to the source device type and target device address, the upgrade frame may also include the full firmware size, the current upgrade frame number, and the current firmware data. These other fields can be used to determine the upgrade progress or data transmission status of the firmware upgrade task, thus providing a data basis for subsequent calculations of the waiting time.

[0051] Using the above method, upgrade task information can be obtained directly based on the upgrade frames actually transmitted in the communication network, so that the task priority judgment can correspond to the actual firmware transmission process.

[0052] In one possible implementation, a specific process for determining the task priority among multiple firmware upgrade tasks based on upgrade task information is described. The specific process for determining the task priority is as follows: Step S301: For any two firmware upgrade tasks among multiple firmware upgrade tasks, determine the task priority between the two firmware upgrade tasks based on the device type and upgrade target of the upgrade initiating device in the upgrade task information of the two firmware upgrade tasks.

[0053] In this system, any two firmware upgrade tasks can be selected from multiple concurrent firmware upgrade tasks or tasks whose execution times at least partially overlap. Using pairwise comparisons to determine task priority does not mean that only two firmware upgrade tasks can exist in a multi-unit system. For example, when the debugger, central controller, and wired controller each have firmware upgrade tasks, the priority relationships between multiple tasks can be determined by comparing the firmware upgrade tasks corresponding to the debugger with those corresponding to the central controller, the debugger with those corresponding to the wired controller, and the central controller with those corresponding to the wired controller.

[0054] In this embodiment, a pre-established correspondence between different upgrade initiating devices, different upgrade targets, and task priorities can be established. The upgrade control module queries the above correspondence based on the device type of the upgrade initiating device and the upgrade target of each of the two firmware upgrade tasks, thereby obtaining the task priorities between the two firmware upgrade tasks.

[0055] Step S302: When one firmware upgrade task is initiated by a debugger and the other firmware upgrade task is initiated by a central controller or wired controller, determine that the firmware upgrade task initiated by the debugger has a higher priority than the firmware upgrade task initiated by the central controller or wired controller.

[0056] The debugger can be a device used for installation, debugging, fault diagnosis, or after-sales maintenance of multi-split air conditioning systems. The central controller can be a device capable of centrally controlling multiple indoor and / or outdoor units in a multi-split air conditioning system. The wired controller can be a control device that communicates with the corresponding indoor unit and can initiate firmware upgrade tasks.

[0057] In this embodiment, the firmware upgrade task corresponding to the debugger typically occurs in on-site debugging or after-sales fault handling scenarios, and its timeliness is higher than that of background upgrade tasks executed by the central controller or wired controller during daily operation. Therefore, when the firmware upgrade task corresponding to the debugger and the firmware upgrade task corresponding to the central controller or wired controller exist simultaneously, the firmware upgrade task corresponding to the debugger can be set to a higher task priority.

[0058] For example, if an upgrade frame sent by a debugger is detected in the communication network while the wired controller is sending firmware data to the indoor unit in the background, the debugger firmware upgrade task can be determined based on the source device type of the upgrade frame. The task priority of the debugger is determined to be higher than the firmware upgrade task currently being executed by the wired controller, and then the current firmware data transmission of the wired controller is stopped according to step S102.

[0059] Step S303: When the upgrade initiating devices of the two firmware upgrade tasks are a centralized controller and a wired controller, the task priority between the two firmware upgrade tasks is determined according to the upgrade objects of the two firmware upgrade tasks.

[0060] Among them, the central controller and the wired controller have different firmware data transmission paths for different upgrade objects, so that the upgrade initiation device that is more suitable for the corresponding upgrade path can be selected according to the upgrade object.

[0061] In this embodiment, when both firmware upgrade tasks corresponding to the central controller and the wired controller target the outdoor unit, the firmware upgrade task initiated by the central controller has a higher priority than the firmware upgrade task initiated by the wired controller. The central controller can directly transmit firmware data through the communication network of the outdoor unit, while the wired controller needs to forward firmware data to the outdoor unit through the corresponding indoor unit. Therefore, prioritizing the execution of the outdoor unit's firmware upgrade task by the central controller reduces intermediate forwarding processes and related communication resource consumption.

[0062] When both firmware upgrade tasks for the central controller and the wired controller target indoor units, the firmware upgrade task initiated by the wired controller has a higher priority than the one initiated by the central controller. The wired controller can directly send firmware data to the corresponding indoor unit via its communication link; therefore, the wired controller is given priority in executing the firmware upgrade task for that indoor unit, reducing the overhead on other communication links.

[0063] It should be noted that the above embodiments mainly describe the priority relationships explicitly set in this application. For other task combinations without explicitly set fixed priorities, corresponding scheduling rules can be pre-set according to the communication resource configuration in the actual product, and this embodiment does not limit their specific priority order. For tasks that can be executed using different communication paths and do not need to be mutually exclusive according to the above priorities, the parallel execution method described in subsequent embodiments can also be adopted.

[0064] The above task priority rules not only enable the priority execution of debugger tasks based on the business urgency of different firmware upgrade tasks, but also allow for differentiated scheduling based on the actual data transmission paths of different upgrade objects by combining the central controller and wire controller.

[0065] In one possible implementation, a specific process is described for different upgrade initiating devices to transmit firmware data to different upgrade targets. The specific implementation process is as follows.

[0066] Step S401: Establish the communication relationship between the devices in the multi-unit system.

[0067] A multi-split air conditioning system may include one outdoor unit and multiple indoor units. The indoor units can be installed in different indoor spaces and work in conjunction with the outdoor unit for air conditioning. The first communication network can be a network used for communication between the indoor units, outdoor units, and other centralized control or debugging equipment. The second communication network can be a network used for communication between a wired controller and its corresponding indoor unit.

[0068] In this embodiment, the central controller, the debugger, multiple indoor units and outdoor units can be connected to the first communication network, each indoor unit is connected to a wired controller, and each wired controller communicates with its corresponding indoor unit through the second communication network.

[0069] For example, the first communication network can be a Controller Area Network (CAN) to form a bus network that enables data exchange between indoor units, outdoor units, central controllers, and debuggers; the second communication network can be a Home Bus (HomeBUS) to establish communication connections between each wired controller and its corresponding indoor unit.

[0070] Here, "corresponding indoor unit" refers to the indoor unit that directly establishes a second communication network relationship with the current wired controller. For example, when a multi-split system includes a first indoor unit, a second indoor unit, and a third indoor unit, a first wired controller, a second wired controller, and a third wired controller can be set up respectively. The first wired controller corresponds to the first indoor unit, the second wired controller corresponds to the second indoor unit, and the third wired controller corresponds to the third indoor unit. Therefore, not all wired controllers communicate through the same indoor unit.

[0071] Optionally, the central controller and wired controller can obtain the firmware file to be upgraded from the network server; the debugger can have file read and write functions, for example, it can obtain the pre-written indoor or outdoor unit firmware file through the Universal Serial Bus (USB) interface.

[0072] Step S402: When the upgrade initiating device is a centralized controller or debugger, the firmware data of the corresponding firmware upgrade task is sent to the indoor or outdoor unit that is the target of the upgrade through the first communication network.

[0073] Both the central controller and the debugger are connected to the first communication network, thus enabling them to communicate with the indoor and outdoor units connected to the network.

[0074] In this embodiment, when the centralized controller initiates a firmware upgrade task, it can generate an upgrade frame based on the target device address corresponding to the upgrade object of the firmware upgrade task, and send the upgrade frame to the first communication network. After receiving the upgrade frame, the indoor unit or outdoor unit corresponding to the target device address in the first communication network extracts firmware data from the upgrade frame and uses it to perform the firmware upgrade.

[0075] Similarly, when the debugger initiates a firmware upgrade task, it can divide the firmware file to be upgraded into multiple firmware data parts, construct multiple corresponding upgrade frames, and send them to the corresponding indoor or outdoor unit through the first communication network.

[0076] For example, when the central controller needs to upgrade the second indoor unit, the device address of the second indoor unit can be written into the target device address field of the upgrade frame, and multiple upgrade frames can be sent via the first communication network. The second indoor unit identifies the corresponding upgrade frame based on the target device address and receives the firmware data carried in it sequentially.

[0077] Step S403: When the upgrade initiating device is a wired controller and the upgrade target is an indoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network.

[0078] Since each wired controller communicates directly with its corresponding indoor unit through the second communication network, when upgrading the corresponding indoor unit of the wired controller, there is no need to forward the communication through the first communication network or other indoor units.

[0079] In this embodiment, the wired controller can encapsulate the target device address of the corresponding indoor unit and the firmware data to be sent into an upgrade frame, and send it directly to the corresponding indoor unit through the second communication network. The corresponding indoor unit receives multiple upgrade frames in sequence and restores the order of the firmware data according to the upgrade frame sequence number to obtain complete or write-compliant firmware data.

[0080] Step S404: When the upgrade initiating device is a wired controller and the upgrade target is an outdoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network, so that the indoor unit forwards the firmware data to the outdoor unit through the first communication network.

[0081] Among them, the indoor unit corresponding to the wired controller can communicate with the second communication network where the wired controller is located, as well as the first communication network where the indoor and outdoor units are located. Therefore, it can serve as a forwarding node between the two communication networks when the wired controller is upgraded to an outdoor unit.

[0082] In this embodiment, the wired controller first generates an upgrade frame based on the target device address of the outdoor unit to be upgraded and the firmware data to be sent, and then sends the upgrade frame to the corresponding indoor unit through the second communication network. Upon receiving the upgrade frame, the indoor unit determines, based on the target device address in the upgrade frame, that the final upgrade target is not itself but the outdoor unit. Therefore, it forwards the firmware data in the upgrade frame, or an upgrade frame containing that firmware data, to the first communication network. The outdoor unit receives the forwarded upgrade frame from the first communication network and performs a firmware upgrade based on the firmware data contained therein.

[0083] Optionally, when it is necessary to provide feedback on the outdoor unit upgrade status to the wired controller, the corresponding indoor unit can also forward the upgrade response data received from the first communication network and related to the firmware upgrade task initiated by the wired controller to the second communication network, so that the wired controller can obtain the firmware upgrade progress or data transmission status of the outdoor unit.

[0084] Therefore, the centralized controller and debugger can send firmware data to the indoor or outdoor unit through the first communication network, the wired controller can directly upgrade the corresponding indoor unit through the second communication network, and can upgrade the outdoor unit across communication networks with the help of the corresponding indoor unit.

[0085] In one possible implementation, a specific process for performing firmware upgrade tasks in parallel using different communication paths is described. The specific implementation process is as follows: Step S501: When the firmware upgrade task initiated by the central controller targets the outdoor unit, and the firmware upgrade task initiated by the wired controller targets the indoor unit corresponding to the wired controller, the firmware upgrade task initiated by the central controller and the firmware upgrade task initiated by the wired controller are executed in parallel.

[0086] Parallel execution can mean that at least part of the execution time of two firmware upgrade tasks overlaps, but does not require that the two firmware upgrade tasks start or end at exactly the same time.

[0087] In this embodiment, when the centralized controller upgrades the outdoor unit, it can send firmware data directly to the outdoor unit through the first communication network; when the wired controller upgrades its corresponding indoor unit, it can send firmware data directly to the corresponding indoor unit through the second communication network. Since the two firmware upgrade tasks use different direct communication paths to transmit firmware data, the two firmware upgrade tasks can be executed in parallel for at least part of the time without globally blocking the other task simply because a firmware upgrade task already exists in the system.

[0088] For example, if the central controller is sending firmware data to the outdoor unit via the first communication network, and the first wired controller needs to upgrade its corresponding indoor unit, the first wired controller can simultaneously send firmware data to the indoor unit via the second communication network. In this case, the firmware upgrade task corresponding to the central controller and the firmware upgrade task corresponding to the first wired controller transmit data along different communication paths.

[0089] Compared to the completely sequential approach of upgrading the outdoor unit first and then the indoor unit, the parallel approach described above allows the execution times of the two firmware upgrade tasks to overlap at least partially. For example, if the upgrade times required for the two tasks are the first upgrade time and the second upgrade time, respectively, the overall execution time after parallel execution can approach the larger of the two upgrade times, rather than simply adding the two upgrade times together.

[0090] It should be noted that when the firmware upgrade tasks of the central controller and the wired controller target the same upgrade object and there is a competition for communication resources, arbitration can be performed according to the aforementioned task priority rules, without the need for forced parallel execution. For example, if both are upgrading the outdoor unit, the firmware upgrade task initiated by the central controller can be executed first; if both are upgrading the indoor unit, the firmware upgrade task initiated by the wired controller can be executed first.

[0091] Therefore, different communication paths in a multi-device system can be fully utilized, reducing unnecessary waiting between firmware upgrade tasks that do not require necessary resource competition, and shortening the time required for multiple devices to complete a firmware upgrade as a whole.

[0092] In one possible implementation, a specific process for determining the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task is described. The specific process for determining the waiting time is as follows: Step S601: Determine the remaining number of upgrade frames for the target firmware upgrade task based on the complete firmware size corresponding to the target firmware upgrade task, the firmware data size transmitted in a single upgrade frame, and the current upgrade frame sequence number.

[0093] The total firmware size refers to the amount of data in the complete firmware file that the target firmware upgrade task needs to transmit to the corresponding upgrade object. The firmware data size transmitted in a single upgrade frame refers to the amount of data actually used to carry the firmware content in an upgrade frame. The current upgrade frame sequence number can be used to indicate the position of the upgrade frame that has been transmitted so far. The remaining upgrade frame number can be used to characterize the number of upgrade frames corresponding to the amount of firmware data that the target firmware upgrade task still needs to transmit.

[0094] In this embodiment, the total number of upgrade frames required to complete the entire firmware transmission can be determined first based on the complete firmware size and the firmware data size transmitted in a single upgrade frame. Then, the remaining number of upgrade frames can be determined based on the difference between the total number of upgrade frames and the current upgrade frame sequence number.

[0095] For example, the total number of upgrade frames can be determined according to the following relationship: Total number of upgrade frames = Total firmware size ÷ Firmware data size transmitted in a single upgrade frame. When the total firmware size cannot be divided evenly by the firmware data size transmitted in a single upgrade frame, the calculation result can be rounded up so that the last bit of data that is less than one complete upgrade frame still corresponds to one upgrade frame.

[0096] Furthermore, the remaining upgrade frames can be determined according to the following relationship: Remaining upgrade frames = Total number of upgrade frames - Current upgrade frame sequence number. In this way, the remaining upgrade frames can reflect the current actual upgrade progress of the target firmware upgrade task.

[0097] Step S602: Determine the average transmission rate based on the number of upgrade frames sent and the corresponding transmission duration of the target firmware upgrade task, and determine the redundancy coefficient based on the number of repeatedly sent upgrade frames and the current upgrade frame sequence number.

[0098] The average transmission rate can be defined as the average number of upgrade frames that the target firmware upgrade task can send per unit time within the executed time range. The number of duplicated upgrade frames can be defined as the number of upgrade frames retransmitted due to incorrect reception, failure to receive the expected response, or other communication anomalies. The redundancy factor can be used to characterize the additional transmission overhead caused by factors such as duplicate transmissions during firmware data transmission.

[0099] In this embodiment, the average transmission rate can be determined based on the ratio between the number of upgrade frames sent in the target firmware upgrade task and the corresponding transmission duration. For example, the average transmission rate = number of upgrade frames sent ÷ transmission duration. For instance, if 10 upgrade frames have been sent within 10 seconds, the average transmission rate can be 1 frame / second.

[0100] Furthermore, the redundancy coefficient can be determined based on the ratio of the number of repeatedly sent upgrade frames to the current upgrade frame sequence number. For example: Redundancy coefficient = 1 + number of repeatedly sent upgrade frames ÷ current upgrade frame sequence number.

[0101] When there are no duplicate upgrade frames, the redundancy factor can be 1; as the number of duplicate upgrade frames increases, the redundancy factor increases accordingly, thus reflecting the additional data transmission overhead in the current communication environment.

[0102] Optionally, when the firmware upgrade task has just started and no valid current upgrade frame sequence number or valid transmission statistics have been formed, the preset initial value or parameters corresponding to the historical transmission status can be used temporarily. After obtaining sufficient real-time transmission data, the corresponding parameters can be updated according to the actual data.

[0103] Step S603: Determine the waiting time based on the preset basic waiting time, the remaining upgrade frames, the average transmission rate, and the redundancy coefficient.

[0104] The base waiting time can be an additional base time set beyond the estimated transmission time based on the remaining firmware data, used to reserve time for task completion processing, communication response delays, or other uncertain communication time consumption.

[0105] In this embodiment, the theoretical transmission time required for the target firmware upgrade task to send the remaining firmware data can be estimated based on the remaining upgrade frames and the average transmission rate. Then, the theoretical transmission time is corrected by the redundancy coefficient, and the final waiting time is obtained by combining it with the basic waiting time.

[0106] For example, the waiting time T can be determined according to the following relationship: T = base waiting time + (remaining upgrade frames ÷ average transmission rate) × redundancy coefficient.

[0107] For example, if the complete firmware size is 1,048,576 bytes, and a single upgrade frame carries 256 bytes of firmware data, then the entire firmware corresponds to 4,096 upgrade frames. If the current upgrade frame sequence number is 100, then the remaining upgrade frames are 3,996. Assuming the current average transmission rate is 1 frame / second, and one upgrade frame has already been duplicated, the redundancy factor can be determined as 1 + 1 ÷ 100, which is 1.01. If the basic waiting time is set to 60 seconds, then the waiting time can be calculated as: T = 60 + (3996 ÷ 1) × 1.01 ≈ 4095.96 seconds. In practical applications, the above waiting time can be rounded according to the system timing accuracy, for example, determined to be 4096 seconds.

[0108] It should be noted that the specific values ​​mentioned above are only used to explain the process of determining the waiting time and do not constitute a limitation on the complete firmware size, the size of a single frame of firmware data, the basic waiting time, or the data transmission rate.

[0109] When network communication is good and there are basically no duplicate upgrade frames, the redundancy coefficient is small, and the waiting time is mainly determined by the amount of remaining firmware data and the transmission rate of the target firmware upgrade task. When communication is poor and there are many duplicate upgrade frames, the redundancy coefficient increases and the waiting time is correspondingly extended.

[0110] Therefore, compared with using a fixed waiting time, this embodiment can dynamically estimate the remaining time that may occupy communication resources based on the actual remaining data volume, actual transmission efficiency and retransmission status of the target firmware upgrade task, so that the waiting time is more in line with the current actual upgrade status.

[0111] In one possible implementation, a specific process is described that controls the current firmware upgrade task to stop during the execution of a high-priority firmware upgrade task and resumes execution after certain conditions are met. The specific implementation process is as follows: Step S701: After stopping the current firmware upgrade task, continuously monitor upgrade frames in the communication network.

[0112] Continuous monitoring can be used to continuously acquire communication data according to the data receiving mechanism of the communication network while the current firmware upgrade task is in a stopped state, and identify the upgrade frame corresponding to the target firmware upgrade task from it.

[0113] In this embodiment, when the priority of the target firmware upgrade task is determined to be higher than that of the current firmware upgrade task based on task priority, the upgrade control module stops the current firmware upgrade task from sending firmware data and enters a waiting state while continuing to monitor the communication network.

[0114] The monitored upgrade frames can be matched with the target firmware upgrade task based on the source device type, target device address, and other information that can distinguish the firmware upgrade task. For example, if the target firmware upgrade task is a firmware upgrade task initiated by the debugger for the second indoor unit, the upgrade frame whose source device type represents the debugger and whose target device address represents the second indoor unit can be identified as the upgrade frame corresponding to the target firmware upgrade task.

[0115] Step S702: When an upgrade frame corresponding to the target firmware upgrade task is detected, maintain the stopped state of the current firmware upgrade task and restart the waiting timer.

[0116] Among them, restarting the waiting time can be done by restarting the continuous undetected time used to determine whether the target firmware upgrade task has stopped sending firmware data.

[0117] In this embodiment, after the current firmware upgrade task stops, a timer corresponding to the waiting duration can be set. When an upgrade frame corresponding to the target firmware upgrade task is detected, it indicates that the target firmware upgrade task is still transmitting firmware data, and therefore the current firmware upgrade task cannot be resumed.

[0118] At this point, the current firmware upgrade task can remain stopped, and the waiting time can be restarted from the moment the upgrade frame corresponding to the target firmware upgrade task is detected. Therefore, "not detected within the waiting time" means that there needs to be a continuous waiting time during which the upgrade frame corresponding to the target firmware upgrade task is not detected again, rather than forcibly resuming after a fixed countdown once when the current firmware upgrade task is first stopped.

[0119] Optionally, upon detecting a new upgrade frame corresponding to a new target firmware upgrade task, the waiting time can be re-determined based on the latest upgrade progress and current data transmission status reflected in the upgrade frame. In the case of re-determining the waiting time, timing can be restarted according to the updated waiting time, allowing the recovery decision to further adapt to the real-time changes of the target firmware upgrade task.

[0120] For example, if a change in the current upgrade frame sequence number of the target firmware upgrade task is detected during the waiting process, or if a new duplicate transmission is detected, the remaining upgrade frame count, average transmission rate, or redundancy coefficient can be updated, and the waiting time can be re-estimated based on the updated parameters.

[0121] Step S703: If no upgrade frame corresponding to the target firmware upgrade task is detected within the continuous waiting period, resume the execution of the current firmware upgrade task.

[0122] The continuous waiting time can be a continuous time interval calculated from the last detected upgrade frame corresponding to the target firmware upgrade task.

[0123] In this embodiment, if no upgrade frame corresponding to the target firmware upgrade task is detected within the continuous time interval, it can be considered that the target firmware upgrade task has ended firmware data transmission, or at least has released the communication resources required by the current firmware upgrade task. The upgrade control module can release the stopped state of the current firmware upgrade task, allowing the current firmware upgrade task to resend firmware data to the communication network.

[0124] If the firmware upgrade task was stopped but the upgrade progress was recorded, the firmware upgrade task can continue to execute based on the current upgrade frame sequence number or the current firmware data transmission position recorded before the stop. For example, if the current firmware upgrade task has completed the transmission of the first 300 upgrade frames, it can continue to transmit subsequent upgrade frames after resumption, without having to retransmit the first 300 completed upgrade frames.

[0125] For example, if the central controller is performing a background indoor unit firmware upgrade task and detects a higher-priority firmware upgrade task initiated by the debugger, the central controller will stop sending current firmware data and determine the waiting time based on the actual upgrade status of the debugger's firmware upgrade task. Each time the debugger sends a new upgrade frame, the central controller remains in a stopped state and restarts the continuous waiting timer; only when the corresponding upgrade frame from the debugger is not detected for the corresponding waiting time will the central controller resume the original firmware upgrade task.

[0126] As described above, this embodiment reduces data collisions and upgrade interference caused by multiple upgrade initiating devices simultaneously occupying relevant communication resources by arbitrating the priority of upgrade initiating devices and upgrade targets among multiple firmware upgrade tasks and stopping low-priority tasks when high-priority tasks occur. By dynamically determining the waiting time based on the remaining number of upgrade frames, average transmission rate, and retransmission status, and using the continuous absence of detected high-priority upgrade frames as the recovery condition, the matching degree between the recovery timing of low-priority tasks and the actual communication status can be improved. At the same time, by using different communication paths when the centralized controller upgrades the outdoor unit and the wired controller upgrades the corresponding indoor unit to execute the corresponding upgrade tasks in parallel, unnecessary task waiting can be reduced, and the overall firmware upgrade time of multiple devices in the multi-split system can be shortened, thereby balancing the reliability and upgrade efficiency of the firmware upgrade process.

[0127] Figure 2This flowchart illustrates another firmware upgrade method for a multi-split air conditioning system provided in this application embodiment. Taking an example where a central controller, wired controller, and debugger simultaneously possess firmware upgrade capabilities for both indoor and outdoor units, the firmware upgrade process in the multi-split air conditioning system is explained. The central controller and wired controller can obtain the firmware to be upgraded from the server, while the debugger can obtain the firmware file locally. Each upgrade initiating device transmits firmware data by sending upgrade frames. The upgrade frame may include the source device type, target device address, total firmware size, current upgrade frame number, and current firmware data.

[0128] In this embodiment, the central controller and the wired controller listen for upgrade frames in the communication network when performing a firmware upgrade task. When an upgrade frame with a debugger as the source device type is detected, since the firmware upgrade task corresponding to the debugger has a higher priority, the central controller and the wired controller stop sending the current firmware data and determine the waiting time based on the remaining number of upgrade frames, average transmission rate, and retransmission status of the debugger firmware upgrade task. If no upgrade frame corresponding to the debugger is detected within the continuous waiting time, the original firmware upgrade task is resumed.

[0129] When no firmware upgrade task corresponding to the debugger is detected, coordination can be performed based on the upgrade targets of the central controller and the wired controller. When both are upgrading the outdoor unit, the central controller will prioritize the outdoor unit upgrade; when both are upgrading the indoor unit, the wired controller will prioritize the indoor unit upgrade; when the central controller is upgrading the outdoor unit and the wired controller is upgrading the corresponding indoor unit, the two firmware upgrade tasks can be executed in parallel using different communication paths to reduce task waiting and improve overall upgrade efficiency.

[0130] Figure 3 This application provides a structural diagram of a firmware upgrade system for a multi-split air conditioning system. The multi-split system includes an outdoor unit, multiple indoor units, a central controller, a debugger, and multiple wired controllers corresponding to each indoor unit. The outdoor unit, multiple indoor units, the central controller, and the debugger are connected to a first communication network. Each indoor unit is connected to a wired controller, and each wired controller communicates with its corresponding indoor unit through a second communication network. For example, indoor unit 1 is connected to wired controller 1, indoor unit 2 is connected to wired controller 2, and indoor unit n is connected to wired controller n.

[0131] In this embodiment, the centralized controller and debugger can interact with the indoor or outdoor unit via a first communication network to initiate firmware upgrade tasks for the indoor or outdoor unit; the wired controller can send firmware data to the corresponding indoor unit via a second communication network. When the wired controller needs to upgrade the outdoor unit, it can first send the firmware data to the corresponding indoor unit via the second communication network, and then the indoor unit forwards the firmware data to the outdoor unit via the first communication network. Thus, different upgrade initiating devices can transmit firmware data to the corresponding upgrade targets based on their respective communication paths, providing a network foundation for subsequent priority arbitration and parallel upgrades for multiple firmware upgrade tasks.

[0132] Figure 4 A structural diagram of a firmware upgrade device for a multi-unit system provided in this application embodiment includes: The determination module 41 is used to obtain upgrade task information of multiple firmware upgrade tasks in the multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information. The first control module 42 is used to stop the current firmware upgrade task when a target firmware upgrade task with a higher priority than the current firmware upgrade task is detected during the execution of the current firmware upgrade task, and to determine the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task. The second control module 43 is used to resume the execution of the current firmware upgrade task when no firmware data corresponding to the target firmware upgrade task is detected within the waiting time.

[0133] In one possible implementation, the determining module is specifically used to monitor upgrade frames used for transmitting firmware data in the communication network of the multi-unit system; The source device type and target device address in the upgrade frame are obtained. The device type of the upgrade initiating device for the firmware upgrade task is determined according to the source device type, and the upgrade object of the firmware upgrade task is determined according to the target device address. The device type of the upgrade initiating device and the upgrade object are used as the upgrade task information of the corresponding firmware upgrade task. The upgrade initiating device includes a debugger, a central controller and a wired controller. The upgrade object includes the indoor unit and the outdoor unit in the multi-split air conditioning system.

[0134] In one possible implementation, the determining module is specifically configured to, for any two firmware upgrade tasks among the plurality of firmware upgrade tasks, determine the task priority between the two firmware upgrade tasks based on the device type and upgrade target of the upgrade initiating device in the upgrade task information of the two firmware upgrade tasks, including: When one of the two firmware upgrade tasks is initiated by a debugger and the other is initiated by a central controller or a wired controller, the firmware upgrade task initiated by the debugger has a higher priority than the firmware upgrade task initiated by the central controller or the wired controller. When the two firmware upgrade tasks are initiated by a central controller and a wired controller respectively, if the upgrade target of both firmware upgrade tasks is an outdoor unit, then the firmware upgrade task initiated by the central controller is determined to have a higher priority than the firmware upgrade task initiated by the wired controller. If the upgrade target of both firmware upgrade tasks is an indoor unit, then the firmware upgrade task initiated by the wired controller is determined to have a higher priority than the firmware upgrade task initiated by the central controller.

[0135] In one possible implementation, the multi-split air conditioning system includes an outdoor unit and multiple indoor units. The communication network includes a first communication network and a second communication network. The central controller, the debugger, the multiple indoor units, and the outdoor unit are connected to the first communication network. Each indoor unit is connected to a wired controller. The wired controller communicates with the corresponding indoor unit through the second communication network. The first control module is also used to send firmware data of the corresponding firmware upgrade task to the indoor unit or outdoor unit that is the upgrade target through the first communication network when the upgrade initiating device is the central controller or the debugger. When the upgrade initiating device is a wired controller and the upgrade target is an indoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network. When the upgrade initiating device is a wired controller and the upgrade target is an outdoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network, so that the indoor unit forwards the firmware data to the outdoor unit through the first communication network.

[0136] In one possible implementation, the first control module is further configured to execute the firmware upgrade task initiated by the central controller and the firmware upgrade task initiated by the wired controller in parallel when the upgrade target of the firmware upgrade task initiated by the central controller is the outdoor unit and the upgrade target of the firmware upgrade task initiated by the wired controller is the indoor unit corresponding to the wired controller.

[0137] In one possible implementation, the first control module is specifically used to determine the remaining number of upgrade frames for the target firmware upgrade task based on the complete firmware size corresponding to the target firmware upgrade task, the firmware data size transmitted in a single upgrade frame, and the current upgrade frame sequence number. The average transmission rate is determined based on the number of upgrade frames sent and the corresponding transmission duration of the target firmware upgrade task, and the redundancy coefficient is determined based on the number of repeatedly sent upgrade frames and the current upgrade frame sequence number. The waiting time is determined based on the preset base waiting time, the remaining number of upgrade frames, the average transmission rate, and the redundancy coefficient.

[0138] In one possible implementation, the second control module is specifically configured to continuously monitor upgrade frames in the communication network after stopping the current firmware upgrade task; When an upgrade frame corresponding to the target firmware upgrade task is detected, the current firmware upgrade task remains stopped, and the waiting time is restarted. If no upgrade frame corresponding to the target firmware upgrade task is detected within the specified waiting time, the current firmware upgrade task is resumed.

[0139] The device provided in this embodiment may be as follows: Figure 4 The device shown can perform Figure 1 All steps of the method shown are then implemented. Figure 1 For details on the technical effects of the method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0140] Figure 5 This is a schematic diagram of the structure of a multi-unit air conditioning system provided in an embodiment of this application. Figure 5 The multi-unit device 500 shown includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the multi-unit device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 5 The general designated all buses as Bus System 505.

[0141] The user interface 503 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0142] It is understood that the memory 502 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0143] In some implementations, memory 502 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 5021 and application program 5022.

[0144] The operating system 5021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 5022 includes various applications, such as a media player and a browser, used to implement various application functions. Programs implementing the methods of this application embodiment can be included in application program 5022.

[0145] In this embodiment, by calling the program or instructions stored in memory 502, specifically the program or instructions stored in application program 5022, processor 501 executes the method steps provided in each method embodiment, including, for example: Obtain upgrade task information for multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information; If a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and the waiting time is determined based on the upgrade progress and data transmission status of the target firmware upgrade task. If no firmware data corresponding to the target firmware upgrade task is detected within the waiting period, the current firmware upgrade task is resumed.

[0146] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in processor 501. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 502. Processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method.

[0147] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0148] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0149] The multi-unit equipment provided in this embodiment can be as follows: Figure 5 The device shown can perform, for example Figure 1 All steps of the method, thus achieving Figure 1 For details on the technical effects of the method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0150] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0151] When one or more programs in the storage medium can be executed by one or more processors to implement the above-described method for firmware upgrade of multi-connected systems executed on the device side.

[0152] The processor is used to execute the multi-unit system firmware upgrade program stored in the memory to implement the following steps of the multi-unit system firmware upgrade method executed on the device side: Obtain upgrade task information for multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information; If a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and the waiting time is determined based on the upgrade progress and data transmission status of the target firmware upgrade task. If no firmware data corresponding to the target firmware upgrade task is detected within the waiting period, the current firmware upgrade task is resumed.

[0153] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0154] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0155] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A firmware upgrade method for a multi-unit air conditioning system, characterized in that, include: Obtain upgrade task information for multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information; If a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, the current firmware upgrade task is stopped, and the waiting time is determined based on the upgrade progress and data transmission status of the target firmware upgrade task. If no firmware data corresponding to the target firmware upgrade task is detected within the waiting period, the current firmware upgrade task is resumed.

2. The method according to claim 1, characterized in that, The acquisition of upgrade task information for multiple firmware upgrade tasks in a multi-unit system includes: Monitor upgrade frames used for transmitting firmware data in the communication network of the multi-unit system; The source device type and target device address in the upgrade frame are obtained. The device type of the upgrade initiating device for the firmware upgrade task is determined according to the source device type, and the upgrade object of the firmware upgrade task is determined according to the target device address. The device type of the upgrade initiating device and the upgrade object are used as the upgrade task information of the corresponding firmware upgrade task. The upgrade initiating device includes a debugger, a central controller and a wired controller. The upgrade object includes the indoor unit and the outdoor unit in the multi-split air conditioning system.

3. The method according to claim 2, characterized in that, Determining the task priority among the multiple firmware upgrade tasks based on the upgrade task information includes: For any two firmware upgrade tasks among the plurality of firmware upgrade tasks, the task priority between the two firmware upgrade tasks is determined based on the device type and upgrade target of the upgrade initiating device in the upgrade task information of the two firmware upgrade tasks, including: When one of the two firmware upgrade tasks is initiated by a debugger and the other is initiated by a central controller or a wired controller, the firmware upgrade task initiated by the debugger has a higher priority than the firmware upgrade task initiated by the central controller or the wired controller. When the two firmware upgrade tasks are initiated by a central controller and a wired controller respectively, if the upgrade target of both firmware upgrade tasks is an outdoor unit, then the firmware upgrade task initiated by the central controller is determined to have a higher priority than the firmware upgrade task initiated by the wired controller. If the upgrade target of both firmware upgrade tasks is an indoor unit, then the firmware upgrade task initiated by the wired controller is determined to have a higher priority than the firmware upgrade task initiated by the central controller.

4. The method according to claim 2, characterized in that, The multi-split air conditioning system includes one outdoor unit and multiple indoor units. The communication network includes a first communication network and a second communication network. The central controller, the debugger, the multiple indoor units, and the outdoor unit are connected to the first communication network. Each indoor unit is connected to a wired controller, and the wired controller communicates with the corresponding indoor unit through the second communication network. The method further includes: When the upgrade initiating device is a centralized controller or debugger, the firmware data corresponding to the firmware upgrade task is sent to the indoor or outdoor unit that is the target of the upgrade through the first communication network. When the upgrade initiating device is a wired controller and the upgrade target is an indoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network. When the upgrade initiating device is a wired controller and the upgrade target is an outdoor unit, the firmware data of the corresponding firmware upgrade task is sent to the indoor unit corresponding to the wired controller through the second communication network, so that the indoor unit forwards the firmware data to the outdoor unit through the first communication network.

5. The method according to claim 4, characterized in that, The method further includes: When the firmware upgrade task initiated by the central controller targets the outdoor unit, and the firmware upgrade task initiated by the wired controller targets the indoor unit corresponding to the wired controller, the firmware upgrade task initiated by the central controller and the firmware upgrade task initiated by the wired controller are executed in parallel.

6. The method according to claim 2, characterized in that, The step of determining the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task includes: The remaining number of upgrade frames for the target firmware upgrade task is determined based on the complete firmware size corresponding to the target firmware upgrade task, the firmware data size transmitted in a single upgrade frame, and the current upgrade frame sequence number. The average transmission rate is determined based on the number of upgrade frames sent and the corresponding transmission duration of the target firmware upgrade task, and the redundancy coefficient is determined based on the number of repeatedly sent upgrade frames and the current upgrade frame sequence number. The waiting time is determined based on the preset base waiting time, the remaining number of upgrade frames, the average transmission rate, and the redundancy coefficient.

7. The method according to claim 6, characterized in that, When no firmware data corresponding to the target firmware upgrade task is detected within the waiting period, resuming the execution of the current firmware upgrade task includes: After stopping the current firmware upgrade task, continuously monitor upgrade frames in the communication network; When an upgrade frame corresponding to the target firmware upgrade task is detected, the current firmware upgrade task remains stopped, and the waiting time is restarted. If no upgrade frame corresponding to the target firmware upgrade task is detected within the specified waiting time, the current firmware upgrade task is resumed.

8. A firmware upgrade device for a multi-unit air conditioning system, characterized in that, include: The determination module is used to obtain upgrade task information of multiple firmware upgrade tasks in a multi-unit system, and determine the task priority among the multiple firmware upgrade tasks based on the upgrade task information. The first control module is used to stop the current firmware upgrade task when a target firmware upgrade task with a higher priority is detected during the execution of the current firmware upgrade task, and to determine the waiting time based on the upgrade progress and data transmission status of the target firmware upgrade task. The second control module is used to resume the execution of the current firmware upgrade task when no firmware data corresponding to the target firmware upgrade task is detected within the waiting time.

9. A multi-unit air conditioning system, characterized in that, include: A processor and a memory, the processor being configured to execute a multi-unit system firmware upgrade program stored in the memory to implement the multi-unit system firmware upgrade method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the firmware upgrade method for a multi-unit system according to any one of claims 1 to 7.

Images