An IT asset whole life cycle tracking and maintenance decision integrated management system

Abstract

The application discloses an IT asset whole life cycle tracking and maintenance decision integrated management system. The system establishes asset root identity from hardware identification of independent acquisition path or trust root, takes name, address and location as alias with validity period, and saves into warehouse, enables, migrates, maintains, replaces and retires in non-overlapping life events. Hardware cumulative count is converted into running exposure after reset, wraparound and unit identity verification, and further forms a health state interval with model version. Maintenance candidates must be simulated on the current topology snapshot through capacity, redundancy, task migration, maintenance window and spare part interface to generate execution preparation records; after execution, new and old identities and minimum function probes are closed loop, and only attributable samples are used for model calibration.

Description

Technical Field

[0001] This invention relates to the fields of IT asset identity unification, lifecycle event tracking, and maintenance decision-making, specifically to an integrated management system for IT asset full lifecycle tracking and maintenance decision-making. Background Technology

[0002] IT assets generate various identifiers during warehousing, shelving, component replacement, resource allocation, and maintenance, including purchase numbers, serial numbers, management addresses, configuration items, and work orders. When associated with the ledger primary key, replacing a motherboard or accelerator card may be mistakenly considered a change to the entire machine, and historical operational data may be lost as the ledger is overwritten.

[0003] Arranging maintenance based on service life or fixed thresholds does not take into account the actual exposure of replaceable units to temperature, power cycles, media writing, and fault retries, nor does it simulate the impact of downtime on redundancy and tasks, which may lead to premature replacement or operation during high-risk windows.

[0004] Common asset management systems generate maintenance reminders based on ledger fields, depreciation years, or single health status ranges. This makes it difficult to maintain consistency between asset identity, exposure contribution, status version, and maintenance impact after component replacement, asset transfer, historical data delays, and topology changes.

[0005] Asset names, management addresses, and physical slots change upon migration or replacement, while health counts may restart after controller reset, component replacement, or bit width wrap-around. If the identity and counting period are not bound to a replaceable unit, health trends and maintenance results will be incorrectly assigned; if only thresholds are considered, the impact of offline actions on remaining resources cannot be determined.

[0006] This invention uses trusted asset root identities to link dual-time life events and operational exposure count periods, expressing data uncertainty as intervals rather than single values ​​for health results. Automated maintenance undergoes topology impact simulation before execution, and is then confirmed after execution using both old and new identities and functional probes, with strict limitations on samples that can enter model calibration.

[0007] Asset health values ​​are not directly given by the current alarm or a single runtime. Uncoverable life events are first accumulated to the operational exposure of replaceable units, and then the health status with upper and lower bounds is calculated according to the event version. Before maintenance actions are submitted, the impact on availability, risk transfer, and spare parts occupancy is simulated, and the execution results are continued to be added to the original event chain for calibration. Summary of the Invention

[0008] This invention solves the problems of identity mismatch and exposure miscalculation caused by changes in asset aliases, hardware cumulative count resets or wrap-arounds, and enables maintenance decisions to have resource impact verification before execution and identity and function closed loop after execution.

[0009] The integrated management method, which focuses on the continuous processing of asset identity, life events, and maintenance decisions, includes the following steps: S101 (establishing hardware root identity), S102 (registering non-coverable life events), S103 (accumulating unit operation exposure), S104 (calculating versioned health intervals), S105 (simulating maintenance impact), S106 (gating and executing maintenance), and S107 (confirming results and calibrating the model).

[0010] This invention forms a closed loop along the path of "root identity—life event—operational exposure—health zone—impact simulation—performance calibration". The original identity conditions, counting processing, and model calibration constraints are fully expanded as follows.

[0011] Collect at least two unique hardware identifiers or hardware proof information from different acquisition paths or roots of trust for the complete machine and replaceable units, where at least one of them is an immutable hardware identifier or verifiable hardware proof, establish an asset root identity with a trust level, and associate the hostname, management address, bus location, and physical location as aliases or corroborating information with valid ranges with the asset root identity.

[0012] The processes of warehousing, installation, activation, migration, repair, replacement, and decommissioning are converted into asset life events. Each asset life event records at least the event type, effective time, registration time, previous state summary, subsequent state summary, replaceable unit identity, source evidence, and event sequence number. Late events are saved as newly registered versions without overwriting historical events.

[0013] The device controller reads the cumulative values ​​of temperature dwell time, power cycle, media write, error correction, and fault retry. Based on the count bit width, previous value, device reset event, sampling interval, maximum count growth rate, and replaceable unit identity, the counting period is determined and the operational exposure increment is calculated. The operational exposure increment is attributed to the asset root identity of the replaceable unit.

[0014] The health status interval is calculated based on the lower limit of the specification, the upper limit of the specification, the contribution weight, and the data quality of each operational exposure corresponding to the target equipment category, and the model version and the contribution of each operational exposure are saved.

[0015] The health status interval is compared with the automatic maintenance threshold and manual review threshold fixed in the model version. When the lower bound of the health status interval reaches the automatic maintenance threshold, an automatic maintenance candidate is generated. When only the upper bound of the health status interval reaches the manual review threshold, only an inspection candidate is generated and no automatic offline or replacement action is generated.

[0016] Simulate candidate maintenance actions on a read-only snapshot during the current resource topology period. The simulation includes checking remaining capacity, redundant paths, data reconstruction or task migration, maintenance window and spare parts interface contract after removing the target device, forming blocking items and release conditions.

[0017] Only when there are no unresolved blocking items in the automatic maintenance candidate, the spare parts interface contract matches, and the identity and function probes after maintenance have a collection path, will an execution preparation record for asset offline, task migration, or component replacement be generated.

[0018] After executing the candidate maintenance action, the old unit exit status, the new unit root identity, interface enumeration and minimum function probe are collected. The execution result is confirmed and only the fault mode that has been physically checked, whose maintenance action corresponds to a single faulty unit and whose function probe is closed after maintenance is used as the calibration sample for the subsequent model version.

[0019] Furthermore, the asset root identity is cross-confirmed by at least two of the following: security chip proof, immutable serial number, device-side firmware unique identifier, and out-of-band controller proof. The at least two proofs are obtained through different acquisition paths and include at least one verifiable hardware proof or immutable serial number. Bus location, management address, and physical location are only used as evidence with valid ranges and do not participate in the counting of two independent sources. When sources conflict, candidate identities are established and automatic maintenance control is suspended until new evidence closes the candidate identities.

[0020] Furthermore, for non-volatile storage components, the cumulative data write volume, cumulative duration above alarm temperature, power cycle count, number of media or data integrity errors, and error log entries are read from their controller health information. For an n-bit cumulative counter, the operational exposure increment is calculated as current+2^n-previous only when it can be determined, based on the maximum growth rate of the counter and the sampling interval, that at most one wrap-around occurs between adjacent samples. When the current value is less than the previous value and the reset period remains unchanged, a new counting period is established and the current value is used as the new baseline. When it is impossible to distinguish between wrap-around and reset, the operational exposure increment is saved as the interval from zero to current+2^n-previous. When it is impossible to guarantee at most one wrap-around, the corresponding source quality is set to unknown. Neither of these conditions will output a definite maintenance instruction.

