Campus device cluster-oriented remote version iteration and log management method and system

Abstract

The application discloses a remote version iteration and log management method and system for a campus equipment cluster, and relates to the technical field of data processing. The remote version iteration and log management method and system for the campus equipment cluster, comprising S1, collecting campus equipment cluster data, storing after preprocessing and constructing an equipment regulation database; S2, combining equipment operation conditions and version parameters to carry out health situation quantitative evaluation; S3, relying on equipment observation fragments and operation health degree to carry out data conflict detection analysis; S4, according to the health situation and the system busy degree to carry out import risk deduction analysis; S5, gathering the whole process key event flow and constructing time sequence index, realizing the construction of equipment whole life cycle health atlas and the traceability management of regulation database. The problems that conflict processing, transaction guarantee and log traceability are difficult to cooperate in the batch import and remote version iteration process of the campus equipment cluster are solved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for remote version iteration and log management of campus equipment clusters. Background Technology

[0002] With the continuous deployment of campus consumer terminals, self-service devices, identity recognition devices, and supporting edge nodes in campus scenarios, campus equipment is gradually shifting from single-point deployment to a clustered operation and maintenance model with multiple regions, models, and versions coexisting. In existing technologies, the management of campus equipment clusters mostly revolves around basic ledger maintenance, status switching, and version updates. For multi-source information such as equipment operating status, fault records, operation behaviors, version parameters, network load, and configuration change records, management is usually accomplished by distributed collection, table-based storage, or processing according to business pages.

[0003] For example, the invention patent with announcement number CN118642751B discloses a method, device, and medium for low-code platform application version management. The technical solution adopted is as follows: generating application version artifacts: generating application version artifacts by using metadata files, dictionary indexes and dictionary item data files with the application as the aggregate root, and static files, and starting to asynchronously distribute the application to the runtime center that subscribes to the application version artifacts; storing subscribed application version artifacts: after the runtime center starts, it actively registers the host and port of the application design center, and the design center saves the host address and port of the runtime center; uploading application version artifacts and obtaining new application version records.

[0004] For example, invention patent CN116974857B discloses a method and system for automatically deploying and updating a monitoring agent, including: the server polling the local area network to determine if a new host is found; if a new host is found, automatic or batch deployment is performed; if no new host is found, the version information and parameter configuration information of the client and server are checked to see if they are consistent; if they are inconsistent, data packets are downloaded and updated; the client collects and processes data from the host machine according to the collection configuration requirements, and sends the processed data to the server; the server integrates the returned data and unifies the data format, completing data entry into the database and pushing data to the page display. This invention can greatly improve deployment efficiency and real-time status monitoring.

[0005] However, in existing campus equipment operation and maintenance, operation logs such as version upgrades, configuration adjustments, enabling / disabling, import rollbacks, and anomaly alarms are often recorded in a scattered manner according to function, lacking a continuous temporal correlation established around individual devices. This makes it difficult to form a complete trajectory of the entire process of a device from access, operation, upgrade, conflict handling to anomaly recovery, which is not conducive to subsequent root cause location of faults, evaluation of version iteration effects, and long-term operation and maintenance record management. Especially when adding or updating campus devices in batches via files, the data to be imported often contains unique fields such as device identifiers and network addresses that are duplicated with existing devices, and may also be accompanied by configuration differences, version inconsistencies, fault record conflicts, and component dependency mismatches.

[0006] Therefore, in response to the above problems, there is an urgent need for a remote version iteration and log management method and system for campus equipment clusters. Summary of the Invention

[0007] To address the above issues, this invention provides a method and system for remote version iteration and log management for campus device clusters, which solves the problem of difficulty in coordinating conflict handling, transaction protection, and log traceability during batch import and remote version iteration of campus device clusters.

[0008] To achieve the above objectives, the technical solution adopted by this invention is: a remote version iteration and log management method and system for campus equipment clusters, comprising: S1, collecting campus equipment cluster data, preprocessing the campus equipment cluster data, storing it, and constructing an equipment control database; S2, conducting a quantitative assessment of health status based on equipment operating conditions and version parameters, and executing equipment status hierarchical control and version iteration operations based on the health assessment results; S3, conducting data conflict detection and analysis based on equipment observation segments and operational health, and executing overwrite, skip, and fusion operations based on the conflict detection and analysis results; S4, conducting import risk simulation analysis based on health status and system busy level, and executing dynamic switching of transaction modes and atomicity guarantee operations based on the risk simulation analysis; S5, aggregating key event streams throughout the entire process and constructing a time-series index to realize the construction of a health map of the entire equipment lifecycle and traceability management of the control database.

[0009] Further, the specific steps for collecting campus equipment cluster data are as follows: Collect campus equipment cluster data: Obtain real-time equipment operating status, failure count, current version value, and configuration file data through the equipment management interface; obtain network bandwidth utilization and load values ​​through the equipment performance monitoring interface; obtain equipment failure records through equipment failure logs; pull dependency declarations of all published components through the dependency declaration file to construct a global component dependency graph; obtain equipment operating status, number of operations, runtime, and load data through the equipment performance monitoring module; obtain the latest firmware version, configuration update time, and current device version number through the version control system; obtain the maximum supported version number of the device through equipment calibration parameters, split the version number into a three-dimensional integer sequence based on the major version number, minor version number, and revision version number, and sort and map the three-dimensional integer sequence according to the lexicographical priority comparison rule to obtain the maximum version value.

[0010] Further, the specific steps for preprocessing and storing campus equipment cluster data and constructing an equipment control database are as follows: Each sensor record is synchronously written with its equipment identifier, acquisition time, task batch number, and geographic coordinate identifier, and time alignment and window aggregation are performed based on the acquisition time; sliding window denoising, outlier removal, and missing value interpolation are performed on the campus equipment cluster data, integrating multi-source records within the same observation time window into equipment observation segments, and assigning a globally unique segment sequence number to each segment; the equipment identifier, task batch number, and work area identifier are uniformly encoded and standardized using a distribution standardization algorithm to achieve unified format of the identifier data, and normalized to a uniform numerical range using a minimum-maximum normalization algorithm; the standardized and normalized campus equipment cluster data is then stored and an equipment control database is constructed.

[0011] Furthermore, the specific steps for conducting a quantitative assessment of health status by combining equipment operating conditions and version parameters are as follows: Obtain the number of failures, number of operations, current version value, and maximum version value allowed for the equipment category for the i-th device during the observation period; multiply the number of failures by the failure impact weighting factor to obtain the weighted failure value; divide the weighted failure value by the number of operations to obtain the failure contribution component; calculate the ratio of the current version value to the maximum version value to obtain the version compliance rate; subtract the version compliance rate from one to obtain the version lagging item; multiply the version lagging item by the version impact weighting factor to obtain the version contribution component; add the failure contribution component and the version contribution component to finally obtain the health failure value of the i-th device.

