Batch upgrade method and device of device firmware, electronic device and storage medium

Abstract

The application relates to the technical field of device upgrading, and discloses a batch upgrading method and device for device firmware, an electronic device and a storage medium, the method comprising the following steps: obtaining upgrading trigger information and a version image of all devices; determining an upgrading reason according to the upgrading trigger information, and determining a candidate device range and a corresponding upgrading mode from all the devices based on the upgrading reason and the version image; performing verification matching on each device in the candidate device range based on an upgrading rule matrix automatically generated in advance according to a firmware package and the version image, to determine target devices to be upgraded, the target devices being at least one; and issuing a firmware package to the target devices according to the upgrading mode and a protocol adaptation scheduling strategy, and performing firmware upgrading. Through a full-process standardization and digitization automatic screening and upgrading scheduling mechanism, the application can improve the accuracy, safety and universality of batch firmware upgrading of Internet of Things devices, and realizes automatic, standardized and refined version control of firmware upgrading of large-scale device clusters.

Description

Technical Field

[0001] This invention relates to the field of equipment upgrade technology, and more specifically to a method, apparatus, electronic device, and storage medium for batch upgrading of equipment firmware. Background Technology

[0002] Firmware upgrades for IoT devices involve multiple dimensions such as device model, hardware module, and version iteration. The device system has complex and differentiated characteristics: the same product model can have multiple unique PID (Product ID) model codes due to product positioning, sales region, hardware configuration, or customer customization. Different PIDs correspond to exclusive adapted firmware and cannot be used interchangeably. At the same time, a single IoT device usually integrates multiple independently upgradable functional modules, and the firmware of each module is independent and upgrades are not compatible with each other.

[0003] Existing firmware batch upgrade version management solutions mostly rely on maintenance personnel to manually select the device scope, choose firmware packages, and upgrade targets. This manual operation is highly subjective and has a low error tolerance, easily leading to problems such as incorrect firmware distribution across different PIDs, incorrect firmware pushes across different modules, and blindly including stable devices that do not require upgrades in the upgrade scope. Furthermore, traditional upgrade solutions often use fixed-condition matching and single-scheduling methods for firmware upgrade operations. This results in a single upgrade trigger scenario, coarse-grained device selection, and an inability to differentiate between different upgrade requests. It is difficult to accurately manage the upgrades of large batches of terminal devices with multiple PIDs, modules, and communication standards, thus failing to meet the refined, secure, and automated firmware batch upgrade maintenance needs of large-scale IoT device clusters. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, and storage medium for batch firmware upgrades of devices, in order to solve the problem that existing device firmware upgrades rely on manual labor and cannot meet the needs of refined, secure, and automated batch firmware upgrade and maintenance.

[0005] In a first aspect, the present invention provides a method for batch upgrading device firmware, the method comprising: acquiring upgrade trigger information and acquiring version profiles of all devices, wherein the version profiles represent a set of device attributes; determining the upgrade reason based on the upgrade trigger information, and determining a range of candidate devices and corresponding upgrade methods from all devices based on the upgrade reason and the version profiles; verifying and matching each device within the candidate device range based on an upgrade rule matrix automatically generated from the firmware package and the version profiles in advance, and determining a target device to be upgraded, wherein there is at least one target device; sending firmware packages to the target device according to the upgrade method and protocol adaptation scheduling strategy, and performing firmware upgrade, wherein the protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transition according to the communication protocol of the target device.

[0006] The batch firmware upgrade method for devices provided by this invention obtains upgrade trigger information and version profiles of all IoT devices, and uses these version profiles to digitally represent the complete attribute characteristics of each device. Then, based on the upgrade trigger information, it determines the corresponding upgrade reason, accurately divides the candidate device range by combining the upgrade reason and the device version profile, and matches the corresponding upgrade method. Furthermore, relying on the upgrade rule matrix automatically generated by the firmware package, it verifies and matches all devices within the candidate range one by one, accurately selecting target devices that meet the upgrade conditions. Finally, combining the preset upgrade method and protocol adaptation scheduling strategy, it completes the firmware package distribution and automated firmware upgrade operation for the target devices. The protocol adaptation scheduling strategy is used to standardize the entire process rules for instruction adaptation transmission and upgrade task status transition based on the device communication protocol. This invention, through a standardized and digitalized automatic screening and upgrade scheduling mechanism, can effectively avoid cross-device and cross-module upgrade errors caused by manual operation. It also achieves accurate differentiation of upgrade scenarios, strict verification of device matching, and unified scheduling of multi-protocol devices, thereby significantly improving the accuracy, security, and universality of batch firmware upgrades for IoT devices, and realizing automated, standardized, and refined version control for firmware upgrades of large-scale device clusters.

[0007] In one optional implementation, the upgrade reason is determined based on the upgrade trigger information, and the candidate device range and corresponding upgrade method are determined from all devices based on the upgrade reason and version profile. This includes: if the upgrade trigger information is an after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list, then the upgrade reason is determined to be a problem-fixing upgrade; the R&D model, product unique model code, fault module, and problem source firmware version range of the devices involved in the after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list are extracted; the version profiles of all devices are matched according to the R&D model, product unique model code, fault module, and problem source firmware version range, and the candidate device range is determined by summarizing and deduplicating; the fault severity level is read from the after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list, and the upgrade method is matched according to the fault severity level as either a forced upgrade or a confirmed upgrade.

[0008] This invention targets problem-repairing upgrade scenarios, precisely limiting multiple types of fault-related upgrade trigger sources. By extracting the equipment's R&D model, unique product model code, fault module, and problem version range, it accurately selects candidate devices. At the same time, it differentiates between two execution methods—forced upgrade and confirmed upgrade—based on the severity of the fault, enabling targeted and graded repair upgrades for faulty devices. This avoids accidental upgrades of irrelevant devices while ensuring that high-risk faulty devices are prioritized for forced repair, thus improving the timeliness and security of iterative repair of equipment faults.

[0009] In one optional implementation, the upgrade reason is determined based on the upgrade trigger information, and the candidate device range and corresponding upgrade method are determined from all devices based on the upgrade reason and version profile. This includes: if the upgrade trigger information is a firmware release order or feature release plan, the upgrade reason is determined to be a new feature update upgrade; the product unique model code, R&D model, module to be upgraded, and target adaptation source version range recorded in the firmware release order or feature release plan are extracted; the version profiles of all devices are matched based on the product unique model code, R&D model, module to be upgraded, and target adaptation source version range, and the candidate device range for new feature update upgrades is determined by summarizing and deduplicating; and the upgrade method is determined to be a confirmed upgrade.

[0010] This invention addresses new feature update scenarios by identifying new feature upgrade scenarios based on firmware release sheets and feature release plans. It filters compatible devices based on product model, R&D model, module, and compatible version range, and uniformly adopts a confirmation upgrade method. This enables precise gray-scale and batch push upgrades of new feature versions, balancing the popularization of new feature iterations with the autonomy of device upgrades. It avoids device compatibility anomalies caused by blindly pushing new feature firmware, thereby improving the stability of feature iteration upgrades and user experience.

[0011] In one optional implementation, the target device to be upgraded is determined by verifying and matching each device within the candidate device range based on the upgrade rule matrix and version profile automatically generated from the firmware package in advance. This includes: sequentially reading each effective upgrade rule in the upgrade rule matrix; for any effective upgrade rule, sequentially performing multi-dimensional hierarchical consistency verification on the version profile of each candidate device within the candidate device range; if all verification items pass the match, the matched device is determined as the target device to be upgraded; otherwise, the process switches to the next effective upgrade rule to continue verification and matching until all verification items pass the match; if all effective upgrade rules fail the match, the candidate device is removed from the candidate device range, and the corresponding reason for not being able to upgrade is stored.

[0012] This invention innovatively adopts a matching logic that iterates through the rule matrix one by one and verifies all devices with a single rule. By cross-verifying candidate devices with multiple effective rules, only devices that fully match are retained as target devices. Devices that fail to match are automatically removed and the reasons for not being able to be upgraded are recorded. This can significantly improve the rigor of device upgrade screening, make upgrades traceable and anomalies recordable, effectively avoid the risks of incorrect upgrades, missed upgrades, and unauthorized upgrades, and improve the compliance and controllability of batch upgrades.

[0013] In one optional implementation, a multi-dimensional hierarchical consistency verification is performed on the version profiles of each candidate device within the candidate device range, including: performing a product unique model code matching verification between the first product unique model code included in the effective upgrade rule and the second product unique model code included in the version profile to determine whether the upgrade is allowed; if the matching is successful, performing a research and development model attribution verification between the first R&D model included in the effective upgrade rule and the second R&D model included in the version profile to determine whether they belong to the same R&D branch or version family; if the matching is successful, performing the following verifications in sequence based on the effective upgrade rule and version profile: module matching verification, rule source version range verification, device communication protocol matching verification, upgrade reason and firmware risk level matching verification, upgrade method compliance verification, and verification of no corresponding module upgrade task in transit.

[0014] This invention constructs a multi-dimensional hierarchical verification mechanism with clear priorities. It first completes hardware access verification through the product's unique model code, then completes verification of R&D branch and version family affiliation through the R&D model, and finally completes full-dimensional compliance verification of modules, versions, protocols, risks, and task status. Through the hierarchical logic of first unique hardware matching, then R&D lineage affiliation, and finally business compliance verification, it can filter out unqualified devices layer by layer, completely eliminate illegal upgrades across models, R&D systems, and non-compliant scenarios, and greatly improve the security and compatibility accuracy of firmware upgrades.