[0021] Furthermore, for the i-th type of operational exposure E_i in the effective operational exposure index set I, z_i = clip((E_i-L_i) / (U_i-L_i),0,1) is calculated based on the lower specification limit L_i and upper specification limit U_i of the target device category, where clip(x,0,1) = min(1,max(0,x)); the basic risk quantity r = 1 - ∏_{i∈I}(1-w_i) is calculated. z_i) and uncertainty δ=min(1,Σ_{i∈I}w_i(1-q_i)), output health status interval H=[max(0,r-δ),min(1,r+δ)]; where w_i≥0 and Σ_{i∈I}w_i=1, q_i∈[0,1], L_i, U_i, w_i and threshold are fixed with model version; no definite maintenance instructions are output when specification boundary is missing, U_i is not greater than L_i, key source is unknown or I is empty.

[0022] Furthermore, when simulating candidate maintenance actions, a maintenance impact subgraph is constructed. The maintenance impact subgraph includes the target device, the tasks running on it, redundant devices, data replicas, interconnection paths, and candidate spare parts. After deleting the target device and its associated edges from the subgraph, the available nodes for the task, the lower bound of the remaining capacity, the effective redundancy in different fault domains, the rebuild bandwidth and the upper bound of the completion time, as well as the bus interface, capacity, and minimum firmware capability of the spare parts are verified in sequence. Any verification failure forms a blocking item.

[0023] Furthermore, the execution preparation record includes the asset root identity, current life event version, current topology period, expected write set, maintenance impact summary, spare part identity requirements, idempotent action number, and compensation entry. Confirmation and submission are only confirmed when the identity and function observations collected independently are consistent with the execution preparation record. If the interface times out and the external status is unknown, the actual status of the device is read first, and actions with side effects are not repeated.

[0024] Furthermore, model calibration only uses life events that simultaneously satisfy the conditions of physical inspection providing a fault mode, post-maintenance functional probe closure, and maintenance actions corresponding to a single fault unit. For the same equipment category and operational exposure item, under the constraints of w_i≥0 and Σ_iw_i=1, at least one of Li, U_i, or w_i is updated according to the exposure distribution of confirmed samples. The health interval coverage threshold and automatic action false trigger threshold are checked on time-isolated verification samples. Only when both pass are a new model version with an effective time generated. Life events such as label conflicts, unconfirmed faults, or multiple simultaneous unit replacements that cannot be attributed do not update Li, U_i, or w_i, but only reduce the corresponding q_i or increase the uncertainty penalty for that source. The new version does not cover historical models and historical health state intervals.

[0025] Corresponding to the aforementioned methods, this invention also discloses an IT asset lifecycle tracking and maintenance control system, characterized in that it includes an asset discovery agent, a root identity resolver, a dual-time life event memory, a hardware counter processor, a health interval calculator, a maintenance candidate generator, a maintenance impact simulator, a maintenance execution controller, and a model calibrator. Each component is configured to perform the method described in any one of claims 1 to 7. The maintenance candidate generator distinguishes between automatic maintenance candidates and inspection candidates based on health status intervals and versioning thresholds. The maintenance execution controller only opens the automatic execution interface when the impact simulation of the automatic maintenance candidate does not output blocking items and identity and function probes can be collected. The model calibrator only uses confirmed and attributable samples to generate new model versions.

[0026] To perform the aforementioned processing, the present invention also discloses an IT asset maintenance control device, characterized in that it includes a processor, a memory, a device-side management interface, a resource orchestration interface, and a maintenance execution interface, wherein the memory stores asset life events, operational exposure count periods, model versions, and maintenance impact subgraphs, and the processor implements the method described in any one of claims 1 to 7 when executing program instructions.

[0027] The present invention also discloses a non-transitory computer-readable storage medium having program instructions stored thereon, characterized in that the program instructions, when executed by a processor, implement the method described in any one of claims 1 to 7.

[0028] Life events and operational exposures are attributed to the asset root identity and its replaceable units, enabling the maintenance of historical continuity of the same physical object after changes in address, slot, or hostname, and retaining late events as newly registered versions.

[0029] The healthy zone first distinguishes between automatic maintenance and manual inspection, and then simulates the blocking capacity or insufficient redundancy actions based on topological influences; the execution confirmation and sample calibration use independent identity and functional observation to avoid unconfirmed results from back-contaminating the model. Attached Figure Description

[0030] Figure 1 A flowchart for IT asset lifecycle tracking and maintenance decision-making.

[0031] Figure 2 This is a functional structure diagram of an integrated management system for IT asset tracking and maintenance decision-making.

[0032] Figure labeling: Hardware root identity manager 110, life event ledger 120, running exposure accumulator 130, health interval evaluator 210, maintenance impact simulator 220, execution gating and work order interface 310, result confirmation and model calibrator 320. Detailed Implementation

[0033] The following describes the asset root identity, life events, hardware count periods, health intervals, and maintenance impact subgraphs. Each automated action references the corresponding identity version, model version, and resource topology period.

[0034] An asset lifecycle event must include at least the following: asset_root_id, replaceable_unit_id, event_type, valid_time, record_time, before_digest, after_digest, location_alias, counter_epoch, exposure_delta, evidence_refs, event_seq, and integrity_digest. The asset_root_id must be verified by at least two hardware evidences from different acquisition paths or roots of trust, and at least one must be an immutable identifier or verifiable hardware proof. Bus location, physical location, hostname, and management address are only used as aliases or corroborating evidence with valid timestamps and must not be combined with another field returned by the same firmware path to impersonate two independent sources. Events are appended by record_time, and when querying a historical moment, both valid_time and the version registered at that time are restricted.

[0035] For non-volatile storage components, the device-side agent reads the cumulative data write volume, cumulative duration above alarm temperature, power cycles, media or data integrity errors, and error log counts. It also saves the field width, unit, controller reset generation, sampling sequence number, maximum growth rate, and sampling interval. Calculation of current+2^n-previous is only allowed if the maximum growth rate multiplied by the sampling interval is less than 2^n; a new counting period is established when a reset record is established. When both rewinding and reset are possible, the increment interval is [0, current+2^n-previous] and the quality is reduced. It cannot be guaranteed that the quality will be set to UNKNOWN at most one rewind. Accounting with negative numbers, zero values, or specific point values ​​is prohibited.

[0036] The health calculator loads read-only parameter snapshots by device category. Exposure E_i in the valid set I is normalized using specification boundaries L_i and U_i, and z_i=clip((E_i-L_i) / (U_i-L_i),0,1) is calculated. Then r=1-∏_i(1-w_i z_i) and δ=min(1,Σ_iw_i(1-q_i)), where w_i≥0, Σ_iw_i=1, and q_i∈[0,1]. The model version simultaneously saves the manual review threshold θ_review and the automatic maintenance threshold θ_auto, where θ_auto≥θ_review. Automatic maintenance candidates are generated only when the lower bound of H reaches θ_auto; only inspection candidates are generated when the upper bound of H reaches θ_review. This interval is a maintenance gating state variable and is not interpreted as failure probability or remaining life.