[0012] Furthermore, the specific steps for implementing equipment status grading control and version iteration operations based on health assessment results are as follows: By comparing health failure values ​​and failure thresholds in real time, when the health failure value is less than the failure threshold, it is determined to be in a healthy state, and the current version configuration, operating parameters, and health failure value are archived together in the equipment control database for decision-making by the conflict handling module; when the health failure value is greater than or equal to the failure threshold, it is determined to be in a risky state, and it is isolated from the service cluster, triggering a configuration reset command to restore the equipment parameters to the factory template; and comparing the current version value of the equipment with the component dependency graph, if the current version value is less than or equal to the failure threshold, the equipment is considered to be in a risky state. If the version value is lower than the target version but all dependencies are satisfied, it is considered a version lag, and an incremental upgrade package is issued when the version is lagging. If any component version in the current version value does not meet the dependency range, it is considered a version break. The previous stable version is selected from the device's historical version records as the version marked as stable and with a continuous stable running time exceeding the stability threshold, and the version is rolled back to the previous stable version. If the health failure value is still greater than or equal to the failure threshold after recalculation, an alarm report is generated, and the status change, version iteration, repair operation, and conflict handling decision are stored in the device control database through log records.

[0013] Furthermore, based on equipment observation segments and operational health status, data conflict detection and analysis are conducted. The specific steps for performing coverage, skipping, and fusion operations based on the conflict detection and analysis results are as follows: A device fingerprint hash space is constructed using the equipment observation segments as input. Collision detection is performed on the unique identifier of each device to be imported, comparing it with the device records in the device control database to identify primary key uniqueness conflicts. Primary key uniqueness conflicts include duplicate device identifiers and duplicate network addresses. Based on the current device version value and component dependency graph, each component version number of the device to be imported is checked to see if it meets the version range required by the corresponding dependent components: if all component versions fall within the corresponding range, version compatibility is determined; otherwise, version breakage is determined and marked as a version chain conflict item. A comprehensive decision is made by combining the operational status indicators in the observation segments to be imported with the device status in the device records: for primary key uniqueness conflicts, if the observation segment acquisition time is later than the most recent update time of the device record... If the number of faults in the observed segment is less than the number of faults recorded by the device, and the device is in a healthy state, an overwrite operation is performed, and the version number is incremented. If the device is in a risky state, a skip operation is performed, and the conflict record is temporarily stored in the log buffer. For version chain conflicts, if the version is broken, and the number of operations and runtime in the observed segment are both greater than those recorded by the device, and the device is in a healthy state, an intelligent merging operation is performed: based on field weights and collection timeliness, the version information, configuration files, and fault records of the observed segment to be imported and the device record are merged. A merged observed segment is generated in the temporary work area, and its similarity is calculated with the device record. Only when the similarity exceeds the similarity threshold is it written to the device control database. If the device is in a risky state and the number of faults in the observed segment is greater than the number of faults in the device record, a skip operation is performed and it is marked as a version conflict anomaly. All operation results and state changes are stored in the device control database through log records.

[0014] Furthermore, the specific steps for conducting risk projection analysis based on the health status and system busy level are as follows: obtain the health failure value and load value of the i-th device; multiply the health loss attenuation factor by the health failure value to obtain the attenuation product; take the negative value of the attenuation product and use it as the exponent to calculate the natural exponential function to obtain the health attenuation term; multiply the load adjustment factor by the load value to obtain the load product; add 1 to the load product to obtain the load compensation term; divide the health attenuation term by the load compensation term to finally obtain the success guarantee value of the i-th device.

[0015] Furthermore, based on risk simulation analysis, the specific steps for dynamic switching of transaction modes and atomicity guarantee operations are as follows: Real-time comparison of the successful guarantee value and the guarantee threshold, including T1 and T2; when the successful guarantee value < T1, it is determined to be an abnormal import item, blocking the transactional write process of the device, marking the import status as blocked and generating a risk warning instruction, and writing the successful guarantee value and blocking flag to the log record; when T1 ≤ successful guarantee value < T2, a partial successful import mode is enabled, allowing the device to enter the import process but using flexible transaction processing, skipping conflict records according to the conflict item list marked by the conflict handling module, continuing to import non-conflicting data, and simultaneously pushing the import progress and conflict records to the log record in real time; when the successful guarantee value ≥ T2, a transactional import mode is enabled. A globally unique transaction identifier is generated and associated with all data to be written in this import. Before each write, an idempotent key is generated using the device identifier, transaction identifier, and key data fields for anti-duplicate verification. The key data fields include at least the device identifier, observation segment sequence number, and current version value. After the verification is successful, the data is temporarily stored in the transaction buffer. When all data verification is completed and the success guarantee value is still ≥T2, the transaction is committed uniformly. If any step fails or the success guarantee value falls below T2 before the commit, a full rollback operation based on the pre-created rollback point is triggered to roll back to the initial state before import to achieve full successful writing of device data or overall rollback. At the same time, the transaction identifier, import result and transaction status, dynamic change trajectory of the success guarantee value, and non-conflicting data skipping strategy execution record are written to the log.

[0016] Furthermore, the specific steps for aggregating key event streams across the entire process and constructing a time-series index to achieve the construction of a health graph and traceability management of the control database throughout the device's lifecycle are as follows: Using the device control database as a foundation, key event streams from each stage of device status monitoring, conflict handling, and transactional import are acquired in real time. These key event streams include health status change events, version operation events, conflict detection events, and transactional import events. Specifically, health status change events include records of health failure value changes and state switching times; version operation events include configuration reset command execution trajectories, incremental upgrade package distribution records, and version rollback operation details; and conflict detection events include primary key collision results and version chain conflict markers. The system includes detailed operation records for both coverage and intelligent merging. Transaction import events include the output of successful guarantee value calculation, transaction identifier, import result, and transaction execution status. After attaching a timestamp and device identifier to each event stream, a time-series index is established using the combination of device identifier and timestamp as the primary key and event type and transaction identifier as secondary keys. This constructs a health graph for the entire lifecycle of the device. The health graph uses device identifier as the core node, time axis as the dimension, event type as the attribute label, and version iteration and conflict resolution relationships as edges, forming a time-series evolution network of device health status. Accumulated log data is aggregated by device identifier and then injected back into the device control database to form a traceable device health record.

[0017] Furthermore, the second aspect of this invention provides a remote version iteration and log management system for campus equipment clusters, applying a remote version iteration and log management method for campus equipment clusters, including: a data acquisition and preprocessing module for acquiring campus equipment cluster data, preprocessing the campus equipment cluster data, storing it, and constructing an equipment control database; an equipment status monitoring and management module for conducting quantitative health status assessments based on equipment operating conditions and version parameters, and executing equipment status hierarchical control and version iteration operations based on the health assessment results; a conflict handling module for conducting data conflict detection and analysis based on equipment observation segments and operational health, and executing overwrite, skip, and fusion operations based on the conflict detection and analysis results; a transactional import module for conducting import risk extrapolation analysis based on health status and system busy levels, and executing dynamic switching of transaction modes and atomicity guarantee operations based on the risk extrapolation analysis; and a log recording module for aggregating key event streams throughout the entire process and constructing a time-series index to realize the construction of a health map of the entire equipment lifecycle and traceability management of the control database.