[0015] In one optional implementation, the process of generating the upgrade rule matrix includes: after the R&D personnel upload the firmware package and accompanying description file, reading and parsing the accompanying description file, extracting firmware adaptation information, and generating a draft rule instance; filling and organizing the adaptation information of the draft rule instance according to the verification fields included in the pre-set rule template to obtain standardized rule instances; performing multi-dimensional verification on the standardized rule instances according to the verification logic built into the rule template, the multi-dimensional verification including at least: field integrity verification, consistency verification between the product unique model code and the R&D model, product model mapping verification, and source version and module dependency legality verification; if the verification fails, If an error is detected, an error message will be output and the application will be returned for modification of the accompanying description file. Otherwise, a conflict detection will be performed on the standardized rule instance. The conflict detection includes at least the following: whether there are multiple target versions for the same product's unique model code and the same module; whether the source version ranges overlap; whether the firmware risk level matches the upgrade method; whether the protocol constraints conflict; and whether it affects historically effective upgrade tasks. If a conflict is detected, an error message will be output and the application will be returned for modification of the accompanying description file. Otherwise, the standardized rule instance will be submitted for approval and, after approval, the standardized rule instance will be stored in the database as an effective upgrade rule. Together with the effective upgrade rules already stored in the database, they will form an upgrade rule matrix.

[0016] This invention enables the automated, standardized generation and compliance verification of upgrade rule matrices. Through a full-process mechanism of file parsing, template standardization, multi-dimensional compliance verification, conflict detection, and approval and database entry, it automatically generates and iterates upgrade rule matrices. This ensures the integrity, legality, and conflict-free nature of each upgrade rule, while also adapting to different firmware packages to generate exclusive upgrade rules. It avoids the subjectivity, errors, omissions, and conflicts inherent in manually formulated rules, achieving a standardized, iterative, and controllable upgrade rule system, and providing reliable rule support for precise device matching.

[0017] In one optional implementation, the protocol adaptation scheduling strategy is built upon a unified task state machine and multiple protocol schedulers. Firmware packages are distributed to the target device according to the upgrade method and the protocol adaptation scheduling strategy, and firmware upgrades are performed. This includes: if the upgrade method is a confirmed upgrade, an upgrade confirmation pop-up is sent to the target device, the pop-up containing at least the device name, target version, upgrade reason, estimated time, and precautions; if the user confirms, or if the upgrade method is a forced upgrade, an upgrade task instruction is generated, and the communication protocols supported by the target device are determined; and the adapted protocol scheduler is invoked according to the communication protocol. The protocol scheduler converts upgrade task instructions into executable actions adapted to the communication protocol. These executable actions are compatible with any of the following communication methods: wireless LAN communication, cellular mobile communication, Bluetooth near-field communication, and long-range low-power communication. Based on the communication method adapted to the executable action, the firmware package is sent to the target device, and the task running status is updated in real time based on the task state machine until the firmware upgrade of the target device is completed. The task running status includes: pending matching, pending confirmation, pending delivery, waiting to be woken up, in transmission, pending device execution, successful execution, failed execution, rolled back, and canceled.

[0018] This invention establishes an adaptive scheduling system based on a unified task state machine and a multi-protocol scheduler. It is compatible with four mainstream communication methods: Wi-Fi, cellular mobile communication, Bluetooth near-field communication, and long-range low-power communication. It automatically adapts to the communication differences of different devices to complete command conversion and firmware delivery. Simultaneously, relying on full-dimensional task states, it achieves closed-loop management of the entire upgrade process, distinguishing between confirmed upgrade and forced upgrade logic. It balances upgrade flexibility, compatibility, and reliability, solving the shortcomings of traditional solutions such as fragmented multi-protocol device scheduling, uncontrollable states, and poor adaptability, thus achieving unified batch upgrade scheduling for all types of terminal devices.

[0019] Secondly, the present invention provides a batch firmware upgrade device for devices, comprising: an upgrade information acquisition module for acquiring upgrade trigger information and version profiles of all devices, wherein the version profiles represent a set of device attributes; an upgrade information determination module for determining the upgrade reason based on the upgrade trigger information and determining a range of candidate devices and corresponding upgrade methods from all devices based on the upgrade reason and version profiles; an upgrade device matching module for verifying and matching each device within the candidate device range based on an upgrade rule matrix automatically generated from the firmware package and the version profiles, and determining the target device to be upgraded, wherein there is at least one target device; and a device upgrade execution module for sending firmware packages to the target device according to the upgrade method and protocol adaptation scheduling strategy, and executing the firmware upgrade, wherein the protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transition according to the communication protocol of the target device.

[0020] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform a batch firmware upgrade method for the device described in the first aspect or any corresponding embodiment.

[0021] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the batch upgrade method of device firmware described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the first process of a batch upgrade method for device firmware according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the overall process of a batch upgrade method for device firmware according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a second process for a batch upgrade method of device firmware according to an embodiment of the present invention; Figure 5This is a schematic diagram of the maintenance and automated generation process of the upgrade rule matrix in the batch upgrade method for device firmware according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the interactive process for maintaining and automatically generating the upgrade rule matrix of the batch upgrade method for device firmware according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the third process of a batch upgrade method for device firmware according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the forced upgrade and confirmation upgrade process of the batch upgrade method for device firmware according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the upgrade scheduling process of the batch upgrade method for device firmware according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the upgrade scheduling interaction process of the batch upgrade method for device firmware according to an embodiment of the present invention; Figure 11 This is a structural block diagram of a batch firmware upgrade device according to an embodiment of the present invention; Figure 12 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0026] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0027] As an optional application scenario of this invention, such as Figure 1As shown, a batch firmware upgrade system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0028] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0029] In the scenario of batch firmware upgrade and maintenance of large-scale IoT device clusters, there are significant differences in device hardware systems, upgrade triggering scenarios, and communication transmission methods. This makes it difficult for traditional manual maintenance and unified fixed upgrade solutions to adapt to actual operational needs. The specific technical pain points are reflected in three core dimensions: hardware adaptation, scenario selection, and communication scheduling.

[0030] At the hardware adaptation level, firmware upgrades for IoT devices exhibit multi-dimensional differences. Firstly, each device possesses a unique PID (Process ID) model code. The same basic product model can generate multiple different PIDs based on product market positioning, sales region division, hardware configuration iterations, and customer customization needs. Each PID corresponds to a dedicated firmware package, and firmware cannot be universally adapted across PIDs. Secondly, a single IoT device has an integrated architecture, typically equipped with multiple functionally independent upgradeable sub-modules such as a main control module, communication module, lock control module, and sensing module. Firmware iterations, function updates, and fault repairs for each module are independent, and there is no universal firmware version. Traditional upgrade operations heavily rely on maintenance personnel manually identifying device models, selecting upgrade scopes, and matching firmware packages with upgrade modules. Manual identification is highly subjective, has a low error tolerance, and is difficult to scale up, easily leading to problems such as incorrect firmware distribution across PIDs, incorrect firmware pushes across modules, and the blind inclusion of unstable devices in the upgrade scope, causing upgrade failures, functional abnormalities, or even device downtime.

[0031] In terms of upgrade scenarios and device selection, IoT device firmware upgrades are mainly divided into two core scenarios: bug fix upgrades and new feature update upgrades. These two scenarios differ significantly in their upgrade requirements, selection logic, and execution needs. For large-scale deployed IoT devices, using real-time full log analysis and automatic anomaly code identification to screen faulty upgrade devices incurs extremely high implementation costs. Furthermore, the identification accuracy is easily affected by external factors such as inconsistent log formats, unstable data reporting frequencies, and fluctuating on-site communication conditions, making it unstable for batch bug fix upgrade scenarios. Therefore, a more feasible implementation approach in the industry is to rely on structured business data such as after-sales work orders, faulty batch device lists, version issue lists, gray-scale verification failure records, customer feedback lists, and manually confirmed device lists as core inputs for determining upgrade reasons and locking in the upgrade scope. The system then automatically matches the precise range of upgradable devices based on the device's own attributes. This avoids the technical shortcomings and cost pressures of full log analysis and adapts to the differentiated selection needs of the two different upgrade scenarios.

[0032] At the communication scheduling and firmware transmission level, the communication protocols, connection mechanisms, wake-up logic, and transmission links of different IoT terminal devices vary greatly. The mainstream communication methods include four categories: wireless LAN communication, cellular mobile communication, Bluetooth near-field communication, and long-range low-power communication. The operating characteristics of each communication mode are completely different. Among them, wireless LAN devices are mostly in a persistent long-term connection state and can respond to upgrade commands at any time; cellular mobile communication devices are mostly intermittent short-term connections and can only receive commands and transmit data within a fixed wake-up window; Bluetooth near-field communication devices only support direct interaction with the APP at close range and cannot complete firmware delivery and command scheduling at long distances; long-range low-power communication door lock devices do not have a direct network link and need to rely on a gateway to complete command forwarding and device wake-up. Traditional upgrade systems often use a unified and fixed firmware distribution and scheduling logic, without making differentiated adaptations for the characteristics of different communication methods. This can easily lead to various upgrade anomalies: short-connection devices miss the limited upgrade wake-up window, causing upgrade tasks to fail; Bluetooth devices cannot obtain the adapted firmware package due to long-distance link anomalies; and long-distance low-power communication devices cannot complete effective routing matching through the gateway, resulting in target device scheduling failure. Overall, the success rate and compatibility of batch upgrades are extremely low.