[0037] The nodes in the maintenance impact subgraph include at least the target hardware unit, the task being carried, the data replica, the redundant unit, the interconnection link, the candidate migration node, and the spare parts. The nodes record the carrying capacity, replication, routing, fault domain, and interface dependencies. After deleting the target unit during the frozen topology period, the simulator first checks if there are still available replicas or paths located in different fault domains. Then, it assigns tasks based on the lower bound of capacity and calculates the data reconstruction amount divided by the lower bound of available bandwidth to obtain the upper bound of reconstruction time. Finally, it verifies whether this upper bound falls within the maintenance window and whether the spare parts interface contract covers the original unit. The input values ​​and blocking reasons for each step are saved with the simulation summary.

[0038] Candidate maintenance records enter the impact simulation from the candidate stage; if there are unresolved blocking items, the branch enters the blocked stage and cannot be executed. When the threshold is closed, it sequentially enters the preparation for execution, execution, and pending functional verification stages; when the interface times out or the receipt conflicts with the out-of-band status, it enters the submission unknown stage. Only after reading the actual status on the device side and orchestration side can it enter the pending functional verification stage, retry preparation stage, or isolation stage. Directly repeating offline or replacement is prohibited. When functional verification is closed, it enters the confirmed stage; when verification fails, only reversible software orchestration actions are compensated. When physical replacement is irreversible or the new and old identities are unclear, it enters the isolation stage and keeps the task entry closed, and is not uniformly marked as compensated.

[0039] After component replacement, the root identity and bus location of the new unit are read first, followed by device enumeration, minimum read / write or calculation, error register reading, and redundancy recovery probes. If the new identity does not match the spare parts requirements in the preparation record, the maintenance action is not confirmed, and the new unit must not inherit the old unit's operational exposure or health range; the old unit's life events are transferred to the pending detection or decommissioning candidate. Only when the identity and all necessary function probes are closed can the orchestrator allow the resumption of tasks and establish the first counting period of the new unit.

[0040] Model calibration samples must simultaneously possess pre-maintenance exposure contributions, failure modes confirmed by physical inspection, attributable single fault units, executed actions, and functional observations of post-maintenance closure. The calibrator only updates L_i, U_i, or w_i within the corresponding equipment category and projects to the constraint set where w_i≥0 and Σ_iw_i=1; candidate versions are only registered and effective after simultaneously satisfying the health interval coverage threshold and the automatic action false trigger threshold on time-isolated validation samples. Records with no conclusions from physical inspections, multiple simultaneous unit replacements that cannot be attributed, or functional probe failures do not update the above parameters, but only reduce q_i or increase uncertainty penalties; historical life events continue to use the original version.

[0041] Taking the example of an increase in errors after a non-volatile storage component is migrated from server A to server B, the root identity resolver uses the controller's unique identifier and out-of-band proof to maintain the component's historical continuity; the counter processor identifies a controller reset and establishes a new counting period, not treating the zeroing difference as a negative exposure. The health interval shows an increased contribution from media errors, but there are missing measurements of temperature sources, thus maintaining the interval rather than giving a definitive lifetime. The impact simulator checks another fault domain copy, rebuilds bandwidth, maintenance windows, and spare parts interfaces after deleting the component; a replacement preparation record is generated only after all thresholds are closed, and the replacement is confirmed with the new identity and read / write probes after completion.

[0042] Figure 1 This demonstrates the closed loop of hardware root identity throughout life events, operational exposure, health intervals, maintenance impact simulation, execution gating, and result calibration; Figure 2 It shows the connections between the device management interface, data ledger, health decision layer, and maintenance execution interface.

[0043] See Figure 1 Asset and component identities serve as a common index for life events and operational exposures, with health intervals driving the simulation of maintenance impacts. Maintenance execution is gated by blocking items; once the results are confirmed, only new calibration samples and model versions are generated, without rewriting the original events.

[0044] Figure 1 The seven steps shown constitute a maintenance decision and execution record processing procedure. Step S107 ends the process after writing the confirmation result and versioned calibration sample; subsequent life events will trigger a new processing batch, rather than returning directly to step S101 from step S107.

[0045] This embodiment uses asset life events and health decision records as the common record carrier for the processing chain. Hardware root identity, component unit identity, and event version are used to lock the input attribution, while the identity validity period, operational exposure period, maintenance plan window, and result observation period limit the applicable scope of each result; records are appended, and the active version is only updated after the content, evidence citation, and parent version summary have all passed verification. Version conflicts, late records, or unknown fields are registered separately and are not concatenated with data from other periods.

[0046] Step S101 involves establishing a hardware root identity. Assets and components are cross-verified using at least two independent sources, with the management address and hostname serving as aliases with valid ranges. When replacing a component, a new unit identity is created without overwriting the old one. Before publishing the results of this stage, it is also necessary to verify that the "event occurrence time and registration time are separate." If this cannot be proven from the current snapshot, the result remains in a pending verification state and points to the most recent stable version.

[0047] After proceeding to step S102, the system completes the registration of indelible life events. Monotonic event numbers are used within the same hardware root, and source retries are deduplicated based on event summaries; late events generate new registration versions while retaining the old query view. This stage uses "historical events cannot be overwritten, only appended corrections" as a substantive threshold; if the threshold is not met, only conflict items, scope of impact, and evidentiary gaps are registered.

[0048] Step S103 is used to accumulate unit operational exposure. First, the sampled values ​​are verified according to the sensor range and counter loopback rules. After the component moves across the entire machine, its own exposure continues to be accumulated, and environmental exposure is allocated according to the actual time period. Only if "the exposure amount belongs to the currently valid replaceable unit" is true in the current period can the output be read by the next step; otherwise, the active version remains unchanged.

[0049] After completing the previous stage, step S104 calculates the versioned health interval. It outputs the risk level and confidence interval based on operational exposure, failure events, and environmental evidence; when key measurements are missing, the interval is expanded and the automatic decision level is reduced. The judgment of "expanding the health interval for data gaps instead of filling in default values" is limited to frozen snapshots, and unknown operands are not filled in according to default values.

[0050] The process then proceeds to step S105, where the system simulates the impact of maintenance. Redundant paths, remaining capacity, task shadow placement, and spare parts capability signatures are checked. Tasks that cannot be placed or spare parts that do not meet the interface contract become blocking items. Before publishing the results of this stage, it is also necessary to verify that "the maintenance simulation uses the current topology and retains the model version"; if this cannot be proven from the current snapshot, the results remain in a pending verification state and point to the most recent stable version.

[0051] In step S106, the system completes gating and performs maintenance. A work order is only issued to the maintenance interface when the simulation passes and the check candidate is closed. The execution process is bound to the asset identity, the plan window, and the checkpoint.