[0018] (1) This invention collects data from multiple sources, including equipment management interface, performance monitoring interface, fault log, version control system and calibration parameters, in real time. The data includes equipment operating status, number of faults, version value, configuration file, dependency declaration, etc. Each record is appended with equipment identifier, collection time, task batch number and geographic coordinate identifier. After noise reduction, interpolation, alignment and normalization, the data is integrated into standardized equipment observation segments and a device control database is constructed. This achieves unified representation and high-confidence storage of campus equipment cluster data, effectively solving the problems of data silos and decision bias caused by heterogeneous multi-source data formats, misaligned time sequence and inconsistent quality in the prior art.

[0019] (2) In this invention, the number of failures, the number of operations, the current version value and the maximum version value are coupled into quantitative indicators, and the healthy state and the risk state are dynamically divided based on the failure threshold. For risky equipment, configuration reset, incremental upgrade or version rollback operation is automatically triggered, and the status change and repair trajectory are archived in real time, thereby realizing accurate measurement of equipment health and autonomous closed loop of version iteration, effectively solving the problems of rough equipment status judgment, version management relying on manual and delayed fault response in the prior art.

[0020] (3) This invention relies on the device fingerprint hash space to perform collision detection on unique identifiers, accurately identify conflicts between duplicate primary keys and duplicate network addresses, and simultaneously verify the compatibility of version intervals item by item based on the component dependency graph to detect version chain breaks and anomalies. Combining the operational health and the timeliness of the observed segments, it performs intelligent fusion operations based on field weight and collection timeliness, and generates fused segments in the temporary work area. After similarity verification, the fused segments are written into the database, thereby realizing full-dimensional detection and lossless fusion of conflict items. This effectively solves the problems of only supporting simple primary key verification, inability to identify version conflicts, and easy introduction of contradictions in data fusion in the prior art.

[0021] (4) This invention aggregates key event flows from each stage of equipment status monitoring, conflict handling, and transactional import, including health value changes, status switching, version iteration, conflict detection results, fusion operation details, success guarantee value calculation output, and final transaction status. After adding timestamps and equipment identifiers to each event, a time-series index is constructed to form a health map of the entire equipment lifecycle. The accumulated logs are then injected into the control database to drive the self-optimization of thresholds and weight factors, thereby realizing traceable management of operation and maintenance events and closed-loop evolution of system strategies. This effectively solves the problems of scattered logs, inability to perform correlation analysis, and lack of self-optimization capabilities in the existing technology.

[0022] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0023] Figure 1 This is a flowchart of the remote version iteration and log management method for campus equipment clusters according to the present invention;

[0024] Figure 2 This is a structural diagram of the remote version iteration and log management system for campus equipment clusters according to the present invention;

[0025] Figure 3 This is a flowchart illustrating the intelligent decision-making process for importing conflict data into a campus equipment cluster, as described in this invention.

[0026] Figure 4 This is a distribution diagram of the import strategy under the coupling effect of health status and system busyness in this invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solution, the present invention will be described in detail below with reference to embodiments. The description in this part is only exemplary and explanatory, and should not be used to limit the scope of protection of the present invention in any way.

[0028] Please see Figures 1-4 This invention provides a technical solution: a remote version iteration and log management method and system for campus equipment clusters, comprising: S1, collecting campus equipment cluster data, preprocessing the data, storing it, and constructing an equipment control database; S2, conducting a quantitative assessment of health status based on equipment operating conditions and version parameters, and performing equipment status hierarchical control and version iteration operations based on the health assessment results; S3, conducting data conflict detection and analysis based on equipment observation segments and operational health, and performing overwrite, skip, and fusion operations based on the conflict detection and analysis results; S4, conducting import risk simulation analysis based on health status and system busyness, and performing dynamic switching of transaction modes and atomicity guarantee operations based on the risk simulation analysis; S5, aggregating key event streams throughout the entire process and constructing a time-series index to realize the construction of a health map of the entire equipment lifecycle and traceability management of the control database.

[0029] Specifically, the steps for collecting campus equipment cluster data are as follows: Through multiple source channels such as equipment management interfaces, performance monitoring interfaces, fault logs, dependency declaration files, version control systems, and equipment calibration parameters, comprehensive information on the campus equipment cluster's operating status, number of faults, number of operations, runtime, load data, current version value, configuration files, dependency declarations, latest firmware version, and maximum firmware version is collected. The collected semantic version numbers are split into a three-dimensional integer sequence based on major version number, minor version number, and revision version number, and mapped to comparable values ​​according to lexicographical order rules. Simultaneously, a global component dependency graph is constructed based on the dependency declarations of all published components, providing a quantitative benchmark for the version contribution component in subsequent health failure value calculations and a judgment basis for version compatibility verification and version chain conflict detection. This achieves unified collection and standardized representation of multi-source equipment data, effectively solving the problems in existing technologies where version information cannot directly participate in numerical calculations and component dependency relationships are missing, leading to difficulty in identifying version conflicts. This lays a complete data foundation for quantitative assessment of equipment health status and remote version iteration.

[0030] In this implementation plan, multi-source data such as device operating status, number of failures, number of operations, runtime, load data, version information, and dependency declarations are collected. The semantic version number is split into a three-dimensional integer sequence and mapped to a comparable value. At the same time, a global component dependency graph is constructed, thereby realizing the unified collection and standardized representation of multi-source data of the device. This effectively solves the problems that version information cannot be directly used in numerical calculations and component dependencies are missing, laying a data foundation for the quantitative assessment of device health status and version iteration.

[0031] Specifically, the steps for preprocessing and storing campus equipment cluster data and constructing an equipment control database are as follows: Each sensor record is synchronously written with the equipment identifier, acquisition time, task batch number, and geographic coordinate identifier. Time alignment and window aggregation are performed based on the acquisition time. During the writing process, the number of faults, number of operations, runtime, current equipment version value, load value, configuration file summary, network address, and component version list are attached to the corresponding record as associated fields, ensuring that data entering the same observation process has a unified traceability marker. Sliding window denoising, outlier removal, and missing value imputation are performed on the campus equipment cluster data. Multi-source records within the same observation time window are integrated into equipment observation segments, and each segment is assigned a globally unique segment sequence number. Each equipment observation segment fixedly includes the equipment identifier, the start and end points of the acquisition time interval, the task batch number, geographic coordinate identifier, number of faults, number of operations, runtime, current equipment version value, load value, configuration file summary, network address, component version list, and status label. The observation time window width is uniformly divided according to integer multiples of the acquisition cycle. Continuous numerical fields within the window are aggregated using a combined method of mean, extreme values, and last values ​​to generate segment characteristics. The discrete state field is aggregated using frequency statistics and last state retention, providing a stable input basis for subsequent equipment observation segments in equipment fingerprint hash space construction, collision detection, and similarity calculation. The segment sequence number serves as a unique tracking number for the equipment observation segment, forming a segment-level index key together with the equipment identifier and task batch number. A distribution standardization algorithm is used to uniformly encode and standardize the equipment identifier, task batch number, and work area identifier, achieving a unified format for the identifier data. A minimum-maximum normalization algorithm is used for normalization, scaling the data to a uniform numerical range. For continuous features within the equipment observation segment, dual records of the original value before normalization and the mapped value after normalization are retained to support subsequent operational health assessment and conflict comparison analysis. The standardized and normalized campus equipment cluster data is stored and an equipment control database is constructed. Simultaneously, segment index tables, time index tables, and equipment index tables are established according to the segment sequence number, allowing any equipment observation segment to trace back to the corresponding original record set, window aggregation result, and field mapping relationship along the segment sequence number. This provides a consistent data foundation for subsequent fingerprint hash space construction, uniqueness collision detection, and fusion similarity determination based on equipment observation segments.