[0033] Based on the aforementioned multi-dimensional technical pain points, this invention provides a batch upgrade method for device firmware. It proposes a batch upgrade scheme with layered screening, rule matrix verification, and multi-protocol differentiated scheduling. Through a full-process mechanism of digital version profiling, dual-scenario precise screening, hierarchical compliance verification, and protocol adaptive scheduling, it has achieved the technical effect of solving core problems such as mismatch, missed upgrades, scheduling failures, and poor adaptability in the batch upgrade process of firmware for large-scale IoT devices, and realizing the technical effect of automated, standardized, and refined version control of firmware upgrades for large-scale device clusters.

[0034] According to an embodiment of the present invention, a method for batch upgrading device firmware is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] This embodiment provides a method for batch upgrading device firmware, which can be used in the aforementioned mobile terminals, such as computers. Figure 2 This is a flowchart of a batch firmware upgrade method for devices according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain upgrade trigger information and version profiles of all devices. The version profile represents the set of attributes of the device.

[0036] Specifically, in this embodiment of the invention, the upgrade trigger information is the source data that triggers a batch firmware upgrade task, used to identify the reason for initiating this upgrade task and the basis for the basic upgrade scope. The upgrade trigger information can be any business information that can initiate the firmware upgrade process, such as upgrade commands initiated manually in the background, new firmware release tasks, device anomaly feedback records, version iteration plans, etc. After receiving the upgrade trigger information, the system creates an upgrade task, such as... Figure 3 As shown.

[0037] At the same time, such as Figure 3 As shown, the system has pre-generated and stored version profiles for all IoT devices in the entire network based on the device master data. A version profile is a structured and digital representation of all static attributes, dynamic attributes, and firmware status information of a single IoT device, uniquely corresponding to one device and comprehensively depicting the device's hardware identity, firmware status, and device capabilities. In this embodiment, the device version profile may include attribute data such as the device's unique identifier (PID), the product model to which the device belongs, the device's hardware configuration attributes, the currently running firmware version, the types of upgradable functional modules, the communication methods supported by the device, the device's online status, and historical upgrade records. By uniformly constructing device version profiles, the backend system possesses the ability to digitally perceive all devices in the network, providing a data foundation for subsequent automatic screening and matching upgrades, replacing the traditional manual method of reviewing device ledgers and manually verifying versions.

[0038] Step S202: Determine the upgrade reason based on the upgrade trigger information, and determine the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and version profile.

[0039] Specifically, in this embodiment of the invention, different upgrade trigger information corresponds to different upgrade reasons. The upgrade reason is used to distinguish the business purpose of this upgrade, enabling the system to differentiate the range of devices and match reasonable upgrade execution logic based on the upgrade requirements. This embodiment of the invention categorizes upgrade reasons into problem-fixing upgrades and new feature update upgrades, thereby matching corresponding IoT devices according to different upgrade reasons.

[0040] In some optional implementations, after obtaining the upgrade trigger information, the system first analyzes the upgrade reason corresponding to this upgrade to clarify whether the upgrade is for a different upgrade request, such as a fault repair iteration or a version feature iteration. Subsequently, the system combines the version profile data of all devices in the network and, based on the upgrade compatibility conditions corresponding to the upgrade reason, initially filters and categorizes a range of candidate devices from all devices. It can be seen that the range of candidate devices is a set of devices that theoretically meet the adaptation conditions for this firmware upgrade, obtained from the initial screening. This pool of devices, coarsely screened from all devices in the network, awaits further verification, avoiding indiscriminate upgrades to all devices in the network.

[0041] Meanwhile, this invention matches the corresponding upgrade method according to the upgrade request. The upgrade method represents the interactive form of firmware delivery to the terminal device and the execution of the upgrade, including two types: forced upgrade and confirmed upgrade. This is used to adapt to the security level and operation and maintenance requirements of different upgrade scenarios, so that the upgrade execution method matches the purpose of this upgrade. Among them, forced upgrade is mainly used in high-risk fault repair upgrade scenarios. For devices with security vulnerabilities or operational failures, the system does not need to wait for manual confirmation from the user. After the device communication link is connected and the device is woken up and online, the system directly delivers the firmware package and starts the upgrade process, thereby eliminating device failures and security risks as soon as possible and ensuring the overall operational security of the device cluster. Confirmed upgrade is mostly used in upgrade scenarios for new feature iteration and performance optimization. The system first pushes an upgrade pop-up window to the target device, displaying the device name, new version information, upgrade reason, estimated time, and related precautions. Only after receiving the user's confirmation instruction will the firmware delivery and upgrade task be initiated, fully respecting the user's right to choose and avoiding unnecessary upgrades from interfering with normal use.

[0042] Step S203: Based on the upgrade rule matrix and version profile automatically generated from the firmware package in advance, verify and match each device in the candidate device range to determine the target device to be upgraded. There is at least one target device.

[0043] Specifically, in this embodiment of the invention, the automatically selected candidate device range is only a preliminary screening result, and there are uncertainties such as some device models not matching, version incompatibility, and operating status not meeting the upgrade conditions. Therefore, the system needs to rely on the standardized constraint rules built into the upgrade rule matrix to perform compliance verification and matching judgment on the version profile of each device in the candidate device range.

[0044] Among them, such as Figure 3 As shown, in this embodiment of the invention, the firmware list of the released firmware package is automatically parsed in advance, and a draft rule matrix is ​​automatically generated and constructed in conjunction with the device version profile and pre-set rule templates. After conflict and missing item detection (if the detection fails, it is returned to R&D / testing for correction), and approval, a standardized set of rules is obtained, which serves as the upgrade rule matrix. It can be seen that the upgrade rule matrix is ​​a comprehensive rule library that adapts to the current firmware package's compatibility range and upgrade constraints. It is used to uniformly standardize the legitimate upgrade targets of this firmware through multi-dimensional consistency verification, such as... Figure 3 As shown, if the multidimensional consistency check fails, the firmware upgrade will be blocked and the reason will be explained; if it passes, the firmware upgrade task will be executed.

[0045] In this embodiment of the invention, a standardized verification mechanism based on a rule matrix is ​​used to perform a refined secondary verification on the candidate devices after coarse screening. Devices that do not meet firmware adaptation specifications or upgrade prerequisites are eliminated. Finally, target devices that fully meet the upgrade conditions and can safely perform firmware iteration are accurately selected. The target devices are the final set of officially selected devices to be upgraded, with a minimum of one device. Therefore, this invention, through a two-stage device screening logic of "coarse screening followed by fine verification," can significantly avoid the risks of mismatch, omission, and erroneous upgrades caused by manual screening, ensuring the accuracy and security of batch upgrades.

[0046] Step S204: Send the firmware package to the target device according to the upgrade method and protocol adaptation scheduling strategy, and perform firmware upgrade. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status flow according to the communication protocol of the target device.

[0047] Specifically, in this embodiment of the invention, the protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task state transition according to the communication protocol of the target device. It is pre-built based on a unified task state machine and multiple protocol schedulers, thereby enabling differentiated and adaptive upgrade scheduling and management of IoT devices with different communication standards.

[0048] In some alternative implementations, such as Figure 3As shown, after passing the multi-dimensional consistency verification, firmware data packets need to be sent to the target device for firmware upgrade. However, different IoT devices are equipped with different communication link types, and their connection mechanisms, wake-up methods, transmission latency, and communication link stability vary significantly. Therefore, this embodiment of the invention does not adopt a unified and fixed firmware delivery method. Instead, it relies on a protocol adaptation scheduling strategy to adaptively match the corresponding protocol scheduler according to the actual communication protocol capabilities of each target device. This completes the upgrade task instruction conversion, data transmission adaptation, and full-process status flow control of the upgrade task, achieving compatibility between upgrade task instructions, firmware data packets, and device communication standards.

[0049] Meanwhile, this invention matches the corresponding upgrade method according to the upgrade request. The upgrade method represents the interactive form of firmware delivery to the terminal device and the execution of the upgrade, including two types: forced upgrade and confirmed upgrade. This is used to adapt to the security level and operation and maintenance requirements of different upgrade scenarios, so that the upgrade execution method matches the purpose of this upgrade. Among them, forced upgrade is mainly used in high-risk fault repair upgrade scenarios. For devices with security vulnerabilities or operational failures, the system does not need to wait for manual confirmation from the user. After the device communication link is connected and the device is woken up and online, the system directly delivers the firmware package and starts the upgrade process, thereby eliminating device failures and security risks as soon as possible and ensuring the overall operational security of the device cluster. Confirmed upgrade is mostly used in upgrade scenarios for new feature iteration and performance optimization. The system first pushes an upgrade pop-up window to the target device, displaying the device name, new version information, upgrade reason, estimated time, and related precautions. Only after receiving the user's confirmation instruction will the firmware delivery and upgrade task be initiated, fully respecting the user's right to choose and avoiding unnecessary upgrades from interfering with normal use.

[0050] This invention relies on a unified task state machine to monitor, record, and update the upgrade task running status of each device throughout the entire process, covering the entire lifecycle from task generation, firmware distribution, device execution to task completion. Ultimately, it automatically completes the batch firmware upgrade operation for all target devices and writes back the results, thereby achieving unified, stable, and differentiated batch upgrade scheduling for multiple types of heterogeneous IoT devices.