[0052] Step S107 involves confirming the results and calibrating the model. After the replacement is completed, the old unit is verified to be out of service, the new unit is identified, the interface is visible, and the minimum functionality is checked. The deviation between the actual failure modes and the predicted contributions forms a calibration sample, and the original model version remains replayable.

[0053] The processing chain saves dependencies by input summary. If an underlying record becomes invalid, only results that directly or indirectly reference that record are relegated to the candidate state and recalculated; other results remain valid. If any release threshold is not met, asset decommissioning, component replacement, task migration, or retirement registration is not submitted; instead, the cause of failure, affected objects, recertification entry point, and security recovery point are retained. Records provided externally include version period, evidence location, and boundaries still awaiting confirmation.

[0054] Furthermore, the asset root identity is cross-verified through at least two independent hardware unique identifiers, proof information, or physical location sources.

[0055] Furthermore, the asset life event simultaneously records the validity period and registration period, and appends a version when a late event arrives without overwriting the history.

[0056] Furthermore, operational exposures are accumulated by replaceable unit identity and remain continuous after a unit moves across the entire system.

[0057] Furthermore, when the cumulative counter wraps around or resets, a new counting period is generated based on the counting bit width, the previous value, and the hardware identity.

[0058] Furthermore, the health status is output in interval form and records the contribution, data quality, and model version of each operational exposure.

[0059] Furthermore, the maintenance impact simulation includes resource offline, redundant paths, task migration, and spare parts interface contract verification. No automatic execution instructions are generated when there are blocking items.

[0060] This solution treats asset lifecycle events as common record objects referenced in all steps, using versions and processing periods to isolate data from different batches. Based on this, it establishes root identities for assets and replaceable units, employs immutable dual-time event recording configuration and exposure increments, calculates versioned health status with data quality ranges and contribution items, and generates closed-loop work orders after simulating the impact of maintenance actions on risk, dependencies, and service continuity on the current topology. Specifically, "confirmation" requires the existence of direct technical observations or mutually independent indirect observations with consistent input summaries; "Unknown" is maintained until the evidence is closed, and the unknown is not interpreted as negation.

[0061] The raw data processed includes asset and replaceable unit identities, procurement, shelving and change events, temperature, writes, cycle and error exposures, and event occurrence and registration times. Interface requests carry object stability identifiers, expected versions, calling permissions, and idempotent keys, while responses carry actual versions, collection time intervals, quality flags, and content summaries. Data from caches, mirrors, or inferences retains its direct source; unavailable fields use explicit unknown values, and unavailable facts are not filled with zero values ​​or old records.

[0062] Parameters, decision thresholds, and weights are fixed simultaneously with the asset lifecycle event version. Thresholds can be determined by the allowable range of equipment specifications, the quantile of on-site calibration samples, the upper limit of historical normal window fluctuations, and task delay budgets or risk budgets; parameters remain unchanged within the same processing period. When the sample size is insufficient or the denominator is zero, the calculation result is marked as incalculable, and fixed empirical numbers are not used for supplementary calculation in this case.

[0063] After reading the asset lifecycle events, the control program first performs checks on field type, object existence, version continuity, permission scope, and integrity summary. Then, it calls to establish the asset root identity to generate a work order and uses feedback to calibrate the corresponding processor. Each processor writes the result field it is responsible for, without overwriting the input from the previous step. When rules or topology need to be corrected, the next version is generated, and the set of affected objects is retrieved from the dependency index.

[0064] Data is transferred between processing steps using structured objects. The previous step outputs the root identity chain or dual-time lifecycle ledger and writes it to the parent version field. The next step re-verifies that the parent version is still the current valid version before generating maintenance work orders and calibration records. If a replacement event is registered late, only the branches that depend on the failed interface are frozen; other unrelated branches remain in the confirmed state.

[0065] Candidate results are processed according to two levels of rules: The first level establishes a feasible set with hard constraints based on the separation of event occurrence time and registration time, the fact that historical events cannot be overwritten but can only be added and corrected, and the attribution of exposure to the currently valid replaceable unit; The second level sorts candidates within the feasible set only based on risk, latency, resource consumption, or evidence completeness. If no candidate satisfies all hard constraints, the system outputs a conflict item and terminates the selection, while the necessary conditions remain unchanged.

[0066] Before committing, the maintenance actions, feedback, and current asset lifecycle event header versions are read again and compared with the input summary saved during the preparation phase. Committing is allowed if the summaries match; if the summary changes but does not affect the current dependent branches, confirmed outputs are reused; if a summary change hits a dependency index, only the affected branches are recalculated, and unaffected branches are not completely rolled back.

[0067] The final maintenance work order and calibration record are published through the results interface, which simultaneously returns the status, applicable period, input summary, evidence path, and unresolved boundaries. The caller can only perform subsequent irreversible actions when the status is confirmed and the applicable period is still valid; candidate, unknown, and contradictory results are only used for diagnosis, supplementary evidence, or manual review.

[0068] The asset life events are structured records that run through the processing chain of this invention, and include at least the hardware root identifier, replaceable unit identifier, event type, effective time, registration time, previous state summary, subsequent state summary, operational exposure increment, source evidence, responsibility work order, event sequence number, and integrity check value. Life events are recorded append-only, recording changes in status such as procurement, installation, activation, migration, maintenance, replacement, and decommissioning. The exposure of replaceable units migrates with their own identity and is not reset due to changes in the overall system.

[0069] The hardware root identity can be confirmed by a combination of the security chip certificate, firmware unique identifier, serial number and physical location; when there is a conflict of evidence, a candidate identity is formed.

[0070] Operational exposure is a segmented accumulation of measurable technical quantities such as temperature dwell time, power cycling, write volume, link error correction, and fault retry, and is not equivalent to simple power-on duration.

[0071] The system connects to procurement and warehousing, out-of-band management, configuration management, monitoring, job orchestration, and work order platforms. The device-side agent reads the unique hardware identifier, replaceable unit identifier, and cumulative counter; the management system does not use the user's entered name as a unique identifier.

[0072] In step S101, assets and components are cross-verified using at least two independent sources, with the management address and hostname serving as aliases with valid ranges; when replacing a component, a new unit identity is created without overwriting the old one.

[0073] In step S102, monotonic event sequence numbers are used within the same hardware root, and source retries are deduplicated by event summary; late events generate new registration versions and retain the old query view.

[0074] In step S103, the sampled values ​​are first verified according to the sensor range and counter looping rules. After the component moves across the whole machine, it continues to accumulate its own exposure, and the environmental exposure is allocated according to the actual time period.

[0075] In step S104, the risk level and confidence interval are output by combining operational exposure, failure events and environmental evidence; when key measurements are missing, the interval is expanded and the automatic decision level is reduced.

[0076] In step S105, redundant paths, remaining capacity, task shadow placement, and spare parts capability signatures are checked. Tasks that cannot be placed or spare parts that do not meet the interface contract are blocked.

[0077] In step S106, a work order is issued to the maintenance interface only when the simulation passes and the candidate check is closed. The execution process is bound to the asset identity, the plan window, and the checkpoint.

