Electronic device group software batch upgrade method
Patent Information
- Application Number
- CN202610875900.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-17
- Publication Date
- 2026-09-18
AI Technical Summary
[0005]因此,现有批量升级方法仍存在以下不足:一是升级批次划分主要依据设备状态或升级效率,未充分考虑不同电子装置对安全区域和功能类型的覆盖关系;二是缺少对主备装置、相邻高风险区域装置以及同功能关键装置的错峰约束,容易造成局部安全功能同时下降;三是升级前未充分确认替代电子装置是否具备临时代替目标电子装置运行的能力;四是升级过程中一旦出现异常,往往仅对失败装置进行重试或回滚,难以及时根据安全覆盖变化冻结后续批次并重新生成升级计划;五是升级完成后通常只关注版本号是否更新,缺少对通信状态和实际功能恢复情况的复核
[0047] 1. This solution establishes the coverage relationship between electronic devices and security areas and functional types, and calculates the security coverage margin in combination with the minimum effective online requirements. This ensures that the generation of upgrade batches is constrained and controlled by security coverage, avoiding the simultaneous upgrade of multiple electronic devices that perform critical functions in the same security area. This reduces the risk of monitoring gaps, alarm failures, or control interruptions during batch upgrades.
Smart Images

Figure CN122777147A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of electronic device software upgrades, and in particular to a method for batch software upgrades of electronic device groups. Background Technology
[0002] With the widespread application of building security, industrial monitoring, mining surveillance, fire alarms, access control, and IoT terminal systems, multiple electronic devices are typically deployed within the same application site. These devices collectively perform functions such as data acquisition, status monitoring, alarm output, access control, communication forwarding, and on-site linkage control. To fix software defects, add functionality, or adapt to new communication protocols, these electronic devices require regular software upgrades. Compared to upgrading a single electronic device, upgrading a group of devices typically involves challenges such as a large number of devices, dispersed deployment areas, inconsistent models and versions, significant differences in communication conditions, and varying operating states. Therefore, batch upgrades are necessary to improve upgrade efficiency.
[0003] Current methods for batch software upgrades of electronic device clusters typically involve a server, gateway, or management platform distributing upgrade packages centrally, with each electronic device then performing operations such as downloading, verifying, installing, restarting, and providing feedback on the results. While some solutions can achieve batch upgrades, retries on failures, resume interrupted downloads, or version rollbacks, they primarily focus on upgrade package transmission efficiency and the integrity of the upgrade process. They usually determine upgrade targets based solely on device online status, version number, or communication status, lacking constraints and judgments regarding the on-site security functions of the electronic device cluster.
[0004] In some safety-critical scenarios, multiple electronic devices often do not operate independently, but rather form a safety coverage system based on safety zones, functional types, primary / backup relationships, adjacent coverage relationships, or communication dependencies. For example, in access control, fire alarm, mining monitoring, tunnel monitoring, or industrial alarm systems, if multiple critical electronic devices in the same area simultaneously enter upgrade, restart, or short-term offline states, it may lead to monitoring gaps, control interruptions, reduced alarm capabilities, or communication link failures in localized areas. Even if the upgrade is subsequently successful, short-term safety risks may still arise during the upgrade process.
[0005] Therefore, existing batch upgrade methods still have the following shortcomings: First, the division of upgrade batches is mainly based on equipment status or upgrade efficiency, without fully considering the coverage relationship of different electronic devices to security areas and functional types; second, there is a lack of staggered constraints on primary and backup devices, adjacent high-risk area devices, and key devices with the same function, which can easily cause a simultaneous decline in local security functions; third, before the upgrade, it is not fully confirmed whether the alternative electronic device has the ability to temporarily replace the target electronic device; fourth, once an anomaly occurs during the upgrade process, it is often only retried or rolled back for the failed device, and it is difficult to freeze subsequent batches and regenerate the upgrade plan in a timely manner according to changes in security coverage; fifth, after the upgrade is completed, it usually only focuses on whether the version number is updated, without verifying the communication status and the actual functional recovery.
[0006] To address this, a method for batch software upgrades of electronic device clusters is proposed. Summary of the Invention
[0007] The main objective of this invention is to provide a method for batch software upgrades of electronic device groups, which can effectively solve the problems in the background art.
[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0009] A method for batch software upgrade of an electronic device group includes the following steps:
[0010] S1. Obtain the device status information of each electronic device in the electronic device group, and obtain the security zone information corresponding to the electronic device group; the device status information includes device number, current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, security zone, historical upgrade failure records, and self-test status; the security zone information includes security zone number, zone risk level, function type, and minimum effective online requirement corresponding to the function type, wherein the minimum effective online requirement is used to represent the minimum effective online coverage that the corresponding security zone needs to maintain under the corresponding function type;
[0011] S2. Based on the security zone, function type and installation coverage of each electronic device, establish the coverage relationship between the electronic device and the security zone, and establish the device relationship information between the electronic devices based on at least one of the following: primary / backup relationship, adjacent area relationship, communication dependency relationship and functional coverage overlap relationship.
[0012] S3. Calculate the security coverage margin of each security zone under different functional types based on the coverage relationship, the online status, the health coefficient, and the minimum effective online requirement;
[0013] S4. Generate at least one off-peak upgrade batch based on the security coverage margin and the upgrade risk value of each electronic device; wherein, each off-peak upgrade batch satisfies the following: during the execution of the off-peak upgrade batch, the security coverage margin of any security area under the corresponding functional type is not less than zero, electronic devices with primary and backup relationships are not in the same off-peak upgrade batch, and key electronic devices with the same function in adjacent high-risk security areas are not in the same off-peak upgrade batch.
[0014] S5. Take the pending peak-shifting upgrade batch as the current upgrade batch. Before executing the current upgrade batch, confirm the replacement capability of the target electronic device in the current upgrade batch. When the replacement electronic device corresponding to the target electronic device does not meet the replacement operation conditions, remove the target electronic device from the current upgrade batch and recalculate the safety coverage margin corresponding to the current upgrade batch.
[0015] S6. After the current upgrade batch meets the safety coverage margin requirements and the replacement capability confirmation requirements, send the corresponding software upgrade package or upgrade instruction to the electronic devices in the current upgrade batch so that the electronic devices in the current upgrade batch can perform software upgrade.
[0016] S7. During the execution of the current upgrade batch, monitor the upgrade progress, upgrade results, online recovery status of electronic devices, and the real-time security coverage margin of the corresponding security area; when an upgrade anomaly is detected that causes the real-time security coverage margin of any security area to fall below the preset margin threshold, or when the upgrade failure rate of the current upgrade batch exceeds the preset failure threshold, freeze the subsequent off-peak upgrade batches and regenerate the off-peak upgrade batches based on the upgrade anomaly results.
[0017] S8. After the current upgrade batch is completed, the upgraded electronic devices undergo version verification, communication verification, and function verification. Once the upgraded electronic devices pass the version verification, communication verification, and function verification, the next off-peak upgrade batch is released.
[0018] Furthermore, in step S2, establishing the coverage relationship between the electronic device and the secure area includes:
[0019] The electronic device group is represented as a device set including N electronic devices, the security area information is represented as a region set including Z security areas, and the function type is represented as a function set including F types of functions.
[0020] According to the Does the electronic device cover the first The first security zone Class functionality, establish coverage matrix:
[0021]
[0022] in, Indicates the first The electronic device for the first The first security zone Class functionality has an overriding function. Indicates the first The electronic device for the first The first security zone Class functionality does not have an overriding function;
[0023] Furthermore, based on the aforementioned regional risk level and functional type, for the first The first security zone Minimum valid online requirements for class functions .
[0024] Furthermore, in step S3, regarding the first... The candidate upgrade batch is calculated according to the following formula. The first security zone Security coverage margin for class functions:
[0025]
[0026] in, Indicates the first During the execution of the first candidate upgrade batch The first security zone Security coverage margin for class functions; Indicates the first Does the electronic device belong to the category of the first? The candidate upgrade batch, when the first The electronic device belongs to the first When there are multiple candidate upgrade batches... When the first The electronic device does not belong to the first When there are multiple candidate upgrade batches... ; Indicates the first The normal operating status of the electronic device, when the first When an electronic device is online and its self-test status is normal. ,otherwise ; Indicates the first The health coefficient of each electronic device, and When any At that time, the judgment of the first The candidate upgrade batch does not meet the security coverage constraint, and for the first batch... Candidate upgrade batches can be split, postponed, or regenerated.
[0027] Furthermore, in step S4, the upgrade risk value of each electronic device is calculated according to the following formula:
[0028]
[0029] in, Indicates the first Upgrade risk value for individual electronic devices; Indicates the first Normalized communication quality values for individual electronic devices; Indicates the first Normalized regional risk level of the security zone to which an electronic device belongs; Indicates the first Normalized value of functional criticality for each electronic device corresponding to its functional type; Indicates the first Normalized values of historical upgrade failure records for an electronic device; Indicates the first Normalized replacement reliability of an electronic device; , , , , These are weighting coefficients, all of which are greater than zero; when the upgrade risk value is greater than the preset risk threshold, the corresponding electronic device will be set as a delayed upgrade target or a separate upgrade target.
[0030] Furthermore, in step S4, for the first... Each candidate upgrade batch undergoes a batch feasibility evaluation, and the batch feasibility evaluation value is calculated according to the following formula:
[0031]
[0032] in, Indicates the first The batch feasibility evaluation value of each candidate upgrade batch; Indicates the first The collection of electronic devices in each candidate upgrade batch; Indicates the first The number of electronic devices in each candidate upgrade batch; Indicates the first Minimum security coverage margin across all security zones and all function types during the execution of each candidate upgrade batch; Indicates the first Upgrade risk value for individual electronic devices; Indicates the first The number of batch conflicts in a candidate upgrade batch includes at least one of the following: the number of primary / backup relationship conflicts, the number of conflicts of critical electronic devices with the same function in adjacent high-risk security areas, and the number of communication dependency conflicts. , , To evaluate the weighting coefficients, all of which are greater than zero; when Less than the preset feasibility threshold, or any At that time, regenerate the first One candidate upgrade batch.
[0033] Furthermore, in step S4, when generating staggered upgrade batches, the method also includes predicting coverage degradation of candidate upgrade batches based on a graph neural network model, specifically including: constructing the electronic device group into a device relationship graph. ,in, Represents the set of electronic device nodes. The system represents the set of edges relating electronic devices; it uses the current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, regional risk level, historical upgrade failure records, self-test status, and alternative reliability of each electronic device as node features; it uses the primary / backup relationship, adjacent region relationship, communication dependency relationship, and functional coverage overlap relationship between electronic devices as edge features; it uses the electronic device marking results in the candidate upgrade batch as batch mask features; it inputs the node features, edge features, and batch mask features into a graph neural network model to obtain the probability of electronic device upgrade failure and the probability of safe area coverage degradation; when the probability of safe area coverage degradation is greater than a preset degradation probability threshold, it lowers the batch feasibility evaluation value of the corresponding candidate upgrade batch, or splits the corresponding candidate upgrade batch into multiple new candidate upgrade batches.
[0034] Furthermore, in step S5, confirming the replacement capability of the target electronic device in the current upgrade batch includes: determining, based on the coverage relationship and device relationship information, a replacement electronic device that covers the same security area and corresponds to the same functional type as the target electronic device; sending communication test commands and function self-test commands to the replacement electronic device; determining that the replacement electronic device meets the replacement operation conditions when the replacement electronic device reports normal communication, normal function self-test, and is not in an upgrade state; and determining that the replacement electronic device does not report, has abnormal communication, abnormal function self-test, or is already in an upgrade state.
[0035] Furthermore, in step S6, before sending the corresponding software upgrade package or upgrade instruction to the electronic devices in the current upgrade batch, the method further includes: matching the corresponding software upgrade package according to the hardware model, current software version, target software version, and communication protocol version of the electronic device; when there is an intermediate version dependency relationship between the current software version and the target software version, generating an upgrade path including at least one intermediate software version; when the communication quality is lower than a preset communication quality threshold, dividing the software upgrade package into multiple upgrade package fragments, and performing fragment integrity verification after each upgrade package fragment is transmitted; when any upgrade package fragment fails the integrity verification, retransmitting the upgrade package fragment that failed the integrity verification, and keeping the electronic devices in the current upgrade batch that have not completed the upgrade in an upgrade waiting state.
[0036] A batch software upgrade system for electronic device clusters, characterized in that it includes:
[0037] The status acquisition module is used to acquire the device status information of each electronic device in the electronic device group, and to acquire the security area information corresponding to the electronic device group.
[0038] The coverage relationship establishment module is used to establish the coverage relationship between electronic devices and security zones based on the security zone, function type, and installation coverage of each electronic device, and to establish device relationship information between electronic devices.
[0039] The security coverage calculation module is used to calculate the security coverage margin of each security zone under different functional types based on the coverage relationship, online status, health coefficient and minimum effective online requirements;
[0040] The risk prediction and batch generation module is used to calculate the upgrade risk value of each electronic device, generate staggered upgrade batches based on the safety coverage margin and upgrade risk value, and perform coverage degradation prediction on candidate upgrade batches through a graph neural network model.
[0041] The substitution capability verification module is used to verify the substitution capability of the target electronic devices in the current upgrade batch before executing the current upgrade batch.
[0042] The upgrade execution module is used to send the corresponding software upgrade package or upgrade command to the electronic devices in the current upgrade batch, and to receive the upgrade progress and upgrade results from the electronic devices.
[0043] The abnormal freeze module is used to freeze subsequent staggered upgrade batches when an upgrade abnormality occurs in the current upgrade batch, and regenerate staggered upgrade batches based on the upgrade abnormality results.
[0044] The upgrade review module is used to review the version, communication, and functions of upgraded electronic devices, and release the next batch of staggered upgrades after the review is passed.
[0045] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for batch software upgrade of an electronic device group.
[0046] Compared with the prior art, the present invention has the following beneficial effects:
[0047] 1. This solution establishes the coverage relationship between electronic devices and security areas and functional types, and calculates the security coverage margin in combination with the minimum effective online requirements. This ensures that the generation of upgrade batches is constrained and controlled by security coverage, avoiding the simultaneous upgrade of multiple electronic devices that perform critical functions in the same security area. This reduces the risk of monitoring gaps, alarm failures, or control interruptions during batch upgrades.
[0048] 2. When generating staggered upgrade batches, this invention comprehensively considers the relationship between primary and backup devices, the relationship between adjacent areas, the relationship between communication dependencies, and the relationship between functional coverage overlap. Before the upgrade, the alternative electronic devices are tested for communication and self-checked for functionality. This can prevent the primary device and the backup device from going offline at the same time, and ensure that there are still alternative electronic devices that meet the conditions to maintain the corresponding safety functions during the upgrade of the target electronic device.
[0049] 3. During the upgrade process, this invention continuously monitors the upgrade progress, online recovery status, and real-time security coverage margin. When an upgrade anomaly leads to insufficient security coverage or an excessively high failure rate, it can freeze subsequent batches and regenerate the upgrade plan. After the upgrade is completed, version verification, communication verification, and functional verification are performed, thereby improving the continuity, reliability, and security of batch upgrades of electronic device groups. Attached Figure Description
[0050] Fig. 1 This is a schematic diagram of the method flow of the present invention;
[0051] Fig. 2 This is a schematic diagram of the system modules of the present invention. Detailed Implementation
[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0053] Example 1
[0054] like Figs. 1-2As shown, the following description uses an electronic device group in a building security scenario to illustrate the implementation of the present invention. This electronic device group includes multiple access control controllers, alarm acquisition terminals, video linkage terminals, and communication gateways. Each electronic device is deployed on different floors, at entrances / exits, equipment rooms, and fire escape routes to perform functions such as access control, alarm acquisition, status monitoring, and communication forwarding. Since these electronic devices collectively undertake security functions during operation, it is necessary to avoid multiple critical electronic devices in the same security area going offline simultaneously during batch software upgrades.
[0055] In this embodiment, the management platform first acquires the device status information of each electronic device in the electronic device group. The device status information includes device number, current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, security zone, historical upgrade failure records, and self-test status. The function type can include access control, alarm detection, video capture, and communication forwarding, etc.; the security zone can be divided according to floor, entrance / exit, equipment room, fire exit, or other security management units.
[0056] The management platform also obtains security zone information corresponding to the electronic device clusters. Security zone information includes the security zone number, zone risk level, function type, and the minimum valid online requirement corresponding to that function type. For example, for video capture functionality in a typical office area, the minimum valid online requirement can be set to at least one video capture terminal maintaining normal operation; for alarm detection functionality between devices, the minimum valid online requirement can be set to at least two alarm capture terminals maintaining normal operation; for access control functionality at main entrances and exits, the minimum valid online requirement can be set to at least one access controller maintaining normal operation, and the main access controller and backup access controller must not be upgraded simultaneously.
[0057] After obtaining the above information, the coverage relationship between the electronic devices and the security areas is established according to the security area, function type, and installation coverage of each electronic device. For example, the first access control controller covers the access control function of Entrance / Exit 1, and the second access control controller, as its backup controller, also covers the access control function of Entrance / Exit 1; the first alarm acquisition terminal and the second alarm acquisition terminal jointly cover the alarm detection function between devices; the first communication gateway covers the communication forwarding function of multiple electronic devices in the area on the east side of the first floor.
[0058] Furthermore, the management platform establishes device relationship information between electronic devices. This device relationship information includes at least one of the following: primary / backup relationship, adjacent area relationship, communication dependency relationship, and functional coverage overlap relationship. For example, the first access controller and the second access controller have a primary / backup relationship; the east side corridor on the first floor and the first floor lobby are adjacent areas; some alarm acquisition terminals rely on the first communication gateway to upload alarm data, thus forming a communication dependency relationship with the first communication gateway; the monitoring ranges of two video linkage terminals partially overlap, thus forming a functional coverage overlap relationship.
[0059] For ease of subsequent calculations, the electronic device group can be represented as a set of devices including N electronic devices, the security area information can be represented as a set of regions including Z security areas, and the function type can be represented as a set of functions including F types of functions. A coverage matrix is then established.
[0060]
[0061] in, Indicates the first The electronic device for the first The first security zone Class functionality has an overriding function. Indicates the first The electronic device for the first The first security zone This type of function does not have a coverage function. Based on the regional risk level and function type, for the [specific category]... The first security zone Minimum valid online requirements for class functions .
[0062] Before generating upgrade batches, the management platform first calculates the security coverage margin for each security zone under different functional types. (For the first...) The candidate upgrade batch is calculated according to the following formula. The first security zone Security coverage margin for class functions:
[0063]
[0064] in, Indicates the first During the execution of the first candidate upgrade batch The first security zone Security coverage margin for class functions; Indicates the first Does the electronic device belong to the category of the first? The candidate upgrade batch, when the first The electronic device belongs to the first When there are multiple candidate upgrade batches... When the first The electronic device does not belong to the first When there are multiple candidate upgrade batches... ; Indicates the first The normal operating status of the electronic device, when the first When an electronic device is online and its self-test status is normal. ,otherwise ; Indicates the first The health coefficient of each electronic device, and
[0065] When any function type in any security zone corresponds to If the candidate upgrade batch results in the effective online coverage of the corresponding security area being lower than the minimum effective online requirement, the management platform will determine that the candidate upgrade batch does not meet the security coverage constraint and will split, postpone, or regenerate the candidate upgrade batch.
[0066] To further improve the rationality of batch segmentation, the management platform can also calculate the upgrade risk value for each electronic device. The upgrade risk value can be calculated using the following formula:
[0067]
[0068] in, Indicates the first Upgrade risk value for individual electronic devices; Indicates the first Normalized communication quality values for individual electronic devices; Indicates the first Normalized regional risk level of the security zone to which an electronic device belongs; Indicates the first Normalized value of functional criticality for each electronic device corresponding to its functional type; Indicates the first Normalized values of historical upgrade failure records for an electronic device; Indicates the first Normalized replacement reliability of an electronic device; , , , , These are weighting coefficients, and all are greater than zero.
[0069] For example, if an access control controller has poor communication quality, belongs to an area with a high risk level, has a high number of historical upgrade failures, and has no reliable backup controller, its upgrade risk value is high. For electronic devices whose upgrade risk value exceeds the preset risk threshold, the management platform can set them as delayed upgrade targets or separate upgrade targets to avoid them being upgraded simultaneously with other critical electronic devices.
[0070] After candidate upgrade batches are generated, the management platform can further conduct batch feasibility evaluations. The batch feasibility evaluation value can be calculated using the following formula:
[0071]
[0072] in, Indicates the first The batch feasibility evaluation value of each candidate upgrade batch; Indicates the first The collection of electronic devices in each candidate upgrade batch; Indicates the first The number of electronic devices in each candidate upgrade batch; Indicates the first Minimum security coverage margin across all security zones and all function types during the execution of each candidate upgrade batch; Indicates the first Upgrade risk value for individual electronic devices; Indicates the first The number of batch conflicts in a candidate upgrade batch includes at least one of the following: the number of primary / backup relationship conflicts, the number of conflicts of critical electronic devices with the same function in adjacent high-risk security areas, and the number of communication dependency conflicts. , , The weighting coefficients are used for evaluation, and all of them are greater than zero.
[0073] When the batch feasibility evaluation value is less than the preset feasibility threshold, or any security coverage margin is less than zero, the management platform regenerates the candidate upgrade batch. During regeneration, high-risk electronic devices can be removed from the original batch, or electronic devices with primary / backup relationships, communication dependencies, or adjacent high-risk area relationships can be assigned to different batches.
[0074] In one alternative implementation, a graph neural network model can also be used to predict coverage degradation in candidate upgrade batches. Specifically, the group of electronic devices is constructed as a device relationship graph. ,in, Represents the set of electronic device nodes. This represents the set of edges representing relationships between electronic devices. The current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, regional risk level, historical upgrade failure records, self-test status, and alternative reliability of each electronic device are used as node features. The primary / backup relationship, adjacent region relationship, communication dependency relationship, and functional overlap relationship between electronic devices are used as edge features. The electronic device marking results in the candidate upgrade batch are used as batch mask features.
[0075] After inputting the aforementioned node features, edge features, and batch mask features into the graph neural network model, the probability of electronic device upgrade failure and the probability of security area coverage degradation are obtained. When the probability of security area coverage degradation corresponding to a candidate upgrade batch is greater than a preset degradation probability threshold, the management platform lowers the batch feasibility evaluation value of that candidate upgrade batch, or splits the candidate upgrade batch into multiple new candidate upgrade batches. This graph neural network model is used to assist in judging the potential security coverage reduction risk caused by candidate upgrade batches. Ultimately, whether a batch is executed is still constrained by the security coverage margin and alternative capabilities.
[0076] When the management platform generates staggered upgrade batches, it must meet at least the following rules: the security coverage margin of any security zone under the corresponding functional type is not less than zero; electronic devices with primary and backup relationships are not in the same staggered upgrade batch; critical electronic devices with the same function in adjacent high-risk security zones are not in the same staggered upgrade batch; electronic devices with communication dependencies are not upgraded at the same time; electronic devices with higher upgrade risk values are upgraded later or individually.
[0077] For example, the first and second access control controllers at entrance / exit 1 cannot be assigned to the same upgrade batch because they have a primary / backup relationship. If the first access control controller is to be upgraded as the target electronic device, it must be confirmed before the upgrade that the second access control controller is online, communicating normally, has normal self-test functions, and is not in an upgrade state. Only when the second access control controller meets the alternative operation conditions is the first access control controller allowed to enter the current upgrade batch.
[0078] Before executing the current upgrade batch, the management platform verifies the replacement capability of the target electronic devices in the current upgrade batch. Specifically, based on coverage and device relationship information, it identifies replacement electronic devices that cover the same security area as the target electronic device and have the same functional type; it sends communication test commands and function self-test commands to the replacement electronic devices; when the replacement electronic device reports normal communication, normal function self-test, and is not in an upgrade state, it is determined that the replacement electronic device meets the replacement operation conditions; when the replacement electronic device does not report, has communication abnormalities, has abnormal function self-tests, or is already in an upgrade state, it is determined that the replacement electronic device does not meet the replacement operation conditions, and the target electronic device is removed from the current upgrade batch.
[0079] After the current upgrade batch passes the security coverage margin assessment and replacement capability confirmation, the management platform issues the corresponding software upgrade package or upgrade command to the electronic devices in the current upgrade batch. Upon receiving the upgrade package or upgrade command, the electronic device sequentially executes the upgrade package reception, upgrade package integrity verification, software writing, restart loading, version confirmation, and result feedback.
[0080] Before distributing software upgrade packages, the management platform can match the corresponding software upgrade package based on the hardware model, current software version, target software version, and communication protocol version of the electronic device. When there is an intermediate version dependency between the current software version and the target software version, the management platform generates an upgrade path that includes at least one intermediate software version, allowing the electronic device to upgrade sequentially according to the upgrade path, avoiding software compatibility issues caused by cross-version upgrades. When the communication quality is lower than a preset communication quality threshold, the management platform divides the software upgrade package into multiple upgrade package fragments and performs fragment integrity verification after each upgrade package fragment is transmitted. If any upgrade package fragment fails the integrity verification, only the upgrade package fragment that failed the integrity verification is retransmitted, and the electronic devices in the current upgrade batch that have not yet completed the upgrade remain in an upgrade waiting state.
[0081] During the current upgrade batch execution, the management platform continuously monitors the upgrade progress, upgrade results, online recovery status, and real-time security coverage margin of the corresponding security zone for electronic devices. The real-time security coverage margin can be updated based on the current online status, self-test status, and health coefficient. When a critical electronic device in the current upgrade batch is detected to have timed out, failed to upgrade, or failed to return to online status after restarting, the management platform recalculates the real-time security coverage margin of the security zone to which that electronic device belongs.
[0082] When an upgrade anomaly causes the real-time security coverage margin of any security zone to fall below a preset margin threshold, or when the upgrade failure rate of the current upgrade batch exceeds a preset failure threshold, the management platform freezes subsequent off-peak upgrade batches. After freezing, the management platform stops issuing upgrade packages or upgrade commands to subsequent batches and regenerates off-peak upgrade batches based on the upgrade anomaly results. For electronic devices that fail to upgrade, retry, rollback, or postponement of the upgrade can be performed; for other electronic devices in the same security zone as the upgrade-failed electronic device or with a primary / backup relationship, they can be temporarily set to an upgrade-prohibited state until the corresponding security zone restores the minimum effective online coverage.
[0083] After the current upgrade batch is completed, the management platform performs version verification, communication verification, and functional verification on the upgraded electronic devices. Version verification confirms that the electronic device's software version matches the target software version; communication verification confirms that the communication link between the electronic device and the management platform, communication gateway, or other associated electronic devices is normal; functional verification confirms that the corresponding access control, alarm acquisition, video linkage, or communication forwarding functions of the electronic device have been restored. Only after the upgraded electronic devices pass the version verification, communication verification, and functional verification will the management platform release the next off-peak upgrade batch.
[0084] Through the above methods, this invention, during the batch software upgrade of an electronic device cluster, not only enables the upgrade of multiple electronic devices but also allows for staggered upgrade batch control based on security area coverage, minimum effective online requirements, primary / backup relationships, and alternative capability confirmation results. This prevents critical electronic devices from going offline simultaneously, thus avoiding security function interruptions. Furthermore, in the event of an upgrade anomaly, subsequent upgrade batches can be frozen and a new upgrade plan can be generated, thereby improving the continuous operation and reliability of the electronic device cluster during batch upgrades.
[0085] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.
Claims
1. A method for batch software upgrade of an electronic device group, characterized in that, Includes the following steps: S1. Obtain the device status information of each electronic device in the electronic device group, and obtain the security zone information corresponding to the electronic device group; the device status information includes device number, current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, security zone, historical upgrade failure records, and self-test status; the security zone information includes security zone number, zone risk level, function type, and minimum effective online requirement corresponding to the function type, wherein the minimum effective online requirement is used to represent the minimum effective online coverage that the corresponding security zone needs to maintain under the corresponding function type; S2. Based on the security zone, function type and installation coverage of each electronic device, establish the coverage relationship between the electronic device and the security zone, and establish the device relationship information between the electronic devices based on at least one of the following: primary / backup relationship, adjacent area relationship, communication dependency relationship and functional coverage overlap relationship. S3. Calculate the security coverage margin of each security zone under different functional types based on the coverage relationship, the online status, the health coefficient, and the minimum effective online requirement; S4. Generate at least one off-peak upgrade batch based on the security coverage margin and the upgrade risk value of each electronic device; wherein, each off-peak upgrade batch satisfies the following: during the execution of the off-peak upgrade batch, the security coverage margin of any security area under the corresponding functional type is not less than zero, electronic devices with primary and backup relationships are not in the same off-peak upgrade batch, and key electronic devices with the same function in adjacent high-risk security areas are not in the same off-peak upgrade batch. S5. Take the pending peak-shifting upgrade batch as the current upgrade batch. Before executing the current upgrade batch, confirm the replacement capability of the target electronic device in the current upgrade batch. When the replacement electronic device corresponding to the target electronic device does not meet the replacement operation conditions, remove the target electronic device from the current upgrade batch and recalculate the safety coverage margin corresponding to the current upgrade batch. S6. After the current upgrade batch meets the safety coverage margin requirements and the replacement capability confirmation requirements, send the corresponding software upgrade package or upgrade instruction to the electronic devices in the current upgrade batch so that the electronic devices in the current upgrade batch can perform software upgrade. S7. During the execution of the current upgrade batch, monitor the upgrade progress, upgrade results, online recovery status of electronic devices, and the real-time security coverage margin of the corresponding security area; when an upgrade anomaly is detected that causes the real-time security coverage margin of any security area to fall below the preset margin threshold, or when the upgrade failure rate of the current upgrade batch exceeds the preset failure threshold, freeze the subsequent off-peak upgrade batches and regenerate the off-peak upgrade batches based on the upgrade anomaly results. S8. After the current upgrade batch is completed, the upgraded electronic devices undergo version verification, communication verification, and function verification. Once the upgraded electronic devices pass the version verification, communication verification, and function verification, the next off-peak upgrade batch is released.
2. The method for batch software upgrade of an electronic device group according to claim 1, characterized in that, In step S2, establishing the coverage relationship between the electronic device and the secure area includes: The electronic device group is represented as a device set including N electronic devices, the security area information is represented as a region set including Z security areas, and the function type is represented as a function set including F types of functions. According to the Does the electronic device cover the first The first security zone Class functionality, establish coverage matrix: in, Indicates the first The electronic device for the first The first security zone Class functionality has an overriding function. Indicates the first The electronic device for the first The first security zone Class functionality does not have an overriding function; Furthermore, based on the aforementioned regional risk level and functional type, for the first The first security zone Minimum valid online requirements for class functions .
3. The method for batch software upgrade of an electronic device group according to claim 2, characterized in that, In step S3, for the first The candidate upgrade batch is calculated according to the following formula. The first security zone Security coverage margin for class functions: in, Indicates the first During the execution of the first candidate upgrade batch The first security zone Security coverage margin for class functions; Indicates the first Does the electronic device belong to the category of the first? The candidate upgrade batch, when the first The electronic device belongs to the first When there are multiple candidate upgrade batches... When the first The electronic device does not belong to the first When there are multiple candidate upgrade batches... ; Indicates the first The normal operating status of the electronic device, when the first When an electronic device is online and its self-test status is normal. ,otherwise ; Indicates the first The health coefficient of each electronic device, and When any At that time, the judgment of the first The candidate upgrade batch does not meet the security coverage constraint, and for the first batch... Candidate upgrade batches can be split, postponed, or regenerated.
4. The method for batch software upgrade of an electronic device group according to claim 3, characterized in that, In step S4, the upgrade risk value of each electronic device is calculated according to the following formula: in, Indicates the first Upgrade risk value for individual electronic devices; Indicates the first Normalized communication quality values for individual electronic devices; Indicates the first Normalized regional risk level of the security zone to which an electronic device belongs; Indicates the first Normalized value of functional criticality for each electronic device corresponding to its functional type; Indicates the first Normalized values of historical upgrade failure records for an electronic device; Indicates the first Normalized replacement reliability of an electronic device; , , , , These are weighting coefficients, all of which are greater than zero; when the upgrade risk value is greater than the preset risk threshold, the corresponding electronic device will be set as a delayed upgrade target or a separate upgrade target.
5. The method for batch software upgrade of an electronic device group according to claim 4, characterized in that, In step S4, for the first Each candidate upgrade batch undergoes a batch feasibility evaluation, and the batch feasibility evaluation value is calculated according to the following formula: in, Indicates the first The batch feasibility evaluation value of each candidate upgrade batch; Indicates the first The collection of electronic devices in each candidate upgrade batch; Indicates the first The number of electronic devices in each candidate upgrade batch; Indicates the first Minimum security coverage margin across all security zones and all function types during the execution of each candidate upgrade batch; Indicates the first Upgrade risk value for individual electronic devices; Indicates the first The number of batch conflicts in a candidate upgrade batch includes at least one of the following: the number of primary / backup relationship conflicts, the number of conflicts of critical electronic devices with the same function in adjacent high-risk security areas, and the number of communication dependency conflicts. , , To evaluate the weighting coefficients, all of which are greater than zero; when Less than the preset feasibility threshold, or any At that time, regenerate the first One candidate upgrade batch.
6. The method for batch software upgrade of an electronic device group according to claim 1, characterized in that, In step S4, when generating staggered upgrade batches, the method further includes predicting coverage degradation of candidate upgrade batches based on a graph neural network model. Specifically, this includes constructing the electronic device group into a device relationship graph. ,in, Represents the set of electronic device nodes. The system represents the set of edges relating electronic devices; it uses the current software version, target software version, online status, communication quality, power status, storage status, health coefficient, function type, regional risk level, historical upgrade failure records, self-test status, and alternative reliability of each electronic device as node features; it uses the primary / backup relationship, adjacent region relationship, communication dependency relationship, and functional coverage overlap relationship between electronic devices as edge features; it uses the electronic device marking results in the candidate upgrade batch as batch mask features; it inputs the node features, edge features, and batch mask features into a graph neural network model to obtain the probability of electronic device upgrade failure and the probability of safe area coverage degradation; when the probability of safe area coverage degradation is greater than a preset degradation probability threshold, it lowers the batch feasibility evaluation value of the corresponding candidate upgrade batch, or splits the corresponding candidate upgrade batch into multiple new candidate upgrade batches.
7. The method for batch software upgrade of an electronic device group according to claim 1, characterized in that, In step S5, confirming the replacement capability of the target electronic device in the current upgrade batch includes: determining, based on the coverage relationship and device relationship information, a replacement electronic device that covers the same security area and corresponds to the same functional type as the target electronic device; sending communication test commands and function self-test commands to the replacement electronic device; determining that the replacement electronic device meets the replacement operation conditions when the replacement electronic device reports normal communication, normal function self-test, and is not in an upgrade state; and determining that the replacement electronic device does not report, has communication abnormalities, has abnormal function self-tests, or is already in an upgrade state.
8. The method for batch software upgrade of an electronic device group according to claim 1, characterized in that, In step S6, before sending the corresponding software upgrade package or upgrade instruction to the electronic devices in the current upgrade batch, the method further includes: matching the corresponding software upgrade package according to the hardware model, current software version, target software version, and communication protocol version of the electronic device; when there is an intermediate version dependency relationship between the current software version and the target software version, generating an upgrade path including at least one intermediate software version; when the communication quality is lower than a preset communication quality threshold, dividing the software upgrade package into multiple upgrade package fragments, and performing fragment integrity verification after each upgrade package fragment is transmitted; when any upgrade package fragment fails the integrity verification, retransmitting the upgrade package fragment that failed the integrity verification, and keeping the electronic devices in the current upgrade batch that have not completed the upgrade in an upgrade waiting state.
9. A batch software upgrade system for electronic device clusters, characterized in that, include: The status acquisition module is used to acquire the device status information of each electronic device in the electronic device group, and to acquire the security area information corresponding to the electronic device group. The coverage relationship establishment module is used to establish the coverage relationship between electronic devices and security zones based on the security zone, function type, and installation coverage of each electronic device, and to establish device relationship information between electronic devices. The security coverage calculation module is used to calculate the security coverage margin of each security zone under different functional types based on the coverage relationship, online status, health coefficient and minimum effective online requirements; The risk prediction and batch generation module is used to calculate the upgrade risk value of each electronic device, generate staggered upgrade batches based on the safety coverage margin and upgrade risk value, and perform coverage degradation prediction on candidate upgrade batches through a graph neural network model. The substitution capability verification module is used to verify the substitution capability of the target electronic devices in the current upgrade batch before executing the current upgrade batch. The upgrade execution module is used to send the corresponding software upgrade package or upgrade command to the electronic devices in the current upgrade batch, and to receive the upgrade progress and upgrade results from the electronic devices. The abnormal freeze module is used to freeze subsequent staggered upgrade batches when an upgrade abnormality occurs in the current upgrade batch, and regenerate staggered upgrade batches based on the upgrade abnormality results. The upgrade review module is used to review the version, communication, and functions of upgraded electronic devices, and release the next batch of staggered upgrades after the review is passed.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for batch software upgrade of an electronic device group as described in any one of claims 1 to 8.