[0051] The batch firmware upgrade method for devices provided by this invention obtains upgrade trigger information and version profiles of all IoT devices, and uses these version profiles to digitally represent the complete attribute characteristics of each device. Then, based on the upgrade trigger information, it determines the corresponding upgrade reason, accurately divides the candidate device range by combining the upgrade reason and the device version profile, and matches the corresponding upgrade method. Furthermore, relying on the upgrade rule matrix automatically generated by the firmware package, it verifies and matches all devices within the candidate range one by one, accurately selecting target devices that meet the upgrade conditions. Finally, combining the preset upgrade method and protocol adaptation scheduling strategy, it completes the firmware package distribution and automated firmware upgrade operation for the target devices. The protocol adaptation scheduling strategy is used to standardize the entire process rules for instruction adaptation transmission and upgrade task status transition based on the device communication protocol. This invention, through a standardized and digitalized automatic screening and upgrade scheduling mechanism, can effectively avoid cross-device and cross-module upgrade errors caused by manual operation. It also achieves accurate differentiation of upgrade scenarios, strict verification of device matching, and unified scheduling of multi-protocol devices, thereby significantly improving the accuracy, security, and universality of batch firmware upgrades for IoT devices, and realizing automated, standardized, and refined version control for firmware upgrades of large-scale device clusters.

[0052] This embodiment provides a method for batch upgrading device firmware, which can be used in the aforementioned mobile terminals, such as computers. Figure 4 This is a flowchart of a batch firmware upgrade method for devices according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps: Step S401: Obtain upgrade trigger information and version profiles for all devices. Each version profile represents a set of device attributes. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0053] Step S402: Determine the upgrade reason based on the upgrade trigger information, and determine the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and version profile.

[0054] Specifically, step S402 includes: Step S4021: If the upgrade trigger information is an after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list, then the upgrade reason is determined to be a problem-fixing upgrade.

[0055] Specifically, in this embodiment of the invention, considering that traditional solutions rely on maintenance personnel to manually screen faulty devices, manual screening is extremely inefficient in scenarios with a large number of IoT devices, and is prone to missing faulty devices and incorrectly selecting normal devices; at the same time, the severity of faults varies, and a unified upgrade mode cannot take into account both security and user experience, this embodiment of the invention replaces manual screening by automatically identifying the source of upgrade services, automatically delineating the pool of faulty devices, and matching upgrade execution modes in a hierarchical manner, thereby achieving targeted and hierarchical upgrades of faulty devices.

[0056] In some optional implementations, to differentiate between bug fix upgrades and new feature update upgrades, separate processing is performed based on the significant differences in device selection logic and upgrade control intensity between the two types of upgrades. For bug fix upgrades, the system parses the data type of the upgrade trigger information passed from the front end and matches it with a preset fault type data source identifier. If the trigger source belongs to any one of the following categories: after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list, the upgrade is determined to be a bug fix upgrade.

[0057] For example, after-sales customer service entering work orders for 100 door locks with lock body jamming faults, R&D outputting a list of problematic versions of version V1.2 with communication disconnection defects, and blue screen failure records of 50 devices after upgrading during gray-scale testing, will all be identified as trigger sources for problem-fixing upgrades. By analyzing whether the upgrade cause is a problem-fixing upgrade, the fault repair scenario can be quickly distinguished, providing a basis for subsequent accurate extraction of faulty device characteristics and hierarchical management of upgrade modes.

[0058] Step S4022: Extract the R&D model, unique product model code, fault module, and firmware version range of the equipment involved in the after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported equipment list.

[0059] Specifically, in this embodiment of the invention, the upgrade trigger information includes device-related information. However, the storage formats of various fault data sources are not uniform, and the constraints of faulty devices are scattered throughout the documents. Therefore, it is necessary to uniformly extract the core filtering fields to complete batch matching with the device version profile. The system has a built-in structured parsing template that reads key fields for different types of documents and uniformly extracts four types of core constraints: R&D model, PID, the hardware module that failed, and the start and end version range of the defective firmware. For example, a certain after-sales work order records the PID of the faulty device as PID008, the R&D model as KD-S10, the faulty module as a lock control module, and the fault version range as V2.0~V2.3. The system automatically captures these four constraint parameters. By standardizing and unifying the filtering conditions of various fault documents, the matching obstacles caused by the differences in the formats of different business documents can be eliminated, and unified access and matching of multi-source data can be achieved.

[0060] Step S4023: Match the version profiles of all devices based on the R&D model, product unique model code, fault module and problem source firmware version range, summarize and deduplicate to determine the range of candidate devices that need to be upgraded for problem fix.

[0061] Specifically, in this embodiment of the invention, a single device may appear in multiple fault work orders and multiple problem lists simultaneously. Direct matching would result in a large number of duplicate devices, causing redundant calculations in subsequent verifications. Simultaneously, only devices matching the fault characteristics are matched, filtering out completely irrelevant devices and narrowing the verification scope. Therefore, the version profiles of all devices stored across the entire network are traversed, and the PID, R&D model, current operating module, and firmware version within the profile are compared with the extracted constraints. Devices that successfully match are temporarily aggregated. After aggregation, the unique identifiers of the devices are deduplicated, and duplicate devices are removed to form a candidate device pool. For example, the lock body module V2.1 device with model PID008 and KD-S10 exists in both after-sales work orders and grayscale failure records. After aggregation, it is automatically merged into a single device data entry and will not participate in subsequent verifications repeatedly. This invention quickly and coarsely screens out all devices with potential faults, eliminating irrelevant devices and reducing system computation; the deduplication mechanism avoids redundant verifications and improves batch processing efficiency.

[0062] Step S4024: Read the severity level of the fault from the after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list or manually imported device list, and match the upgrade method as forced upgrade or confirmed upgrade according to the severity level of the fault.

[0063] Specifically, in this embodiment of the invention, different fault risk levels have different control requirements: high-risk faults require immediate repair to eliminate safety hazards, while minor faults can be upgraded at the user's discretion. Therefore, a single upgrade mode cannot simultaneously address both safety and user needs. Based on this, this embodiment of the invention reads the fault level field marked in the document, classifying it into two levels: high-risk faults and ordinary faults; high-risk faults are matched for mandatory upgrades, while ordinary faults are matched for confirmed upgrades.

[0064] For example, high-risk fault work orders involving door lock malfunctions or security vulnerabilities are matched with a forced upgrade; ordinary faults involving only slight touch button lag are matched with a confirmed upgrade. It is evident that this embodiment of the invention can achieve differentiated upgrade management based on fault classification, automatically and forcibly repairing high-risk faults to reduce equipment security risks, while retaining the user's right to choose for minor faults, thus balancing operational safety and user experience.

[0065] Step S403: Based on the upgrade rule matrix and version profile automatically generated from the firmware package in advance, verify and match each device in the candidate device range to determine the target device to be upgraded. There is at least one target device.

[0066] Specifically, step S403 includes: Step S4031: Read each effective upgrade rule in the upgrade rule matrix in sequence.

[0067] Specifically, in this embodiment of the invention, the determination of the candidate device range is based on a rough screening using fault reports. This method can only identify basic fault characteristics and cannot verify compliance conditions such as firmware compatibility, module dependencies, protocol constraints, and in-transit tasks, which can easily lead to incorrect upgrades across PIDs or modules. Therefore, based on this, this embodiment of the invention relies on a standardized upgrade rule matrix to complete multi-level precise verification, filtering out devices within the rough screening range that do not meet the firmware compatibility specifications.

[0068] The upgrade rule matrix is ​​a set of rules describing the "upgradeable relationship between firmware packages and devices." It consists of two parts: rule templates and rule instances. The rule templates are either pre-configured by the system or jointly maintained by R&D, testing, and operations teams. They define the fields that must be verified (product model, R&D model, PID, module type, source version range, upgrade reason, upgrade method, protocol type, etc.) and the verification logic. The rule instances are automatically generated by the system when the R&D team uploads the firmware package. The system fills in the specific adaptation values ​​for the firmware and the rules take effect after conflict detection and approval.

[0069] In some optional implementations, the upgrade rule matrix contains multiple effective upgrade rules for different PIDs, modules, and versions. Furthermore, the upgrade rule matrix is ​​not entirely maintained manually item by item, but is generated jointly by the firmware package list, device master data, rule templates, and approval processes. Figure 5As shown, the specific generation process includes: Step a1: After the R&D personnel upload the firmware package and the accompanying description file, the accompanying description file is read and parsed to extract firmware adaptation information and generate a draft rule instance.

[0070] Step a2: Fill and organize the adaptation information of the rule instance draft according to the verification fields included in the pre-set rule template to obtain a standardized rule instance.

[0071] Step a3: Perform multi-dimensional verification on the standardized rule instance according to the built-in verification logic of the rule template. The multi-dimensional verification includes at least: field integrity verification, consistency verification between the product unique model code and the R&D model, product model mapping verification, and source version and module dependency legality verification.

[0072] Step a4: If the verification fails, an error message will be output and the process will be returned to modify the accompanying description file. Otherwise, conflict detection will be performed on the standardized rule instance. Conflict detection includes at least the following: whether there are multiple target versions for the same product's unique model code and the same module; whether the source version ranges overlap; whether the firmware risk level matches the upgrade method; whether the protocol constraints conflict; and whether it affects historical upgrade tasks that have already taken effect.