[0078] In step S107, after the replacement is completed, the old unit exits, the new unit is identified, the interface is visible, and the minimum functionality is verified; the deviation between the actual failure mode and the predicted contribution forms a calibration sample, and the original model version remains replayable.

[0079] H=[h_low,h_high]=F(Etemp,Ecycle,Ewrite,Eerror;Vmodel,Qdata)

[0080] In a reproducible implementation, first proceed according to the lower limit of the equipment specifications. and upper limit Expose the i-th type of operation Normalization Then calculate the basic risk. ,in Contribution weights that are fixed with each model version and sum to 1. Based on the quality of each source. Calculate uncertainty Output If equipment specifications are missing or the quality of key sources is unknown, no definitive maintenance conclusion will be output.

[0081] In the formula, H represents the health status interval, E represents temperature dwell time, power cycle, media write, and error exposure, respectively, Vmodel represents the model version, and Qdata represents the data quality. The output interval is only used to form a traceable candidate maintenance ranking basis, and does not represent the failure probability or remaining life, nor does it replace the equipment manufacturer's safety boundary.

[0082] The cumulative counter wraps around by identifying the bit width and the last read value; if the hardware proves that the device has not changed and the counter returns to zero after the device is reset, a new counting period is created and the difference is not recorded as a negative exposure.

[0083] Candidate maintenance actions include observation, load limiting, relocation, component replacement, and complete machine shutdown. The system first verifies the relevance of the action to the risk contribution, and then simulates the resource impact to avoid directly replacing components based solely on the overall score.

[0084] Example 2 illustrates the scenario where a storage medium is moved from server A to server B and replaced with a spare after a period of time. If only the overall asset number is used for statistics, the historical writes on server A and the error counts on server B would be fragmented; this method uses the root identity of the medium for continuous association.

[0085] Asset root identity can be cross-verified from at least two independent sources: device sequence, out-of-band verification value, bus location, and physical disk location. After a replaceable unit is moved, the old physical location relationship ends and a new relationship is established, while the unit root identity remains unchanged; in the event of a source conflict, candidate identities are retained, and automatic maintenance control based on hardware status and topology impact is suspended.

[0086] Life events include event type, previous state summary, subsequent state summary, effective time, registration time, executing entity, and evidence citation. Late entries of maintenance facts are added to a new registration version without altering the previously visible system state; when querying why a particular maintenance was performed, the set of events already registered at that time can be restored.

[0087] The cumulative counter is converted to an increment based on the counting period. If the current value is less than the previous value, it is first determined whether to wrap around based on the bit width, and then determined whether to reset based on the device reset event and root identity; if it cannot be distinguished, the increment segment is marked as an interval instead of being zeroed. After the medium moves across the entire machine, the unit counting period is used again, and the medium baseline is not automatically cleared when the entire machine is reset.

[0088] Health status is determined by equipment specification boundaries, stable distribution within the same category, and operational exposures. Each exposure is recorded for its contribution direction, contribution range, data quality, and model version; when key data is missing, the health range is expanded, and historical averages are not used as current observations.

[0089] The maintenance impact simulation uses the current topology as input. After removing candidate assets, redundant paths, migrated nodes, available maintenance windows, and spare parts interface contracts are checked sequentially. Replacement resources sharing the same fault domain as candidate assets are not considered valid redundancy. The simulation results list the blocking items and their removal conditions.

[0090] In this example, the incremental media error retry rate continues to rise, but server B still has another redundant medium. The system simulates the target medium going offline, data reconstruction, and task migration to confirm that the reconstruction bandwidth will not exceed the maintenance window; only after the spare part's interface, capacity, and minimum firmware version all match is a replacement work order with evidence references generated.

[0091] After replacement, first read the spare part's root identity, verify the disk location relationship, and then execute device enumeration, read / write, and redundancy recovery probes. Once all probes pass, the old media's life event enters a decommissioning or pending detection state, and the new media establishes its first operational exposure baseline; if the identity does not match, the work order remains incomplete and prevents erroneous inheritance of the old health state.

[0092] Health model calibration does not rewrite historical conclusions. New observations are used to generate new versions of the model, with the applicable date noted; when old work orders need to be reviewed, the event set and model version at that time are still used, thus maintaining the traceability of maintenance control based on hardware status and topology impact.

[0093] Specifically, in terms of data structure, each asset lifecycle event includes at least a summary of its before and after states, physical location, operational exposure, counting period, health contribution, and a maintenance impact subgraph. Business identity and the database's auto-incrementing primary key are stored separately; the business identity is determined by the asset's root identity, validity period, and registration version, while the auto-incrementing primary key is only used for physical location. Updates use append-only versions, with the previous version recording its termination reason and remaining readable, thus enabling differentiation between object changes, repeated data collection, and reprocessing of the same object.

[0094] Specifically, regarding state transitions, asset lifecycle events can be in the following states: already in storage, installed, running, migrating, under maintenance, awaiting replacement, decommissioned, or conflicting. Each transition is triggered by a specific event, and the transition record includes the states before and after the transition, the triggering field, and the rejection reason. The recovery procedure only replays confirmed transitions and does not infer intermediate states from the final field values; this allows for different handling of execution interruptions, delayed messages, and partial successes.

[0095] For asset decommissioning, component replacement, task migration, or retirement registration, the system first generates a preparation record containing the expected write set and compensation entry point, and then calls the execution interface. Commit is only confirmed when the object identities of the execution receipt, independent observation, and preparation record match. If the interface times out and the external state is unclear, it is marked as an unclear commit, and the external observation is read first; actions with side effects are not immediately reissued.

[0096] Specifically, for repeated execution, the idempotent index is a hash of the asset root identity, validity period, registered version, and action number. When the same index is reached again, if the input digest is the same, the already confirmed output reference is returned; if the digest is different, an idempotent conflict is registered and overwriting is rejected. In multi-processor contention, a unique writer is determined through conditional write or comparison exchange, and the processor that does not obtain the write right becomes the result reader.

[0097] All time-related fields are registered in intervals, which cover the valid intervals for life events, the fact registration intervals, and the maintenance window. Two intervals are only allowed to be used in the same calculation if they still intersect after considering clock errors and the source period has not been reset. When the interval uncertainty exceeds the rule's allowable value, the system expands the set of records to be supplemented instead of shortening the interval; late records are written to their original period without modifying the currently published conclusion.

[0098] Configurable parameters during implementation include count wraparound boundaries, health intervals, maintenance risk limits, and spare parts contract scope. Parameter values ​​are derived from equipment specifications, offline calibrations, or prior stable operating samples. At the start of processing, the parameter values, units, source summary, and applicable objects are written to a read-only parameter snapshot. Specific values ​​can be changed during implementation, but parameter items corresponding to security commits, version consistency, or integrity checks must not be deleted.

[0099] Abnormal recovery does not cross the following boundaries: undoing unclosed offline or migration actions, and maintaining the old component's root identity and operational exposure so that they are not inherited by new components. Each rollback request has an independent action number, and upon successful execution, a recovery observation and post-recovery summary are appended. If a step cannot be recovered, subsequent compensation dependent on that step is discontinued, on-site evidence is preserved, and the object is placed in isolation to prevent null values ​​from masquerading as recovery completion.