[0032] This implementation plan processes campus equipment cluster data through unified writing, time alignment, window aggregation, noise reduction and cleaning, missing data completion, standardized mapping and normalization. This results in equipment observation segments and segment sequence numbers with fixed field composition, clear time boundaries, consistent segment granularity, and complete identifier association. This transforms scattered multi-source records into traceable, comparable, and computable structured data units, providing a unified and reliable data foundation for subsequent health failure value calculation, equipment fingerprint hash space construction, primary key uniqueness conflict identification, version chain conflict determination, fusion similarity analysis, and transaction import decisions. It also improves data consistency, retrieval efficiency, and end-to-end traceability capabilities in the equipment control database.

[0033] Specifically, the steps for quantitatively assessing the health status of equipment by combining operating conditions and version parameters are as follows: To quantitatively assess the health status of equipment, firstly, obtain the number of failures, number of operations, current version value, and maximum allowed version value for the i-th equipment during the observation period; by collecting historical operating data of the campus equipment cluster, perform multi-factor regression analysis on the correlation between the number of failures and the number of operations, and introduce the version compatibility weight coefficient defined in the component dependency graph. Use a weighted least squares method based on historical failure rate and version update frequency to fit and obtain the failure impact weight factor, with a value range of 0.3 to 0.6; by performing principal component analysis on the health failure values ​​of the same equipment category under different version states, and combining the version breakage risk coefficient defined in the version dependency graph, use a version impact intensity evaluation function based on a Bayesian network to obtain the version impact weight factor, with a value range of 0.4 to 0.7; multiply the number of failures by the failure impact weight factor to obtain the weighted failure value. The initial contribution of the fault frequency to the health loss is reflected in the value. The weighted fault value is then divided by the number of operations to obtain the fault contribution component, which characterizes the fault density of the device per unit of operations, thus eliminating the interference of different operational intensities on the fault impact. Simultaneously, the ratio of the current version value to the maximum version value is calculated to obtain the version compliance rate, reflecting the proximity between the current version of the device and the highest supported hardware version. Subtracting the version compliance rate from one yields the version lag term, which quantifies the performance degradation or security risk caused by the device's lack of version updates. Multiplying the version lag term by the version impact weighting factor yields the version contribution component, which characterizes the intensity of the health loss caused by version lag. Finally, the fault contribution component and the version contribution component are added to obtain the health failure value of the i-th device. This value comprehensively reflects the overall health loss of the device under the combined effects of fault frequency and version lag, providing a quantitative basis for subsequent device status classification and version iteration operations.

[0034] The specific formula for calculating the health failure value is as follows:

[0035] ;

[0036] In the formula, Indicates the first The health failure value of each device reflects / represents the health loss caused by faults, operating frequency, and version during the operation of the device; Indicates equipment The number of failures during the observation period reflects the equipment's failure status; Indicates equipment The number of operations, i.e., the total number of operations performed by the equipment, reflects the workload of the equipment. Indicates equipment The current version value indicates the latest firmware or software version of the device; This indicates the highest version value allowed for the device category, reflecting whether the device complies with the latest standards; This represents the fault impact weighting factor, used to control the degree of influence of equipment faults on health failure values; This indicates the version influence weighting factor, used to control the degree of influence of the device version on the health failure value.

[0037] In this implementation plan, by integrating the two-dimensional indicators of failure frequency and version lag, the original parameters such as the number of failures, the number of operations, the current version value, and the maximum version value are transformed into quantifiable health failure values. This enables the numerical representation and dynamic evaluation of the equipment's operational health, providing a unified quantitative basis for equipment status hierarchical management and version iteration decisions.

[0038] Specifically, the steps for implementing equipment status hierarchical control and version iteration operations based on health assessment results are as follows: By comparing health failure values ​​and failure thresholds in real time, when the health failure value is less than the failure threshold, it is determined to be in a healthy state. The current version configuration, operating parameters, and health failure value are archived together in the equipment control database for the decision-making basis of the conflict handling module. During the archiving process, the equipment identifier, collection time, task batch number, current version value, number of failures, number of operations, runtime, and configuration summary are written synchronously, so that the conflict handling module can directly call the latest health assessment results and version status information of the corresponding equipment when conducting primary key uniqueness conflict identification, version chain conflict identification, and overwrite skip fusion decision-making. When the health failure value is greater than or equal to the failure threshold, it is determined to be in a risky state. The equipment is isolated from the service cluster, a configuration reset command is triggered to restore the equipment parameters to the factory template, and the current version value of the equipment is compared with the component dependency graph. The version of each component corresponding to the current version value is verified item by item along the component dependency graph. If the current version value is less than the target version and all component versions satisfy the dependency relationship, it is determined to be a version lag. When a version lag occurs, an incremental upgrade package is issued, and patches are loaded level by level according to the upgrade path defined by the component dependency relationship graph. The version list and configuration mapping relationship are rebuilt. If any component version in the current version value does not satisfy the dependency range, it is determined to be a version break. The version marked as stable and with a continuous stable running time exceeding the stability threshold in the device's historical version record is queried as the previous stable version. The version is rolled back to the previous stable version, and the configuration file, component list, running parameters and dependency mapping relationship corresponding to the previous stable version are restored synchronously during the rollback process. If the health failure value obtained after recalculation is still greater than or equal to the failure threshold, an alarm report is generated, and the status change, version iteration, repair operation and conflict handling decision are stored in the device control database through log records. This ensures that the device control database continuously maintains a complete correlation link between health assessment, risk isolation, version repair and subsequent conflict handling.

[0039] This implementation scheme achieves hierarchical identification of equipment health status and risk status. In the healthy state, it completes the archiving and retention of the current version configuration, operating parameters and health failure values. In the risk state, it completes equipment isolation, configuration reset, version lag repair, version breakage rollback and continuous alarm handling. This makes the equipment status management, version iteration repair and subsequent conflict handling decisions form a linked process, which effectively improves the reliability of equipment status data in the equipment control database, the stability of version status and the accuracy of subsequent overwrite, skip and merge decisions.