[0073] Step a5: If a conflict is detected, an exception message is output and the corresponding description file is returned for modification. Otherwise, the standardized rule instance is submitted for approval and confirmation. After approval, the standardized rule instance is stored in the database as an effective upgrade rule, which together with the effective upgrade rules already stored in the database constitutes the upgrade rule matrix.

[0074] Specifically, in embodiments of the present invention, such as Figure 5As shown, when R&D personnel upload the firmware installation package to the firmware release platform, they simultaneously upload the accompanying Manifest description file. The system automatically reads this file and parses all the firmware adaptation information recorded in the file through preset parsing fields, including all key parameters such as adaptation PID, R&D model, upgradable module, source version range, target upgrade version, firmware risk level, device communication protocol constraints, and recommended upgrade method. All extracted parameters are temporarily packaged to generate a draft rule instance that has not undergone standardized verification and only aggregates the raw information. For example, if R&D personnel upload a door lock body module V2.4 repair firmware, the accompanying description file records the adaptation PID008, R&D model KD-S10, faulty module as lock body control module, source version V2.0~V2.3, high-risk firmware, and support for WiFi / CAT1 communication; the system automatically reads all the above information and packages it to generate a draft rule instance specific to the lock body module. By automatically capturing the firmware's native adaptation parameters, there is no need for manual input of adaptation conditions, which greatly reduces the labor cost of rule configuration; it ensures that the basic information of the rules is completely consistent with the actual adaptation range of the firmware, avoiding parameter mismatch problems caused by manual input.

[0075] Furthermore, the accompanying description files uploaded by different R&D personnel have inconsistent formats, field orders, and parameter naming, resulting in a disorganized data structure for the rule instance drafts, making them unsuitable for subsequent unified verification and batch device matching. This invention addresses this by standardizing the data structure through a unified rule template, thereby standardizing the rule data format for all firmware and facilitating unified system processing. Specifically, the system has a built-in unified rule template, which predefines all mandatory and optional fields, covering fixed fields such as PID, R&D model, module, source version, target version, risk level, protocol constraints, and upgrade method. The original adaptation information from the generated rule instance draft is filled into the template's preset fields one by one, and default values ​​are added to missing optional fields. Parameter formats are standardized (such as unified version number format and unified communication protocol identifier). After completion, a standardized rule instance with a unified structure and well-organized fields is output. For example, if one R&D description file uses "v2.0" and another uses "V2.0," the template uniformly standardizes it as the string "V2.0." If the description file does not specify optional protocol constraint fields, the template automatically fills in the default value "fully protocol compatible," outputting a standardized rule instance with a completely unified format.

[0076] Simply standardizing the format cannot avoid fundamental errors such as missing parameters, contradictory model logic, and illegal version dependencies. If flawed rules are directly added to the database, it will lead to subsequent device matching errors and widespread anomalies during batch upgrades. Therefore, as... Figure 6 As shown, this embodiment of the invention intercepts errors in basic parameters in advance through multi-layered basic checks, ensuring the rule itself is legal and valid. Specifically, it calls the multi-layered check logic built into the rule template to complete four types of core checks in sequence: ① Field integrity verification: Check whether all required fields such as PID, module, source version, and target version exist and have no empty values; ②PID and R&D Model Consistency Verification: Verify whether the currently entered PID belongs to the corresponding R&D model to prevent incorrect PID binding across R&D branches; ③ Product Model Mapping Verification: Verify whether the hardware configuration and module corresponding to the PID match, and whether there is any conflict between the model and the module; ④ Source version and module dependency validity verification: Verify that the source version range is logically reasonable (starting version ≤ ending version), the target firmware is compatible with the corresponding module hardware, and there are no version inversion or module incompatibility issues.

[0077] All verification items must pass before proceeding to the next step; failure of any one verification item will result in the standardized rule instance failing verification. For example, if only the R&D model is filled in the rule instance and the PID field is omitted, the field integrity verification will be directly blocked; if PID008 (belonging to the KD-S10 R&D model) is filled in but bound to the R&D model KD-S20, the consistency verification will fail; if the source version is filled in as V2.5~V2.1, the version range is reversed, and the module dependency verification will be blocked.

[0078] Furthermore, the absence of errors in the parameters of a single rule does not guarantee the absence of logical conflicts with existing effective rules in the database. When multiple rules coexist, issues such as matching multiple firmware versions for the same device, contradictory risk control logic, and disruption of historical upgrade tasks are highly likely to arise. Global conflict detection is essential to avoid conflicts between rules. In this embodiment of the invention, when multi-dimensional verification fails, the system displays a clear error message, such as "missing PID field" or "source version range inverted," directly reverting the process to the development team for revision of the accompanying description file. After revision, the above process is repeated. If all multi-dimensional verifications pass, all stored effective rules in the database are retrieved, and global conflict detection is performed, checking each of the five conflict scenarios: ① Under the same PID and the same module, are there two rules configured with different target upgrade versions at the same time? ② Does the source version range of this rule overlap with the source version range of existing effective rules? ③ Issues such as mismatch between risk level and upgrade method, including whether high-risk firmware is configured for confirmed upgrades and low-risk firmware is forcibly upgraded; ④ This rule's communication protocol constraints conflict with existing rule protocol restrictions for the same PID module; ⑤ Will the issuance of the new rules disrupt the ongoing batch upgrade historical tasks?

[0079] If any type of conflict exists, the conflict detection fails. For example, if the database already has a PID008 lock body module that can be upgraded to V2.3, and a new rule configures the PID008 lock body module to be upgraded to V2.4, this constitutes a conflict between multiple versions of the same PID and module; if the existing rule source versions V2.0~V2.3 and the new rule versions V2.1~V2.5 overlap, they will all be blocked by the conflict detection.

[0080] Furthermore, the absence of conflict-free rules only signifies logical legality. Firmware release is a critical operation in production and maintenance, requiring manual review and confirmation by testing and maintenance personnel before it officially takes effect. Multiple approved effective rules are stored uniformly to form a complete rule matrix, providing all adaptation basis for subsequent device verification and matching. Specifically, if any conflict is detected, the system outputs a precise conflict warning, such as "PID008 lock module has multiple target version conflicts; return to R&D to modify the supporting description file and re-loop the above process." If no conflicts are found, the system pushes a standardized rule instance to the testing / maintenance personnel's approval page, displaying complete firmware adaptation scope, risk level, upgrade constraints, and other information. After the approver verifies and confirms, this standardized rule instance is marked as an effective upgrade rule and written to the rule database. All historical effective rules in the database, plus the newly added effective rule, are combined to form a complete upgrade rule matrix, which can be invoked in batch upgrade processes for multi-dimensional and hierarchical consistency verification of candidate devices.

[0081] For example, conflict-free lock module V2.4 rules are pushed to operations and maintenance for approval. After operations and maintenance confirm that the firmware adaptation range is correct, the rules are approved and stored in the database. The existing communication module and sensor module effective rules in the database are merged with this lock module rule to form a complete upgrade rule matrix corresponding to this upgrade task. This embodiment of the invention uses manual approval to conduct a second review of firmware release rules, avoiding the omission of special business scenarios in automated verification. Multiple effective rules are stored in a unified rule matrix, which fully covers all adapted device boundaries of the current firmware package, providing a complete and compliant rule basis for accurate device verification and matching.

[0082] In some optional implementations, since no single effective upgrade rule in the database can cover all devices, this embodiment of the invention retrieves standardized rule instances stored in the database one by one, which are automatically generated and approved by the firmware package, in the order they are entered into the database, and then performs a line-by-line traversal and matching. For example, if the firmware for this fault repair includes two effective rules for adapting to the PID008 lock body module and the PID012 communication module, the system will first read the rule corresponding to PID008, and then read the rule corresponding to PID012.

[0083] Step S4032: For any effective upgrade rule, perform multi-dimensional hierarchical consistency verification on the version profiles of each candidate device within the candidate device range.

[0084] Specifically, in this embodiment of the invention, firmware upgrades have multiple levels of pre-conditions. Upgrades are not allowed if any hardware model, R&D branch, module, version, protocol, or task status is mismatched. Layered verification can filter out unqualified devices layer by layer.

[0085] In some optional implementations, step S4032 above includes: Step b1 performs a product unique model code matching verification between the first product unique model code contained in the effective upgrade rule and the second product unique model code contained in the version profile to determine whether the upgrade is allowed.

[0086] Step b2: If the match is successful, the first R&D model included in the effective upgrade rule and the second R&D model included in the version profile will be checked for R&D model affiliation to determine whether they belong to the same R&D branch or version family.

[0087] Step b3: If the matching is successful, then based on the effective upgrade rules and version profile, the following checks are performed in sequence: matching verification of the module to be upgraded, verification of the rule source version range, verification of the device communication protocol, verification of the upgrade reason and firmware risk level, verification of the compliance of the upgrade method, and verification of no upgrade tasks with the same module in transit.