[0100] To implement the above method, an asset discovery agent, life event storage, health calculator, impact simulator, and maintenance execution interface can be configured. Control messages use structured messages with length and version numbers. The receiver checks each required field, enumeration range, and checksum. Older versions of the receiver can ignore unknown optional fields, but must refuse to process unknown required fields and return the supported mode version.

[0101] For asset samples involving component replacements, complete machine migrations, serial number resets, and multiple maintenance operations, compare the data archived according to the current serial number with the hardware root identity event spectrum. Check the number of identity chain breaks, the number of reversed or overridden life events, the cumulative error of operational exposure, the deviation between maintenance simulation and actual receipts, and whether the replaced unit can be traced back to the original complete machine.

[0102] After a power outage or process restart, the recovery process first reads the most recent complete checkpoint, then scans subsequent preparation and confirmation records. Only asset life events that are fully verified and confirmed are entered into the activity index; objects with only preparation records are determined to be continued, compensated, or isolated based on external observations. The scan results are written to a new recovery period without altering the sequence numbers before the interruption, thus preserving the causal boundaries required for incident analysis.

[0103] When the current and subsequent state summaries, physical locations, operational exposures, count periods, health contributions, and maintenance impact subgraphs are provided by different interfaces, the adaptation layer simultaneously registers and saves the original and normalized values, units, source versions, and conversion rules. Fields that fail to be normalized remain unknown with a reason code and are not converted to zero. If multiple sources provide conflicting results for the same field, an asset life event candidate set is formed according to the pre-configured evidence level, and the step using the field determines whether to supplement the data collection or stop the submission.

[0104] When candidate asset life events have the same priority, the processor sequentially checks the satisfaction of hard constraints, the completeness of evidence, the recovery cost, and the stability indicator. The last item is only used to determine the order and does not change the technical feasibility. Each component used for sorting retains its original value, so that the same selection is obtained when replaying under the same input, and it can explain which constraint among the count wraparound boundary, health interval, maintenance risk limit, and spare parts contract range is excluded from the candidate.

[0105] When persisting a processing result, first arrange the before-and-after state summaries, physical location, operational exposure, count period, health contribution, and maintenance impact subgraphs by field number, specifying units for all values ​​and writing the enumerated values ​​into the schema version, then calculate the content summary. Strings only undergo protocol-defined whitespace and encoding normalization; resource names are not fuzzy merged. This ensures that the same asset lifecycle event yields the same summary at different processing nodes, and two objects with only the same display name will not be mistaken for the same object.

[0106] This example also generates a version identifier for each version of the content. Let the normalized business key be K, the processing period be E, the input digest be D, and the parameter snapshot digest be P. Then the version identifier can be H(K∥E∥D∥P), where H is the collision-resistant hash function selected by the system, and the concatenation operator includes the field length. K corresponds to the asset root identity, validity period, and registered version. In addition to comparing the version identifier, the reader also compares E and the pattern version item by item to prevent accidental digest reuse under different encoding rules.

[0107] Evidence quality is registered separately, but includes at least four components: source authenticity, temporal integrity, field integrity, and cross-consistency. Steps using a particular field declare the required components and minimum levels; low-quality flags for unused fields do not block irrelevant branches. When performing partial updates to asset lifecycle events, only outputs dependent on the changed components are recalculated; other confirmed outputs retain the original evidence references without copying the original content.

[0108] If a gap exists in the current data collection, the system first determines whether the gap is relevant based on the read sets of subsequent actions. If the missing field is not in the read set, processing can continue, but the gap flag will be retained in the output. If the field is involved in the release judgment for asset offline, component replacement, task migration, or decommissioning registration, the branch will be stopped and a supplementary data collection request will be generated. The supplementary data collection result must include the original asset root identity, validity period, registration version, and new source summary. After confirmation, only branches waiting for that field will be activated to avoid unconditionally rerunning the entire process.

[0109] A transaction catalog is established around asset lifecycle events, with separate numbering for preparation, external calls, observation confirmations, and compensation records. A preparation entry must at least store the calling interface, target object, expected write set, pre-execution summary, request idempotent key, and timeout. Confirmation entries store a receipt summary and independent observations. When a receipt is lost but observations show the target state has changed, the catalog confirms it as executed and continues the confirmation phase, rather than calling the interface again. If the observation is also uncertain, the commit remains unclear, and the recovery process handles it, without directly re-issuing asset offline, component replacement, task migration, or retirement registration.

[0110] Queues are divided according to business objects. Messages from the same source do not automatically enter the same shard. Only one writer is allowed at any given time for the same asset root identity, validity time, and registration version. Different objects can write concurrently. When a queue reaches its capacity limit, the entry point prioritizes retaining confirmation messages, rollback messages, and evidence re-collection results. Ordinary duplicate samples can be merged into a single record with a count. Merging only applies to samples that have not yet been consumed and have the same pattern version, and cannot cross the time boundaries of the valid interval of life events, the fact registration interval, or the maintenance window.

[0111] Abnormal path verification should at least include message duplication, message out-of-order delivery, processor restart after preparation, interface execution timeout, mode version switching, and one source distortion. Before each injection, save an input snapshot; after injection, check for erroneous commits, unfounded state transitions, or unassociated isolated records. For undoing unclosed offline or migration actions, while maintaining the old component's root identity and operational exposure so it's not inherited by the new component, the process should be interrupted again during compensation to verify that the recovery procedure can continue from the confirmation point of the compensation action itself, without re-executing the already completed reverse action.

[0112] The verification of rule boundaries uses three sets of objects: a baseline object with all evidence complete, an object located exactly at the rule boundary, and an object missing only one key field. Boundary values ​​are taken as the lower bound, upper bound, and adjacent representable values ​​of the allowed values; for count or fixed-point fields, overflow, wraparound, and reset are also tested. The results cannot only compare the final success or failure, but also compare the state of the asset life event, the reason for rejection, and whether the evidence cited is consistent with the expectations item by item.

[0113] For interfaces requiring authorization, the least privilege credential is used. The credential itself is not written into the asset lifecycle event; only an irreversible credential reference summary, permission scope, and audit number are recorded. When the executing entity is not authorized to complete asset decommissioning, component replacement, task migration, or decommissioning registration, the process terminates at the preparation stage, preventing permission errors from being misjudged as target object failures. Audit records and business records are associated with the same object key and processing period, but access is controlled separately. When exporting implementation data, a stable anonymous identifier replaces the real asset identifier.

[0114] Once the number of versions of an asset lifecycle event reaches the retention limit, consecutive versions that have been closed and exceeded the audit period can be compressed into checkpoints. Checkpoints retain the beginning and end states, a summary chain for each state transition, parameter versions, and the location of external evidence; the original large fields are transferred to content-addressable storage. Records still in a state of unclear submission, pending supplementary documentation, or quarantine must not be compressed; versions with asset root identity, validity period, and registered version references must not be deleted until the last reference expires.