[0040] Specifically, the data conflict detection and analysis based on equipment observation segments and operational health status, and the specific steps for performing coverage, skipping, and fusion operations based on the conflict detection and analysis results are as follows: To accurately identify data conflicts during batch import, a device fingerprint hash space is constructed using equipment observation segments as input. This fingerprint is generated by using the device identifier, network address, and device category code to generate a unique hash value through the SHA-256 algorithm, and an index space is constructed using a consistent hash ring. The collision detection threshold is strictly zero tolerance. Collision detection is then performed on the unique identifier of each device to be imported, and the collision is compared with the device records in the device control database to identify primary key uniqueness conflicts. Primary key uniqueness conflicts include duplicate device identifiers and duplicate network addresses. Based on the current version value of the device and the component dependency relationship graph, each component version number of the device to be imported is checked to see if it meets the version range required by the corresponding dependent components: if all component versions fall within the corresponding range, the version is considered compatible; otherwise, the version is considered broken and marked as a version chain conflict item. A comprehensive decision is made by combining the operational status indicators in the observation segments to be imported with the device status in the device records: for primary key uniqueness conflicts, if the observation segment acquisition time is later than the latest update time of the device record, and the number of faults in the observation segment is less than the set value, the conflict is considered resolved. If the device is in a healthy state and the number of faults recorded is available, an overwrite operation is performed, triggering version number increment. If the device is in a risky state, a skip operation is performed, and the conflict record is temporarily stored in the log buffer. For version chain conflicts, if the version is broken and the number of operations and runtime in the observation segment are both greater than those in the device record, and the device is in a healthy state, an intelligent merging operation is performed: Based on field weights and collection timeliness, the version information, configuration files, and fault records of the observation segment to be imported and the device record are merged. The field weights are obtained by analyzing the frequency of field changes in historical data using the entropy weight method, with a value range of 0. ~1 and the sum of the weights of each field is 1. The timeliness of data collection is determined by the reciprocal of the time difference between the time of observation segment collection and the current time. After fusion, the observation segment is generated in the temporary workspace and its similarity to the device record is calculated. The similarity is calculated using a cosine similarity algorithm, and the similarity threshold is obtained through historical data distribution statistics, with a value of 0.85. Data is only written to the device control database when the similarity exceeds the threshold. If the device is in a risky state and the number of failures in the observation segment is greater than the number of failures recorded in the device record, a skip operation is performed and the device is marked as a version conflict anomaly. All operation results and status changes are stored in the device control database through log records. Figure 3 The diagram shown is a flowchart of the intelligent decision-making process for importing conflict data into the campus equipment cluster in this embodiment.

[0041] This implementation scheme constructs a device fingerprint hash space for unique identifier collision detection, accurately identifying primary key uniqueness conflicts and version chain break conflicts based on component dependency graphs. It combines operational status indicators such as acquisition time, number of failures, number of operations, and runtime in the observation segments to be imported with the device health status in device records for comprehensive decision-making. For primary key uniqueness conflicts, it performs overwrite or skip operations; for version chain conflicts, it performs intelligent fusion operations based on field weights and acquisition timeliness, while satisfying version compatibility and health status requirements. Cosine similarity verification ensures the quality of fused data. Finally, all operation results and status changes are stored in the device control database through log records. This achieves accurate detection and differentiated processing of multi-dimensional data conflicts, effectively solving the problems of intertwined primary key conflicts and version compatibility conflicts during batch import and the potential for data fusion to introduce contradictions. It provides refined assurance for the data consistency and integrity of the device control database.

[0042] Specifically, the steps for conducting risk simulation analysis based on health status and system busyness are as follows: Obtain the health failure value and load value of the i-th device. The health failure value represents the degree of fault accumulation, version lag, and operational stability of the i-th device in the current operating phase. The load value represents the device's control database write pressure, link congestion, and resource consumption level during the import period. By collecting historical import task success rate data from the campus device cluster, perform nonlinear regression analysis on the health failure value and import success rate. Use the least squares method to fit an exponential decay curve to obtain a health loss decay factor, with a value range of 1.5 to 3.0. By performing Spearman rank correlation analysis on the correlation between system busyness and transaction failure rate in historical import tasks, and combining the distribution characteristics of system load peak and transaction response time, use a load impact intensity evaluation function based on quantile regression to obtain a system load adjustment factor, with a value range of 0.8 to 1.5. The values ​​of the two factors mentioned above are determined through training with historical data and dynamically optimized during system operation using the import result data accumulated by the log recording module. The health loss attenuation factor is multiplied by the health failure value to obtain an attenuation product. This attenuation factor amplifies the risk differences under different health states, making the health failure value have a more significant inhibitory effect on subsequent import decisions after it enters the risk range. The attenuation product is then negatively evaluated to calculate a natural exponential function, resulting in a health attenuation term. This term decreases non-linearly as the health failure value increases, highlighting the risk identification sensitivity of abnormal devices during the transaction import phase. The load adjustment factor is multiplied by the load value to obtain a load product, which, combined with the concurrent write intensity, link occupancy fluctuations, and resource contention levels during the import period, characterizes the impact of busy conditions on write success. The load product is then incremented by 1 to obtain... The load compensation item constrains the health decay item, preventing the full write process from being directly entered when the device health is good but the import link is busy. The health decay item is divided by the load compensation item to obtain the success guarantee value of the i-th device. The success guarantee value is used as the direct input for subsequent dynamic switching of transaction mode and atomicity guarantee operation. When the success guarantee value is too small, the import process is guided to switch to blocking processing. When the value is in the middle range, the import process is guided to switch to partial success import mode. When the value meets the transaction write condition, the import process is guided to enter transactional import mode. In this way, the joint analysis results of health status and busy level can directly affect the import path selection, thereby reducing the error write and rollback amplification caused by unstable devices entering full commit during busy periods, and improving the continuous import capability of non-conflicting data and the overall batch import throughput performance.

[0043] The specific formula for calculating the success guarantee value is as follows:

[0044] ;

[0045] In the formula, This indicates the probability of successful device import, reflecting the likelihood of success during the import process. This represents the health loss attenuation factor, which controls the strength of the influence of health failure values ​​on the probability of successful import. Indicates device The health failure value reflects the impact of the equipment's health status on the success of the introduction; This represents the system load adjustment factor, which controls the degree of influence of system load on the probability of successful import. This indicates the load value, reflecting the current system load status.

[0046] Table 1 shows the dynamic risk simulation data based on health status and system busyness in this embodiment. For the first sampling point, the health loss attenuation factor is 2.0, the health failure value is 0.10, the system load adjustment factor is 1.0, and the busyness is 0.10, resulting in a calculated success guarantee value of 0.7443. For the second sampling point, the health loss attenuation factor is 2.0, the health failure value is 0.30, the system load adjustment factor is 1.0, and the busyness is 0.50, resulting in a calculated success guarantee value of 0.3659. For the third sampling point, the health loss attenuation factor is 2.0, the health failure value is 0.50, the system load adjustment factor is 1.0, and the busyness is 0.30, resulting in a calculated success guarantee value of 0.2830. For the fourth sampling point, the health loss attenuation factor is 2.0, the health failure value is 0.70, the system load adjustment factor is 1.0, and the busyness is 0.70, resulting in a calculated success guarantee value of 0.1451.