[0088] Specifically, in this embodiment of the invention, the PID is the core boundary that distinguishes hardware configuration, customer customization, and sales region. Different PID firmwares are not interchangeable, and sending firmware across PIDs will directly cause devices to become unusable or malfunction. Therefore, PID matching is used as the first layer of verification, prioritizing the interception of devices with completely mismatched hardware models. This eliminates the need for subsequent multi-layer verification, significantly reducing system computational power consumption. The PID recorded in the currently effective upgrade rule and the PID stored in the candidate device version profile are extracted and compared for an exact match. If the two sets of PID codes are completely identical, the PID verification is deemed successful, and the process proceeds to the next layer of R&D model verification. If the codes are inconsistent, the device is directly determined not to meet the upgrade conditions, all verification processes under the current rule are terminated, and the next effective rule is switched for matching. This embodiment of the invention uses a unique hardware PID as the first interception threshold, quickly filtering out devices that completely lack firmware adaptation capabilities, thus eliminating the fatal failure of incorrect firmware sending across PIDs at the source. Layered pre-verification reduces a large amount of invalid subsequent verification logic, improving the matching speed for large batches of devices.

[0089] Furthermore, each R&D model corresponds to a set of hardware platforms and underlying driver architectures, and one R&D model can correspond to multiple customized PIDs. Even if the PIDs match, if the devices belong to different R&D branches, the underlying hardware drivers will differ, and firmware operation will still experience compatibility failures. This embodiment of the invention, based on PID matching, performs a secondary verification of the device's R&D lineage affiliation to further narrow down the range of compliant devices: after the PID verification passes, the R&D model carried by the rule and the R&D model in the device version profile are read to determine if they are the same R&D model; if they match, it means the devices belong to the same hardware platform and the same version family, and the R&D model verification passes; if they do not match, it is determined that the device's underlying hardware architecture is incompatible, and the verification of this rule is terminated. By overlaying R&D branch constraints on top of PID hardware boundary verification, upgrade anomalies caused by PID matching but underlying hardware platform incompatibility can be avoided; the layered and progressive verification logic narrows down the pool of compliant devices layer by layer, improving the accuracy of screening.

[0090] Furthermore, PID and R&D model only represent the overall hardware spectrum of the equipment. The equipment contains multiple independent upgradeable modules and also faces multiple business constraints such as version compatibility, communication capabilities, risk control, and task exclusivity. If any one of these constraints is not met, the upgrade cannot be performed. Therefore, based on a match between PID and R&D model, this embodiment of the invention executes the remaining verification items sequentially. If any verification fails, the matching of this rule is terminated. ① Upgradeable module matching verification: Verify whether the currently upgradable modules of the device are consistent with the upgradeable modules specified in the rules, to avoid sending the firmware of module A to module B; ② Rule source version range verification: Check whether the current firmware version of the device falls within the source version range defined by the rule. Only devices within the range are allowed to upgrade. ③ Device communication protocol matching verification: Check whether the WiFi / CAT1 / Bluetooth / LoRa communication standards supported by the device are allowed by the rules and protocol constraints; ④ Verification of the match between the upgrade reason and the firmware risk level: High-risk faulty firmware is only allowed to be used for problem-fixing upgrades and is not allowed to be used for normal function iterations. Control the scenarios in which risky firmware is distributed. ⑤ Upgrade method compliance verification: High-risk firmware can only be configured for forced upgrades, and confirmed upgrades are prohibited to ensure timely repair of security faults; ⑥ Verification of no ongoing upgrade tasks for the same module: Check if there are any unfinished upgrade tasks for the same module on the device to prevent firmware damage caused by multiple concurrent upgrades of the same module.

[0091] Only when all six verifications above pass can the device be deemed to meet all upgrade constraints of this rule. This ensures full coverage of six major business constraints: module, version, communication, risk control, and task mutual exclusion. It comprehensively prevents various anomalies such as cross-module upgrades, version incompatibility, protocol incompatibility, risk control violations, and concurrent upgrade conflicts. The multi-level progressive verification logic filters out unqualified devices layer by layer, ultimately selecting target devices that are fully compliant and can safely perform batch upgrades.

[0092] Step S4033: If all verification items pass the match, the matched device is determined as the target device to be upgraded; otherwise, switch to the next effective upgrade rule to continue verification and matching until all verification items pass the match.

[0093] Specifically, in this embodiment of the invention, a single device may be compatible with multiple rules within the rule matrix. If one rule fails verification, there is still a possibility of matching other rules, and it cannot be directly eliminated. Therefore, if all verifications of a single rule pass, it is directly marked as a target device; if any verification item fails, the next effective rule is read, and the multi-dimensional verification process is repeated. For example, if a device's PID matches the first rule, but the module does not match, the system automatically switches to the second rule for re-verification. If all of the second rule matches, the device is still determined to be a target device. By fully utilizing the cross-matching capability of multiple rules, compliant devices can be erroneously eliminated due to a single rule mismatch, thus improving the completeness of device screening.

[0094] Step S4034: If all effective upgrade rules fail to match, the candidate device is removed from the candidate device range, and the corresponding reason for non-upgrade is stored.

[0095] Specifically, in this embodiment of the invention, some devices that have been coarsely screened into the candidate pool only meet the fault characteristics, but their hardware, version, and task status do not meet the firmware adaptation requirements, making upgrades impossible. Therefore, after traversing all effective rules, if no rule verification passes for a device, the device is removed from the candidate pool, and the specific item of verification failure is recorded as the reason for non-upgradeability and stored in the database for maintenance to trace the problem. For example, if a device belongs to the PID in the fault work order, but there is currently an upgrade task in progress for the same module, and all rule verifications have failed, the system records "there is an incomplete upgrade task for the same module" as the reason for non-upgradeability.

[0096] Step S404: The firmware package is sent to the target device according to the upgrade method and protocol adaptation scheduling strategy, and the firmware upgrade is performed. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transitions based on the target device's communication protocol. For details, please refer to [link to relevant documentation]. Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0097] The batch firmware upgrade method for devices provided by this invention obtains upgrade trigger information and version profiles of all IoT devices, and uses these version profiles to digitally represent the complete attribute characteristics of each device. Then, based on the upgrade trigger information, it determines the corresponding upgrade reason, accurately divides the candidate device range by combining the upgrade reason and the device version profile, and matches the corresponding upgrade method. Furthermore, relying on the upgrade rule matrix automatically generated by the firmware package, it verifies and matches all devices within the candidate range one by one, accurately selecting target devices that meet the upgrade conditions. Finally, combining the preset upgrade method and protocol adaptation scheduling strategy, it completes the firmware package distribution and automated firmware upgrade operation for the target devices. The protocol adaptation scheduling strategy is used to standardize the entire process rules for instruction adaptation transmission and upgrade task status transition based on the device communication protocol. This invention, through a standardized and digitalized automatic screening and upgrade scheduling mechanism, can effectively avoid cross-device and cross-module upgrade errors caused by manual operation. It also achieves accurate differentiation of upgrade scenarios, strict verification of device matching, and unified scheduling of multi-protocol devices, thereby significantly improving the accuracy, security, and universality of batch firmware upgrades for IoT devices, and realizing automated, standardized, and refined version control for firmware upgrades of large-scale device clusters.

[0098] This embodiment provides a method for batch upgrading device firmware, which can be used in the aforementioned mobile terminals, such as computers. Figure 7 This is a flowchart of a batch firmware upgrade method for devices according to an embodiment of the present invention, such as... Figure 7 As shown, the process includes the following steps: Step S701: Obtain upgrade trigger information and version profiles for all devices. Each version profile represents a set of device attributes. For details, please refer to [link to relevant documentation]. Figure 4 Step S401 of the illustrated embodiment will not be described again here.

[0099] Step S702: Determine the upgrade reason based on the upgrade trigger information, and determine the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and version profile.

[0100] Specifically, step S702 includes: Step S7021: If the upgrade trigger information is a firmware release order or a feature release plan, then the upgrade reason is determined to be a new feature update type upgrade.

[0101] Specifically, in this embodiment of the invention, the new feature update upgrade scenario is applicable to batch version iteration driven by firmware release orders or feature release plans. It differs from the aforementioned problem-fixing upgrade in terms of business objectives, device selection logic, and user interaction methods. It needs to be identified and processed separately to avoid mixing with the fault repair process, which would affect the version iteration rhythm and user experience, thus complementing the problem-fixing upgrade scenario.

[0102] Therefore, the system analyzes the source and type of upgrade trigger information. If the trigger source is a formal firmware release order or feature release plan (such as a new version launch plan, quarterly feature update plan, etc.), then the upgrade is determined to be a new feature update type upgrade. For example, if R&D releases a "Smart Door Lock Face Unlock Function Firmware V3.0 Release Order" or operations submits a "2026 Q2 Door Lock Performance Optimization Feature Release Plan," the system will identify both as new feature update type upgrade trigger sources. This embodiment of the invention clearly distinguishes between two types of upgrade scenarios: feature iteration and fault repair. This provides a business basis for subsequent device selection logic and upgrade method matching, ensuring that the new feature version push process and the fault repair process do not interfere with each other.

[0103] Step S7022: Extract the product's unique model code, R&D model, module to be upgraded, and target compatible source version range recorded in the firmware release order or feature release plan.