[0115] The complete processing procedure in this embodiment is as follows: The entry components in the asset discovery agent, life event storage, health calculator, impact simulator, and maintenance execution interface receive objects and establish an input snapshot indexed by asset root identity, validity time, and registered version; the rule executor loads the read-only parameter snapshot and generates candidate results; the status controller selects confirmation, re-collection, or isolation based on the current status and submission threshold; the confirmation result, along with evidence citations, is published to the next step. If a version change occurs midway, the current candidate is retained as the replaced record, and the new version continues from the first affected step without overwriting the old conclusion.

[0116] Implementation does not require specific branding of the message bus, relational database, or processor. As long as the alternative implementation maintains a stable association between asset root identity, validity period, and registered version; valid intervals for life events; time boundaries for fact registration intervals and maintenance windows; atomic visibility of state transitions; and the ability to undo unclosed offline or migration actions, while preserving the old component's root identity and operational exposure recovery order that is not inherited by the new component, it can be implemented using shared memory, persistent queues, on-chip directories, or distributed logs. If the alternative implementation eliminates any of the above boundaries, equivalent consistency checks and evidence preservation mechanisms must be added; equivalence cannot be based solely on identical interface names.

[0117] Example 3 illustrates the input, state changes, and anomaly handling by taking a server that has had its storage units replaced twice and its rack relocated, resulting in an increased error rate. The example requires attributing the exposure to the actual components and assessing the impact of immediate replacement on redundancy and business migration.

[0118] Take, for example, the increase in error correction events on a training server containing two accelerator cards and a local solid-state drive.

[0119] Step 1: Read the root certificate of the whole machine, the unit identifiers of the two accelerator cards and the solid-state drive, and associate them with the historical location aliases.

[0120] Step 2, replaying the life event revealed that one of the accelerator cards had been migrated from another server, and its exposure was not cleared upon migration.

[0121] Step 3: Based on the cumulative temperature dwell time, power cycle, and error correction increment of each unit, the data quality verification and identification are reset once.

[0122] Step 4, health calculation shows that the error correction contribution is concentrated on the inbound accelerator card, and the interval is widened due to a period of missing temperature measurements.

[0123] Step 5: Simulate task migration and dual-card redundancy after the card is taken offline, and verify the target node capacity and spare parts interface contract.

[0124] Step 6: After the work order is executed, register the old card's exit and the new card's identity, run the minimum calculation probe, and calibrate the model based on the actual fault inspection results.

[0125] If there is an inconsistency between the identity, counter, or execution receipt, the maintenance status will not be directly advanced; instead, it will be handled according to the following boundary rules.

[0126] (1) When there is a conflict in the source of hardware identity, the history should not be automatically merged, and the upper bound of candidate exposure should be calculated separately.

[0127] (2) When the cumulative counter cannot be distinguished by wrapping or resetting, the interval increment is retained and the health confidence is reduced.

[0128] (3) If the topology or task status changes after the simulation, the maintenance window is invalidated and the simulation is repeated.

[0129] (4) No automatic replacement work order will be generated if the spare parts interface contract does not cover the original unit.

[0130] (1) Hardware root identity can be obtained using a certificate, an immutable serial number, a trusted platform module certificate, or a combination thereof.

[0131] (2) The health model can be a segmented physical model, a survival model, or a statistical model that can output contribution and interval.

[0132] (3) The impact simulation can be performed in the resource graph, digital twin, or orchestrator read-only shadow queue.

[0133] A corresponding IT asset lifecycle tracking and maintenance decision-making integrated management system can be implemented in a modular manner.

[0134] 110 is the hardware root identity manager, used for cross-verification of the stable identity of the entire machine and its components.

[0135] 120 is the life event ledger, used to add and save procurement, deployment, relocation, failure, and replacement events.

[0136] 130 is the runtime exposure accumulator, used to accumulate load and environmental exposure over the effective range of a component.

[0137] 210 is a health interval evaluator used to output versioned health status with confidence intervals.

[0138] The 220 is a maintenance impact simulator used to assess redundancy, capacity, task allocation, and spare parts contracts.

[0139] 310 is the gating and work order interface, used to issue traceable maintenance actions after the blocking item is closed.

[0140] 320 is the result confirmation and model calibrator, used to confirm the replacement results and generate versioned calibration samples.

[0141] The identity and event modules constitute an uncoverable digital thread, and the exposure module accumulates technical quantities according to replaceable units and inputs them into health calculations; health contributions and topology simulation jointly constrain maintenance work orders, and execution feedback generates new identities, functions, and calibration events.

[0142] The deployment and interface implementation of this embodiment are as follows.

[0143] The event store is partitioned by hardware root identifier and event sequence number. The source adapter can only append facts and cannot delete history.

[0144] Health models, equipment specifications, and spare parts capability signatures all include version information, and work orders save their reference summaries.

[0145] The study compares the coverage of the ledger with that of fixed-term maintenance in scenarios such as cross-machine migration of structural components, identity conflicts, counter wrap-around, sensor failure, insufficient redundancy, and incompatible spare parts interfaces.

[0146] (1) Identity continuity: Whether the historical exposure of a component is continuous after it is moved across the entire machine;

[0147] (2) Event replayability: Whether the asset status can be restored at the specified effective and registration time;

[0148] (3) Exposure of cumulative error: deviation of cumulative amount after counter rewinding and reset;

[0149] (4) Maintenance Execution Rate: Whether the recommended actions have been verified through capacity, redundancy, and spare parts contracts;

[0150] (5) Model interpretability: Whether the risk level can be traced back to the exposure contribution and data quality.

[0151] This embodiment is implemented collaboratively through an asset discovery agent, life event storage, a health calculator, an impact simulator, and a maintenance execution interface. The control logic indexes asset life events according to asset root identity, validity time, and registered version, and writes the life event validity period, fact registration period, maintenance window, parameter version, and processing result into the same record chain. Software instructions are stored in a non-transitory computer-readable storage medium; processing requiring programmable logic can be executed by an FPGA, programmable switching device, or embedded controller. Data is transferred between hardware and software through an interface with version and integrity verification.

[0152] Figure 2 In this system, the hardware root identity manager 110, the life event ledger 120, and the operation exposure accumulator 130 constitute the evidence layer; the health interval evaluator 210 and the maintenance impact simulator 220 constitute the decision layer; the execution gating and work order interface 310 connects to the maintenance execution end, and the result confirmation and model calibrator 320 sends the confirmed sample back to the model version library.

[0153] The asset root identity module 110 is used to collect the unique hardware identifier, proof information and physical location of the whole machine and replaceable units to establish an asset root identity with a trust level.

[0154] The life event storage module 120 is used to convert the states of entry, installation, activation, migration, maintenance, replacement and decommissioning into asset life events with before and after state summaries and dual time.

[0155] The exposure processing module 130 is used to segment and accumulate temperature dwell, power cycle, media writing, error correction and fault retry increments according to the replaceable unit identity.