[0047]

[0048] like Figure 4 The diagram shown is a distribution chart of import strategies under the coupling effect of health status and system busyness provided in the embodiments of this application. Combined with the data in Table 1... Figure 4 As can be seen, the health failure value of the first sampling point (0.10, busyness of 0.10, and success guarantee value of 0.7443) is located in the green ACID transaction area, indicating that strong consistency transactions can be safely adopted when the device is healthy and the system is idle. The health failure value of the fourth sampling point (0.70, busyness of 0.70, and success guarantee value of 0.1451) falls into the red blocking area, indicating that the risk of importing high-failure-rate devices under high load is extremely high, and the write process needs to be directly blocked. The scatter distribution verifies that the success guarantee value formula can effectively integrate the health failure value and busyness as dual factors, providing a risk-adaptive dynamic transaction strategy selection basis for batch import operations.

[0049] In this implementation plan, by incorporating health failure values ​​and load values ​​into the import risk simulation, and introducing health decay items and load compensation items to form a success guarantee value, a joint characterization of equipment operation risks and resource consumption pressure during the import period is achieved. This expands the import judgment from single conflict identification to a comprehensive judgment based on health status and busy level. As a result, it can more accurately distinguish between the three processing paths of blocked import, partially successful import, and transactional import, reducing the phenomenon of erroneous writes, rollback propagation, and increased resource consumption caused by abnormal equipment entering full commit under busy links. At the same time, it improves the continuous import capability of non-conflicting data, batch import throughput performance, and the reliability of subsequent atomicity guarantee operations.

[0050] Specifically, the steps for dynamic switching of transaction modes and atomicity guarantee operations based on risk simulation analysis are as follows: Real-time comparison of the success guarantee value and guarantee threshold (including T1 and T2) is performed. Before each write scheduling, a linkage judgment is made based on the device identifier, observation segment sequence number, current version value, conflict item list, and the most recent success guarantee value in the log record corresponding to the current import batch. When the success guarantee value < T1, it is determined to be an abnormal import item, blocking the transactional write process of the device, marking the import status as blocked, generating a risk warning instruction, freezing the corresponding write queue of the device, stopping subsequent buffer loading, and writing the success guarantee value and blocking flag to the log record, so that the abnormal import item is intercepted before entering the write stage. When T1 ≤ success guarantee value < T2, a partial success import mode is enabled, allowing the device to enter the import process but using flexible transaction processing. Conflict records are skipped according to the conflict item list marked by the conflict handling module, and non-conflict data is continued to be imported. Simultaneously, a write order is established for the non-conflict data according to the device identifier and observation segment sequence number, and the import progress is recorded item by item. Each skipped conflict record, each completed non-conflict data entry, and the current success guarantee value are recorded. The results of guaranteed value changes are pushed to the log in real time to ensure continuous traceability of the import process. When the successful guaranteed value is ≥ T2, transactional import mode is enabled, a globally unique transaction identifier is generated and associated with all data to be written in this import. Before each write, an idempotent key is generated using the device identifier, transaction identifier, and key data fields for anti-duplicate verification. The key data fields include at least the device identifier, observation segment sequence number, and current version value. During the anti-duplicate verification process, it is simultaneously verified whether there are duplicate commit records and field conflict records under the same transaction identifier. After the verification is passed, the data is temporarily stored in the transaction buffer, pending further processing. When data verification is completed and the success guarantee value remains ≥T2, the transaction is committed uniformly. If any step fails or the success guarantee value falls below T2 before commit, a full rollback operation based on the pre-created rollback point is triggered, rolling back to the initial state before import to achieve full successful writing of device data or overall rollback. At the same time, the transaction identifier, import result and transaction status, dynamic change trajectory of the success guarantee value and non-conflicting data skipping policy execution record are written to the log, so that the three paths of blocking processing, partial successful import and transactional import form a switchable, verifiable and rollback closed-loop control link in the same import batch.

[0051] In this implementation plan, by comparing the success guarantee value with the guarantee thresholds T1 and T2 in a tiered manner, adaptive switching between three types of write paths—abnormal import blocking, partially successful import, and transactional import—is achieved. This allows device data under different risk levels to be matched with the corresponding import method. When the success guarantee value is low, high-risk writes are blocked in advance. When the success guarantee value is in the middle range, the ability to continuously import non-conflicting data is preserved. When the success guarantee value meets the conditions, the overall write with idempotent verification, transaction buffering, and rollback control is completed. This improves the efficiency of non-conflicting data passing through the batch import process, the ability to isolate and handle conflicting data, and the data consistency guarantee capability in the full write scenario. At the same time, it enhances the traceability, rollback capability, and stability of the import process and the determination of the import status.

[0052] Specifically, the steps for aggregating key event flows throughout the entire process and constructing a time-series index to achieve the construction of a health map and traceability management of the control database for the entire lifecycle of equipment are as follows: Using the equipment control database as the underlying support, key event flows from each stage of equipment status monitoring, conflict handling, and transaction import are captured in real time through a message queue. These key event flows are strictly divided into four categories: health status change events, version operation events, conflict detection events, and transaction import events. Health status change events fully record the dynamic change trajectory of health failure values ​​and the switching moments between healthy and risky states. Version operation events include detailed execution trajectories of configuration reset commands, incremental upgrade package distribution records, and complete details of version rollback operations. Conflict detection events accurately store primary key collision results, version chain conflict markers, and operation details of overwriting and intelligent merging. Transaction import events comprehensively record successful maintenance... The system calculates and outputs fault values, globally unique transaction identifiers, import results, and transaction execution status. For each event stream, a precise timestamp and device identifier are appended. A distributed time-series index is established using the combination of device identifier and timestamp as the primary key and event type and transaction identifier as secondary keys. This constructs a health graph for the entire device lifecycle. The health graph uses device identifiers as the core nodes, timelines as dimensions, event types as attribute labels, and version updates and conflict resolution relationships as edges, fully presenting the health status evolution network of the device from network access to decommissioning. Accumulated log data is aggregated by device identifier, and feature extraction and statistical analysis are performed. Key indicators such as fault frequency, version iteration cycle, and conflict occurrence rate are injected back into the device control database to drive the dynamic optimization of health failure thresholds and weighting factors, ultimately forming a traceable, evolvable, and closed-loop optimized device health profile.

[0053] In this implementation plan, an equipment control database serves as the underlying support. By capturing key event streams from various stages of equipment status monitoring, conflict handling, and transaction import in real time, a time-series index is established for all events, including health failure value changes, version operation trajectories, conflict detection results, and transaction execution status, based on equipment identifiers and timestamps. This constructs a health map of the entire equipment lifecycle. This map, with equipment as nodes, events as attributes, and version iteration and conflict repair relationships as edges, fully presents the evolution network of equipment health status. Accumulated log data is aggregated by equipment identifier and then injected back into the equipment control database to drive the dynamic optimization of health failure thresholds and weighting factors. This enables the traceable construction and closed-loop evolution of equipment health records, providing quantitative data support for fault root cause localization and version iteration effect evaluation.