[0104] Specifically, in this embodiment of the invention, new feature firmware is typically only compatible with specific PIDs, specific R&D branches, specific modules, and specific source version ranges. The firmware release form / plan clearly specifies the compatibility boundaries. Only by extracting these parameters in a structured manner can subsequent automatic matching and filtering be achieved. Therefore, the system reads the pre-filled compatibility fields in the firmware release form or feature release plan and extracts four core parameters: PID, R&D model, module to be upgraded, and target compatible source version range (i.e., which older version devices can be upgraded to the new version). For example, the firmware release form records: compatible PID is PID-008, R&D model is KD-S10, the module to be upgraded is a face recognition module, and the source version is V2.0~V2.5. The system automatically captures the above information as filtering conditions. This embodiment of the invention transforms the unstructured or semi-structured business information in the release form into standardized filtering conditions that can be directly compared with device version profiles, providing basic data for subsequent batch device matching.

[0105] Step S7023: Based on the product's unique model code, R&D model, module to be upgraded, and target compatible source version range, match the version profiles of all devices, summarize and deduplicate to determine the range of candidate devices that need to be upgraded with new features.

[0106] Specifically, in this embodiment of the invention, the new functional firmware only applies to devices that meet the adaptation conditions. It is necessary to quickly filter out devices from the entire network that meet the requirements for PID, R&D model, module, and version, while avoiding duplicate aggregation, reducing the device pool for subsequent verification, and improving processing efficiency. Therefore, the version profiles of all devices in the entire network are traversed, and the PID, R&D model, currently running module, and current firmware version stored in the profiles are compared with the extracted filtering conditions. Devices that successfully match are aggregated into a temporary set; subsequently, the unique identifiers of the devices are deduplicated, and duplicate devices are removed to form the final candidate device range.

[0107] For example, in a batch of 500 KD-S10 door locks, 300 devices with PID-008 and current version V2.3 are matched and grouped. If some of these devices are mentioned in multiple release plans, the system will automatically remove duplicates, ensuring that each device appears only once in the candidate pool. By quickly and in batches identifying all devices that meet the firmware adaptation requirements for the new features and excluding devices that do not meet the requirements for model, module, and version, the computational workload of subsequent rule verification can be significantly reduced, improving the overall execution efficiency of batch upgrade tasks.

[0108] Step S7024: Determine the upgrade method as "confirm upgrade".

[0109] Specifically, in this embodiment of the invention, new feature update upgrades typically do not involve urgent security issues and are considered optimization upgrades that users can choose independently. Using a confirmation-based upgrade method ensures users' right to know and the continuity of device use, avoiding disruptions to normal use due to forced upgrades. Therefore, for new feature update upgrade scenarios, the system defaults to a confirmation-based upgrade method, meaning that a confirmation command from the user is required before the upgrade task is issued. For example, when a face unlock function is pushed out, the system will send an upgrade pop-up to the user's app, stating "Face unlock function added, estimated time 3 minutes, door lock must remain powered during upgrade." Only after the user clicks confirmation will the system officially issue the firmware package. This approach adapts to the user experience needs of new feature update scenarios, avoids forced upgrades interfering with normal use, improves user acceptance, and ensures a smooth rollout of new feature version iterations.

[0110] Step S703: Based on the upgrade rule matrix and version profile automatically generated from the firmware package, verify and match each device within the candidate device range to determine the target device to be upgraded. There must be at least one target device. For details, please refer to [link to details]. Figure 4 Step S403 of the illustrated embodiment will not be described again here.

[0111] Step S704: Send the firmware package to the target device according to the upgrade method and protocol adaptation scheduling strategy, and perform firmware upgrade. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transition according to the communication protocol of the target device.

[0112] Specifically, step S704 above includes: Step S7041: If the upgrade method is confirmed upgrade, an upgrade confirmation pop-up is sent to the target device. The pop-up content includes at least the device name, target version, upgrade reason, estimated time and precautions.

[0113] Specifically, in this embodiment of the invention, IoT devices are divided into four communication standards: WiFi, CAT1, Bluetooth, and LoRa. The transmission logic of long connection, short connection, near-field direct connection, and gateway forwarding is completely different, and a unified distribution method would cause a large number of upgrade failures. At the same time, two interaction modes, forced / confirmed upgrade, are distinguished, and a unified task state machine is used to manage the entire process to achieve unified scheduling of multiple types of devices.

[0114] Firstly, for minor malfunctions and feature optimization upgrades, users need to be informed and confirm them independently. Directly issuing these upgrades would interfere with normal device use. Standardized pop-up windows can fully display upgrade information, reducing user concerns. Therefore, such as Figure 8 As shown, if the upgrade method is "confirm upgrade," the system automatically generates standardized pop-up content based on the firmware release information and pushes it to the mobile app on the bound device. The pop-up displays the device name, new version number, reason for failure / optimization, estimated upgrade time, and precautions such as power outages and network disconnections. In addition, the device side includes triple verification; if any verification fails, the upgrade is abandoned, and the reason for failure (corresponding error code) is reported. The triple verification includes: ① Firmware signature verification: Verify the digital signature of the firmware package to ensure that the firmware comes from a trusted source and has not been tampered with; ② Execution token verification: The exec_token must be bound and matched with the device identifier, firmware identifier, and task identifier; ③ Target version verification: The target version in the firmware package must be consistent with the target_ver declared in the task.

[0115] In step S7042, if the user confirms, or if the upgrade method is a forced upgrade, an upgrade task instruction is generated, and the communication protocol supported by the target device is determined.

[0116] Specifically, in this embodiment of the invention, a confirmed upgrade requires user authorization before the task can be initiated, while a forced upgrade can be executed directly without user confirmation. Simultaneously, the device communication type needs to be identified in advance to provide a basis for differentiated protocol scheduling. Therefore, in a confirmed upgrade scenario, the user confirmation instruction is awaited from the APP, while a forced upgrade does not require waiting. Once the execution conditions are met, a unique upgrade task instruction is generated, and the communication protocol type stored in the device version profile is read. For example, a forced upgrade for a high-risk lock body malfunction generates a task instruction directly without pop-up confirmation, identifying the device as CAT1 cellular communication; a normal function upgrade requires user confirmation before the task is generated.

[0117] Step S7043: Invoke the appropriate protocol scheduler according to the communication protocol, and convert the upgrade task instruction into an executable action that is compatible with the communication protocol based on the protocol scheduler.

[0118] Specifically, in this embodiment of the invention, the command encapsulation, transmission logic, and wake-up mechanism of WiFi, CATI, Bluetooth, and LoRa are incompatible with each other, as shown in the table below:

[0119] Therefore, generic commands cannot be recognized by different devices, requiring a dedicated scheduler to convert command formats and interaction logic. This embodiment of the invention matches the device communication protocol, invokes the corresponding dedicated protocol scheduler, and converts the uniformly formatted upgrade task commands into operation actions that are recognizable and executable by the corresponding communication link.

[0120] For example, such as Figure 9 As shown, for WiFi devices, a long-connection instant notification mode is adopted. After receiving the notification, the device directly pulls the firmware and performs the upgrade.

[0121] For CAT1 cellular devices, tasks are first written into a queue to be pulled. After being actively woken up or waiting for the device to be woken up at a timed interval, the online device pulls and executes the task. The secondary verification of the CAT1 lock includes: whether the current version of the device is still within the range of the source version; whether the PID + R&D model still matches; whether the task is within the validity period; whether the task has been canceled or paused; and whether the device module version still meets the dependency conditions. If any of these conditions are not met, "no task to be executed" is returned, and the task is marked as invalid.

[0122] For Bluetooth devices, relying on the APP's near-field connection, the APP requests upgradeable tasks and bridges the transmission of firmware.

[0123] For LoRa devices, the task is sent to the bound gateway, which wakes up the door lock and completes the firmware transmission through fragment forwarding and response confirmation; the upgrade process of all communication methods is finally summarized in the result write-back stage to achieve unified closed-loop management of the upgrade status.

[0124] Step S7044: The firmware package is sent to the target device based on the communication method adapted to the executable action, and the task running status is updated in real time based on the task state machine until the firmware upgrade of the target device is completed.

[0125] Specifically, in embodiments of the present invention, such as Figure 10 As shown, different communication links have different logic for sending, transmitting, and retrying. Based on this, the execution protocol scheduler generates dedicated executable actions to transmit firmware packages according to the corresponding communication link. Simultaneously, to unify state management, the task state machine synchronously updates the device status: pending delivery, waiting to be woken up, transmitting, successful execution, failed execution, rolled back, etc., monitoring the entire process cyclically until the upgrade is complete. For example, a CAT1 short-connection device stores the firmware task in a queue to be pulled, waiting for the device to be periodically woken up to pull the firmware. The state machine continuously marks "waiting to be woken up," switches to "transmitting" when the device goes online for transmission, and changes to "successful execution" upon upgrade completion. This embodiment of the invention, by adapting to the differentiated transmission logic of four types of communication links, can significantly improve the success rate of batch upgrades for multi-standard devices; the unified task state machine enables visualized management and control of the entire upgrade lifecycle, and abnormal devices can be quickly located.