[0156] The health interval calculation module 210 is used to calculate the health status interval based on the equipment specification interval, similar stable distribution and operation exposure, and write the model version and contribution into the life event.

[0157] The maintenance impact simulation module 220 is used to simulate resource offline, redundancy switching, task migration and spare parts compatibility for candidate maintenance actions within the current topology period, and obtain the executable window and risk boundary.

[0158] The maintenance execution and calibration module 320 is used to generate maintenance work orders that reference asset life events, health contributions, and impact simulation results. After execution, it collects new identity and function probes and calibrates the health model.

[0159] The electronic device includes a processor, memory, a communication interface, and a bus. The memory stores the program that implements the above steps, as well as asset lifecycle events. When the processor executes the program, it first reads the valid version according to the asset root identity, validity period, and registered version, and then completes the calculation, verification, and status submission based on the count wraparound boundary, health range, maintenance risk limit, and spare parts contract scope. The communication interface is used to connect to the execution components described in the embodiment; late or duplicate messages received by the interface are still processed according to the object period and idempotent key.

[0160] Asset discovery protocols, health model formats, or maintenance execution interfaces can be adjusted according to equipment category, but the relationship between independent root identity, non-coverable events, interval health results, and closed-loop verification before and after execution should remain unchanged.

Claims

1. An integrated management system for tracking and maintaining IT assets throughout their entire lifecycle, characterized in that, The system is configured to execute: Step S101, confirm the identity of the whole machine and components from at least two independent sources, and register the valid range for variable aliases; Step S102, add procurement, deployment, relocation, failure and replacement events according to the hardware root identity, and form a new registration version for late events; Step S103, after verifying sensors and counters, accumulate operation and environmental exposure according to the component's valid range; Step S104, output risk level and confidence interval based on exposure, failure and measurement evidence; Step S105, simulate redundant paths, remaining capacity, task shadow placement and spare parts capability; Step S106, after the blocking item is closed, issue maintenance actions bound to the asset identity and the planned window; Step S107, confirm the old unit exit, the new unit identity, interface visibility and minimum function, and generate a versioned calibration sample based on the actual failure mode.

2. The method as described in claim 1, characterized in that, The asset root identity is cross-confirmed by at least two of the following: security chip proof, immutable serial number, device-side firmware unique identifier, and out-of-band controller proof. The at least two proofs are obtained through different acquisition paths and include at least one verifiable hardware proof or immutable serial number. Bus location, management address, and physical location are only used as evidence with valid ranges and do not participate in the counting of two independent sources. When sources conflict, candidate identities are established and automatic maintenance control is suspended until new evidence closes the candidate identities.

3. The method as described in claim 1, characterized in that, For non-volatile storage components, the cumulative data write volume, cumulative duration above alarm temperature, power cycle count, number of media or data integrity errors, and error log entries are read from their controller health information; for an n-bit cumulative counter, the operational exposure increment where the current value is less than the previous value and the reset period remains unchanged is calculated as current+2^n-previous, only when it can be determined from the maximum growth rate of the counter and the sampling interval that at most one wrap-around occurs between adjacent samples; when the controller reset record is established, a new counting period is established and the current value is used as the new baseline; It cannot distinguish between rewinding and reset, saving the operational exposure increment as an interval from zero to current+2^n-previous. It cannot guarantee that the corresponding source quality will be set to unknown at most one rewind. Neither of these will output a definite maintenance instruction.

4. The method as described in claim 1, characterized in that, For the i-th type of operational exposure E_i in the effective operational exposure index set I, calculate z_i=clip((E_i-L_i) / (U_i-L_i),0,1) based on the lower specification limit L_i and upper specification limit U_i of the target equipment category, where clip(x,0,1)=min(1,max(0,x)); calculate the basic risk amount r=1-∏_{i∈I}(1-w_iz_i) and the uncertainty δ=min(1,Σ_{i∈I}w_i(1-q_i)), and output the health status interval H=[max(0,r-δ),min(1,r+δ)]; where w_i≥0 and Σ_{i∈I}w_i=1, q_i∈[0,1], and L_i, U_i, w_i and threshold are fixed with the model version; no definite maintenance instructions are output when the specification boundary is missing, U_i is not greater than L_i, the key source is unknown or I is empty.

5. The method as described in claim 1, characterized in that, When simulating candidate maintenance actions, a maintenance impact subgraph is constructed. The maintenance impact subgraph includes the target device, the tasks running on it, redundant devices, data replicas, interconnection paths, and candidate spare parts. After deleting the target device and its associated edges from the subgraph, the available nodes for the task, the lower bound of the remaining capacity, the effective redundancy in different fault domains, the rebuild bandwidth and the upper bound of the completion time, as well as the bus interface, capacity, and minimum firmware capability of the spare parts are verified in sequence. Any verification failure forms a blocking item.

6. The method as described in claim 1, characterized in that, The execution preparation record includes the asset root identity, current life event version, current topology period, expected write set, maintenance impact summary, spare parts identity requirements, idempotent action number, and compensation entry. Confirmation and submission are only confirmed when the identity and function observations collected independently are consistent with the execution preparation record. If the interface times out and the external status is unknown, the actual status of the device is read first, and actions with side effects are not repeated.

7. The method as described in claim 1, characterized in that, Model calibration only uses life events that simultaneously satisfy the following conditions: physical inspection provides a fault mode, functional probes are closed after maintenance, and maintenance actions correspond to a single fault unit. For the same equipment category and operational exposure item, under the constraints of w_i≥0 and Σ_iw_i=1, at least one of Li, U_i, or w_i is updated according to the exposure distribution of confirmed samples. The health interval coverage threshold and automatic action false trigger threshold are checked on time-isolated verification samples. A new model version with an effective time is generated only when both pass. Life events such as label conflicts, unconfirmed faults, or multiple simultaneous unit replacements that cannot be attributed do not update Li, U_i, or w_i; only the corresponding q_i is reduced or the uncertainty penalty for that source is increased. The new version does not cover historical models and historical health state intervals.

8. A full lifecycle tracking and maintenance control system for IT assets, characterized in that, The system includes an asset discovery agent, a root identity resolver, a dual-time life event memory, a hardware counter processor, a health interval calculator, a maintenance candidate generator, a maintenance impact simulator, a maintenance execution controller, and a model calibrator. Each component is configured to perform the method described in any one of claims 1 to 7. The maintenance candidate generator distinguishes between automatic maintenance candidates and inspection candidates based on health status intervals and versioning thresholds. The maintenance execution controller only opens the automatic execution interface when the impact simulation of the automatic maintenance candidate does not output blocking items and identity and function probes can be collected. The model calibrator only uses confirmed and attributable samples to generate new model versions.

9. An IT asset maintenance control device, characterized in that, It includes a processor, a memory, a device-side management interface, a resource orchestration interface, and a maintenance execution interface. The memory stores asset life events, operational exposure count periods, model versions, and maintenance impact subgraphs. When the processor executes program instructions, it implements the method described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing program instructions thereon, characterized in that, When the program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images