[0054] Specifically, this embodiment provides a remote version iteration and log management system for campus equipment clusters, applied to a method for remote version iteration and log management of campus equipment clusters. It includes: a data acquisition and preprocessing module for collecting campus equipment cluster data, preprocessing the data, storing it, and constructing an equipment control database. During the acquisition process, it uniformly aggregates equipment operating status, number of failures, number of operations, runtime, current device version value, load value, configuration files, network addresses, and component version lists. It also performs execution time alignment, window aggregation, sliding window noise reduction, and outlier removal on the acquired results. Missing measurement value interpolation, standardized label mapping, and numerical normalization processing generate structured records and equipment observation fragments that can be directly stored in the database. The equipment status monitoring and management module combines equipment operating conditions and version parameters to conduct quantitative health status assessments. Based on the health assessment results, it performs hierarchical control of equipment status and version iteration operations, continuously calculates and updates equipment health failure values, and accordingly completes health status archiving, risk status isolation, configuration reset, version lag repair, version breakage rollback, and alarm reporting, ensuring consistency between equipment operating status and version status. The conflict resolution module relies on equipment observation fragments and operational health to conduct... Data conflict detection and analysis involves performing overwrite, skip, and merging operations based on the conflict detection and analysis results. It identifies duplicate device identifiers, duplicate network addresses, and version chain conflicts in the device fingerprint hash space, and combines these with operational status indicators from device observation segments and health failure values ​​from the device control database to complete overwrite replacement, skip buffers, and intelligent merging decisions. The transactional import module performs import risk simulation analysis based on health status and system busy levels. Based on the risk simulation analysis, it performs dynamic switching of transaction modes and atomicity guarantee operations, calculates successful guarantee values ​​in real time, and links them with guarantee thresholds for judgment. It also handles abnormal import scenarios. The system performs blocking operations, partially successful imports within the intermediate risk range, and executes transactional imports with idempotency verification, transaction buffering, unified commit, and failure rollback control when the transaction write conditions are met. The log recording module is used to aggregate the key event streams of the entire process and build a time-series index to realize the construction of the device's full lifecycle health map and the traceability management of the control database. It continuously records changes in health failure values, state transitions, version iterations, conflict detection results, overwrite skip fusion actions, changes in successful guarantee values, and transaction import status, thereby forming a closed-loop management link that runs through collection, evaluation, conflict handling, transaction import, and operation and maintenance tracking.

[0055] In this implementation plan, a standardized equipment control database is constructed through a data acquisition and preprocessing module, providing a unified data foundation for subsequent assessments. The equipment status monitoring and management module achieves quantitative assessment of equipment health status and adaptive repair of risk states based on health failure values. The conflict handling module accurately identifies primary key uniqueness conflicts and version chain break conflicts based on equipment observation fragments and component dependency graphs, and performs overwrite, skip, or intelligent fusion operations according to operational health. The transactional import module dynamically switches between blocking, flexible transactions, and ACID transaction modes based on success guarantee values, achieving risk-adaptive import control and atomicity assurance. The log recording module aggregates key event streams throughout the entire process to construct a time-series index, forming a traceable equipment health graph and driving threshold optimization in reverse. This achieves full-chain collaborative management from data acquisition, status assessment, conflict handling, transaction import to log closure, effectively solving the problems of difficult flexible handling of uniqueness constraint conflicts, inability to identify version compatibility, and rigid transaction modes during batch equipment import.

[0056] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the present invention. These examples are merely for the purpose of helping to understand the method and core ideas of the present invention. The above descriptions are only preferred embodiments of the present invention. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or variations without departing from the principles of the present invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, variations, or combinations, or the direct application of the concept and technical solution of the present invention to other situations without modification, should all be considered within the scope of protection of the present invention.

Claims

1. A method for remote version iteration and log management of campus device clusters, characterized in that, Includes the following steps, S1 collects campus equipment cluster data, preprocesses the campus equipment cluster data, stores it, and builds an equipment control database; S2, combines equipment operating conditions and version parameters to conduct a quantitative assessment of health status, and performs equipment status hierarchical management and version iteration operations based on the health assessment results; The specific steps for conducting a quantitative assessment of health status by combining equipment operating conditions and version parameters are as follows: Obtain the number of failures, number of operations, current version value, and maximum allowed version value for the i-th device during the observation period; multiply the number of failures by the failure impact weighting factor to obtain the weighted failure value; divide the weighted failure value by the number of operations to obtain the failure contribution component; calculate the ratio of the current version value to the maximum version value to obtain the version compliance rate; subtract the version compliance rate from one to obtain the version lag component; multiply the version lag component by the version impact weighting factor to obtain the version contribution component; add the failure contribution component and the version contribution component to finally obtain the health failure value of the i-th device. The specific steps for performing equipment status hierarchical management and version iteration operations based on health assessment results are as follows: By comparing health failure values ​​and failure thresholds in real time, when the health failure value is less than the failure threshold, it is determined to be in a healthy state. The current version configuration, operating parameters and health failure value are archived together in the device control database for the decision-making basis of the conflict handling module. When the health failure value is greater than or equal to the failure threshold, it is judged as a risky state, isolated from the service cluster, and a configuration reset command is triggered to restore the device parameters to the factory template. The device's current version value is compared with the component dependency graph. If the current version value is lower than the target version and all dependencies are satisfied, it is judged as a version lag, and an incremental upgrade package is issued when the version is lagging. If any component version in the current version value does not meet the dependency range, it is judged as a version break. The version marked as stable and with a continuous stable running time exceeding the stability threshold in the device's historical version record is queried as the previous stable version, and the version is rolled back to the previous stable version. If the health failure value calculated again is still greater than or equal to the failure threshold, an alarm report will be generated, and the status change, version update, repair operation and conflict handling decision will be stored in the device control database through log recording. S3 performs data conflict detection and analysis based on equipment observation segments and operational health, and performs overwrite, skip, and fusion operations based on the conflict detection and analysis results. The specific steps for conducting data conflict detection and analysis based on equipment observation segments and operational health, and performing overlay, skip, and fusion operations based on the conflict detection and analysis results, are as follows: Using device observation segments as input, a device fingerprint hash space is constructed. Collision detection is performed on the unique identifier of each device to be imported, and it is compared with the device records in the device control database to identify primary key uniqueness conflicts. Primary key uniqueness conflicts include duplicate device identifiers and duplicate network addresses. Based on the current version value of the device and the component dependency relationship graph, each component version number of the device to be imported is checked to see if it meets the version range required by the corresponding dependent component: if all component versions fall within the corresponding range, the version is considered compatible; otherwise, the version is considered broken and marked as a version chain conflict. A comprehensive decision-making process combining operational status indicators from the observation segments to be imported and equipment status records from the equipment records: For primary key uniqueness conflicts, if the observation segment is collected later than the device's most recent update time, and the number of failures in the observation segment is less than the number of failures recorded by the device, and the device is in a healthy state, then an overwrite operation is performed and the version number is incremented; if the device is in a risky state, then a skip operation is performed and the conflict record is temporarily stored in the log buffer. For version chain conflicts, if the version is broken and the number of operations and runtime in the observation segment are both greater than those in the device record, and the device is in a healthy state, then an intelligent merging operation is performed: based on field weights and collection timeliness, the version information, configuration files, and fault records of the observation segment to be imported and the device record are merged, a merged observation segment is generated in the temporary workspace, and its similarity is calculated with the device record. Only when the similarity exceeds the similarity threshold is it written to the device control database; if the device is in a risk state and the number of faults in the observation segment is greater than the number of faults in the device record, then a skip operation is performed and it is marked as a version conflict exception; all operation results and status changes are stored in the device control database through log records. S4, based on the health status and system busyness, conduct risk simulation analysis, and perform dynamic switching of transaction mode and atomicity guarantee operations according to the risk simulation analysis; The specific steps for conducting risk simulation analysis based on health status and system busyness are as follows: Obtain the health failure value and load value of the i-th device; multiply the health loss attenuation factor by the health failure value to obtain the attenuation product; take the negative value of the attenuation product and use it as the exponent to calculate the natural exponential function to obtain the health attenuation term; multiply the load adjustment factor by the load value to obtain the load product; add 1 to the load product to obtain the load compensation term; divide the health attenuation term by the load compensation term to finally obtain the success guarantee value of the i-th device; The specific steps for dynamically switching transaction modes and ensuring atomicity based on risk deduction and analysis are as follows: By comparing the successful protection value and the protection threshold in real time, the protection threshold includes T1 and T2; When the successful guarantee value is less than T1, it is determined to be an abnormal import item. The transactional write process of the device is blocked, the import status is marked as blocked, a risk warning instruction is generated, and the successful guarantee value and the blocking identifier are written to the log record. When T1 ≤ success guarantee value < T2, the partial success import mode is enabled, allowing the device to enter the import process but using flexible transaction processing. Based on the list of conflict items marked by the conflict handling module, the conflict records are skipped and non-conflicting data is continued to be imported. At the same time, the import progress and conflict records are pushed to the log record in real time. When the success guarantee value is ≥T2, the transactional import mode is enabled. A globally unique transaction identifier is generated and associated with all data to be written in this import. Before each write, an idempotent key is generated using the device identifier, transaction identifier, and key data fields for anti-duplicate verification. The key data fields include at least the device identifier, observation segment sequence number, and current version value. After verification, the data is temporarily stored in the transaction buffer. When all data verification is completed and the success guarantee value remains ≥T2, the transaction is committed uniformly. If any step fails or the success guarantee value falls below T2 before commit, a full rollback operation based on a pre-created rollback point is triggered, rolling back to the initial state before import to achieve full successful writing of device data or overall rollback. At the same time, the transaction identifier, import result, transaction status, dynamic change trajectory of the success guarantee value, and non-conflicting data skipping strategy execution record are written to the log. S5 aggregates key event flows throughout the entire process and builds a time-series index to realize the construction of a health map and the traceability management of the control database for the entire life cycle of equipment.