[0126] The batch firmware upgrade method for devices provided by this invention obtains upgrade trigger information and version profiles of all IoT devices, and uses these version profiles to digitally represent the complete attribute characteristics of each device. Then, based on the upgrade trigger information, it determines the corresponding upgrade reason, accurately divides the candidate device range by combining the upgrade reason and the device version profile, and matches the corresponding upgrade method. Furthermore, relying on the upgrade rule matrix automatically generated by the firmware package, it verifies and matches all devices within the candidate range one by one, accurately selecting target devices that meet the upgrade conditions. Finally, combining the preset upgrade method and protocol adaptation scheduling strategy, it completes the firmware package distribution and automated firmware upgrade operation for the target devices. The protocol adaptation scheduling strategy is used to standardize the entire process rules for instruction adaptation transmission and upgrade task status transition based on the device communication protocol. This invention, through a standardized and digitalized automatic screening and upgrade scheduling mechanism, can effectively avoid cross-device and cross-module upgrade errors caused by manual operation. It also achieves accurate differentiation of upgrade scenarios, strict verification of device matching, and unified scheduling of multi-protocol devices, thereby significantly improving the accuracy, security, and universality of batch firmware upgrades for IoT devices, and realizing automated, standardized, and refined version control for firmware upgrades of large-scale device clusters.

[0127] The batch firmware upgrade device provided in this embodiment is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used above, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0128] This invention provides a batch firmware upgrade device for devices, such as... Figure 11 As shown, the device includes: The upgrade information acquisition module 1101 is used to acquire upgrade trigger information and version profiles of all devices. The version profile represents the set of attributes of the device.

[0129] The upgrade information determination module 1102 is used to determine the upgrade reason based on the upgrade trigger information, and to determine the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and version profile.

[0130] The upgrade device matching module 1103 is used to verify and match each device in the candidate device range based on the upgrade rule matrix and version profile automatically generated in advance according to the firmware package, and to determine the target device to be upgraded. There is at least one target device.

[0131] The device upgrade execution module 1104 is used to send firmware packages to the target device according to the upgrade method and protocol adaptation scheduling strategy, and to perform firmware upgrade. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status flow according to the communication protocol of the target device.

[0132] The batch firmware upgrade system for devices provided in this embodiment of the invention can execute the batch firmware upgrade method for devices provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0133] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0134] The following is a detailed reference. Figure 12The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0135] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 12 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0136] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1209, or installed from a memory 1208, or installed from a ROM 1202. When the computer program is executed by the processor 1201, it performs the functions defined in the batch upgrade method for device firmware of the embodiments of the present invention.

[0137] Figure 12 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0138] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the batch firmware upgrade method of the device shown in the above embodiments is implemented.

[0139] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0140] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for batch upgrading device firmware, characterized in that, The method includes: Obtain upgrade trigger information and version profiles for all devices, whereby the version profiles represent a set of device attributes; The upgrade reason is determined based on the upgrade trigger information, and the candidate device range and corresponding upgrade method are determined from all devices based on the upgrade reason and the version profile. Based on the upgrade rule matrix automatically generated from the firmware package and the version profile, each device in the candidate device range is verified and matched to determine the target device to be upgraded, and the target device is at least one; Firmware packages are sent to the target device according to the upgrade method and protocol adaptation scheduling strategy, and firmware upgrade is performed. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transition according to the communication protocol of the target device.

2. The method according to claim 1, characterized in that, The step of determining the upgrade reason based on the upgrade trigger information, and determining the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and the version profile, includes: If the upgrade trigger information is an after-sales work order, fault batch record, problem version list, gray-scale verification failure record, customer feedback list, or manually imported device list, then the upgrade reason is determined to be a problem-fixing upgrade. Extract the R&D model, unique product model code, fault module, and firmware version range of the equipment involved in the after-sales work order, the fault batch record, the problem version list, the gray-scale verification failure record, the customer feedback list, or the manually imported equipment list; Based on the R&D model, the product's unique model code, the fault module, and the firmware version range of the problem source, match the version profiles of all devices, summarize and deduplicate them to determine the range of candidate devices that need to be upgraded to fix the problem; The severity level of the fault is read from the after-sales work order, the fault batch record, the problem version list, the gray-scale verification failure record, the customer feedback list, or the manually imported device list, and the upgrade method is matched according to the severity level as either forced upgrade or confirmed upgrade.

3. The method according to claim 1, characterized in that, The step of determining the upgrade reason based on the upgrade trigger information, and determining the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and the version profile, includes: If the upgrade trigger information is a firmware release order or a feature release plan, then the upgrade reason is determined to be a new feature update upgrade; Extract the unique product model code, R&D model, module to be upgraded, and target compatible source version range recorded in the firmware release form or the feature release plan; Based on the product's unique model code, the R&D model, the module to be upgraded, and the target compatible source version range, the version profiles of all devices are matched, and duplicates are summarized to determine the range of candidate devices that need to be upgraded with new features. The upgrade method is determined to be a confirmed upgrade.

4. The method according to any one of claims 2 or 3, characterized in that, The process of verifying and matching each device within the candidate device range based on a pre-generated upgrade rule matrix automatically generated from the firmware package and the version profile to determine the target device to be upgraded includes: Read each effective upgrade rule in the upgrade rule matrix sequentially; For any of the aforementioned effective upgrade rules, a multi-dimensional hierarchical consistency check is performed on the version profiles of each candidate device within the candidate device range in sequence; If all verification items pass the match, the matched device is identified as the target device to be upgraded; otherwise, the process switches to the next effective upgrade rule and continues to verify and match until all verification items pass the match. If all of the aforementioned effective upgrade rules fail to match, the candidate device will be removed from the candidate device range, and the corresponding reason for non-upgrade will be stored.

5. The method according to claim 4, characterized in that, The step of sequentially performing multi-dimensional hierarchical consistency verification on the version profiles of each candidate device within the candidate device range includes: Perform a product unique model code matching verification between the first product unique model code contained in the effective upgrade rule and the second product unique model code contained in the version profile to determine whether the upgrade is allowed. If the match is successful, the first R&D model included in the effective upgrade rule and the second R&D model included in the version profile will be checked for R&D model affiliation to determine whether they belong to the same R&D branch or version family. If the match is successful, the following checks will be performed in sequence based on the effective upgrade rules and the version profile: matching verification of the module to be upgraded, rule source version range verification, device communication protocol matching verification, matching verification of upgrade reason and firmware risk level, compliance verification of upgrade method, and verification that there are no upgrade tasks with the same module in transit.

6. The method according to claim 5, characterized in that, The process of generating the upgrade rule matrix includes: After the R&D personnel upload the firmware package and the accompanying description file, they read and parse the accompanying description file, extract the firmware adaptation information, and generate a draft rule instance. According to the verification fields included in the pre-set rule template, the adaptation information of the rule instance draft is filled and organized to obtain a standardized rule instance; Based on the built-in verification logic of the rule template, multi-dimensional verification is performed on the standardized rule instance. The multi-dimensional verification includes at least: field integrity verification, consistency verification between product unique model code and R&D model, product model mapping verification, and source version and module dependency legality verification. If the verification fails, an error message will be output and the process will be returned to modify the accompanying description file. Otherwise, conflict detection will be performed on the standardized rule instance. The conflict detection includes at least the following: whether there are multiple target versions for the same product unique model code and the same module, whether the source version ranges overlap, whether the firmware risk level and upgrade method match, whether the protocol constraints conflict, and whether it affects the already effective historical upgrade tasks. If a conflict is detected, an error message is output and the process is returned to modify the corresponding description file. Otherwise, the standardized rule instance is submitted for approval and confirmation. After approval, the standardized rule instance is stored in the database as an effective upgrade rule, which together with the effective upgrade rules already stored in the database constitutes the upgrade rule matrix.

7. The method according to any one of claims 2 or 3, characterized in that, The protocol adaptation scheduling strategy is built upon a unified task state machine and multiple protocol schedulers. The step of sending firmware packages to the target device according to the upgrade method and protocol adaptation scheduling strategy, and performing firmware upgrades, includes: If the upgrade method is a confirmed upgrade, an upgrade confirmation pop-up will be sent to the target device. The pop-up content will include at least the device name, target version, reason for upgrade, estimated time, and precautions. If the user confirms, or if the upgrade method is a forced upgrade, an upgrade task instruction is generated, and the communication protocol supported by the target device is determined. According to the communication protocol, the corresponding protocol scheduler is invoked, and the upgrade task instruction is converted into an executable action that is compatible with the communication protocol based on the protocol scheduler. The executable action is compatible with any one of the following communication methods: wireless local area network communication, cellular mobile communication, Bluetooth near field communication, and long-range low-power communication. The firmware package is sent to the target device based on the communication method adapted to the executable action, and the task running status is updated in real time based on the task state machine until the firmware upgrade of the target device is completed. The task running status includes: waiting to match, waiting to confirm, waiting to send, waiting to wake up, transmitting, waiting for device execution, execution successful, execution failed, rolled back, and canceled.

8. A device for batch upgrading device firmware, characterized in that, The device includes: The upgrade information acquisition module is used to acquire upgrade trigger information and version profiles of all devices, wherein the version profiles represent the set of device attributes; The upgrade information determination module is used to determine the upgrade reason based on the upgrade trigger information, and to determine the candidate device range and corresponding upgrade method from all devices based on the upgrade reason and the version profile; The upgrade device matching module is used to verify and match each device in the candidate device range based on the upgrade rule matrix automatically generated from the firmware package and the version profile, and to determine the target device to be upgraded, wherein there is at least one target device. The device upgrade execution module is used to send firmware packages to the target device according to the upgrade method and protocol adaptation scheduling strategy, and to perform firmware upgrade. The protocol adaptation scheduling strategy represents the execution rules for instruction adaptation transmission and upgrade task status transition according to the communication protocol of the target device.

9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the batch upgrade method of device firmware according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the batch upgrade method of the device firmware according to any one of claims 1 to 7.

Images