2. The remote version iteration and log management method for campus equipment clusters according to claim 1, characterized in that: The specific steps for collecting data from the campus equipment cluster are as follows: Collect campus equipment cluster data: Obtain real-time equipment operating status, failure count, current version value, and equipment configuration file data through the equipment management interface; obtain network bandwidth utilization through the equipment performance monitoring interface; The system obtains device fault records through device fault logs; pulls dependency declarations of all published components from the dependency declaration file to build a global component dependency graph; obtains device operation counts, runtime, and device load data through the device performance monitoring module; obtains the latest firmware version and configuration update time of the device through the version control system; and obtains the maximum version number supported by the device through device calibration parameters. The version number is then split into a three-dimensional integer sequence based on the major version number, minor version number, and revision version number. The three-dimensional integer sequence is sorted and mapped according to the lexicographical priority comparison rule to obtain the maximum version value.

3. The remote version iteration and log management method for campus equipment clusters according to claim 1, characterized in that: The specific steps for preprocessing and storing campus equipment cluster data and constructing an equipment control database are as follows: For each sensor record, device identifier, acquisition time, task batch number, and geographic coordinate identifier are synchronously written, and time alignment and window aggregation are performed based on the acquisition time. Sliding window denoising, outlier removal, and missing value interpolation are performed on the campus equipment cluster data. Multi-source records within the same observation time window are integrated into equipment observation segments, and each segment is assigned a globally unique segment sequence number. The device identifier, task batch number, and work area identifier are uniformly encoded and standardized using a distribution standardization algorithm to achieve uniform format of the identifier data. The minimum-maximum normalization algorithm is used for normalization processing to scale to a uniform numerical range. The standardized and normalized campus equipment cluster data storage will be completed, and an equipment control database will be built.

4. The remote version iteration and log management method for campus equipment clusters according to claim 1, characterized in that: The specific steps for aggregating key event streams across the entire process and constructing a time-series index to achieve the construction of a health map and control database traceability management for the entire lifecycle of equipment are as follows: Based on the equipment control database, key event streams from each stage of equipment status monitoring, conflict handling, and transaction import are acquired in real time. The key event streams include health status change events, version operation events, conflict detection events, and transaction import events. Among them, health status change events include health failure value change records and status switching times; version operation events include configuration reset command execution traces, incremental upgrade package distribution records, and version rollback operation details; conflict detection events include primary key collision results, version chain conflict markers, and operation details of overwrite and intelligent merging; and transaction import events include successful guarantee value calculation output, transaction identifier, import results, and transaction execution status. After attaching a timestamp and device identifier to each event stream, a time-series index is established using the combination of device identifier and timestamp as the primary key and event type and transaction identifier as the secondary key. This constructs a health graph of the entire device lifecycle. The health graph uses device identifier as the core node, time axis as the dimension, event type as the attribute label, and version iteration and conflict repair relationship as the edge to form a time-series evolution network of device health status. The accumulated log data is aggregated by device identifier and then injected back into the device control database to form a traceable device health record.

5. A remote version iteration and log management system for campus equipment clusters, employing the remote version iteration and log management method for campus equipment clusters as described in any one of claims 1-4, characterized in that, include: The data acquisition and preprocessing module is used to collect data from the campus equipment cluster, preprocess the data, store it, and build an equipment control database. The equipment status monitoring and management module is used to conduct quantitative health status assessments by combining equipment operating conditions and version parameters, and to perform equipment status hierarchical control and version iteration operations based on the health assessment results. The conflict handling module is used to perform data conflict detection and analysis based on equipment observation segments and operational health, and to perform overwrite, skip, and fusion operations based on the conflict detection and analysis results. The transactional import module is used to perform import risk simulation analysis based on the health status and system busy level, and to perform dynamic switching of transaction mode and atomicity guarantee operations based on the risk simulation analysis. The log recording module is used to aggregate key event streams throughout the entire process and build a time-series index to realize the construction of a health map and the traceability management of the control database for the entire life cycle of the device.

Images