Vehicle platform-oriented equipment phm operation software integrated management system

Abstract

This invention discloses an integrated management system for equipment health management (PHM) operation software for vehicle platforms, specifically relating to the field of vehicle health management and collaborative control of operation software. It addresses the problem that existing health conclusions are difficult to accurately apply to the current operating state after changes in the target subsystem software state. By collecting the target software cluster version identifier, parameter set summary, health anchor value, fault event count, and operating condition bucket label, a current software state fingerprint is generated. A verified PHM reference template corresponding to the current software state is retrieved. Based on freezing the health conclusions prior to the change, continuous verification is performed on the health anchor value and fault event count. The PHM configuration is switched or anomaly handling instructions are output based on continuous consistency counts or continuous mismatch counts, thereby completing the continuity maintenance of PHM conclusions during vehicle platform state change phases.

Description

Technical Field

[0001] This invention relates to the field of vehicle health management and collaborative control of operating software, and more specifically, to an integrated management system for equipment PHM operating software for vehicle platforms. Background Technology

[0002] With the increasing electrification, connectivity, and software-defined nature of vehicle platforms, the post-delivery operation phase of vehicles is no longer under fixed control strategies and parameter boundaries. Software version updates, parameter calibration adjustments, and functional configuration changes for powertrain, chassis, body, and special equipment subsystems have become commonplace. Existing vehicle platforms are typically equipped with diagnostic, remote maintenance, and health monitoring capabilities, and based on monitoring parameters, threshold rules, fault event statistics methods, and health assessment models formed under predetermined software conditions, they determine the operational status of target subsystems.

[0003] However, in practical applications, once the software state of the target subsystem changes, the control logic, signal processing paths, parameter boundaries, fault triggering conditions, and representation distribution under the same operating condition may all change accordingly, thereby altering the data premises upon which the original health conclusions depend. Such changes often occur during the operational phase following remote upgrades, maintenance re-flashing, parameter recalibration, function switch switching, and switching between different configuration versions. Especially within the initial operating window after a software change, the vehicle may also experience factors such as learning value reconstruction, diagnostic count continuation, operating condition switching, and inconsistencies in the states of multiple control units, leading to periodic drifts in health anchor values, fault event frequency, and representation patterns. If health conclusions formed under the pre-change software state are directly applied to the post-change operating state, or if the post-change conclusions are adopted immediately without sufficient operational verification, the representation migration caused by the software state change may be confused with actual hardware degradation at the judgment level, resulting in conclusion mismatches in remote monitoring, fault identification, maintenance judgment, and operation and maintenance management of the vehicle platform. This problem is particularly prominent in scenarios involving fleet operations, high-frequency operations, and parallel maintenance of multiple versions. This is because changes in software status do not directly correspond to changes in hardware health, but they can alter the data boundaries, statistical characteristics, and event interpretation relationships upon which health assessments are based, leading to insufficient continuity and applicability of existing health judgments during the operational phase.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To address the problem that existing health conclusions are difficult to accurately apply to the current operating state after changes in the target subsystem software state, this invention provides an integrated management system for equipment PHM (Prognostics and Health Management) operating software for vehicle platforms. This system generates a current software state fingerprint by collecting the target software cluster version identifier, parameter set summary, health anchor value, fault event count, and operating condition bucket label. It then retrieves a verified PHM reference template corresponding to the current software state. Based on freezing the health conclusions prior to the change, it performs continuous verification of the health anchor value and fault event count, and switches the PHM configuration or outputs anomaly handling instructions based on continuous consistency counts or continuous mismatch counts, thereby completing the continuity maintenance of PHM conclusions during vehicle platform state change phases.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The state modeling module collects the target software cluster version identifier, parameter set summary, health anchor value, fault event count and condition bucket label. Based on the target software cluster version identifier, parameter set summary and condition bucket label, it generates the current software state fingerprint and enters the state change phase when the target software cluster version identifier or parameter set summary changes. The template freeze module retrieves the PHM reference template based on the current software status fingerprint and working condition bucket label, and obtains the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier, and freezes the health conclusions before the change. The continuous verification module compares the health anchor value with the health anchor value tolerance range and the failure event count with the failure event tolerance mode, generates a consistency flag or mismatch flag, and updates the continuous consistency count and continuous mismatch count. The decision-making and handling module unfreezes and switches the PHM configuration corresponding to the PHM configuration identifier when the continuous consistency count reaches the first threshold, and outputs an exception handling instruction when the continuous mismatch count reaches the second threshold.

[0007] Furthermore, generating the current software state fingerprint involves extracting parameter fields acting on the target subsystem according to a preset field order, performing unified encoding on each parameter field to form a parameter set summary, and writing the target software cluster version identifier, parameter set summary, and operating condition bucket label into the basic state string in a fixed order, and then generating the current software state fingerprint from the basic state string.

[0008] Furthermore, the process enters the state change phase, which involves comparing the target software cluster version identifier and parameter set summary of the current sampling period with the corresponding content of the previous sampling period. If any comparison result is inconsistent, a state change flag is written.

[0009] Furthermore, the corresponding PHM reference template is retrieved, including in the pre-established reference template library, using the current software status fingerprint as the main search condition, the working condition bucket label as the working condition constraint condition, and the template validity status and template effective time as filtering conditions, to determine the unique verified PHM reference template corresponding to the current unified sampling time.

[0010] Furthermore, the determination of the unique verified PHM reference template includes comparing the candidate templates according to the order of their verification and entry into the database when there is more than one candidate template that meets the main search conditions and operating condition constraints. The candidate template that was most recently verified and entered into the database and whose content is complete is selected as the verified PHM reference template, and the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier are extracted.

[0011] Furthermore, freezing the health conclusions before the change includes reading the health conclusion of the most recent valid output before entering the state change phase from the health conclusion cache at the start of the state change phase, and writing it into the frozen output channel to form the frozen output health conclusion.

[0012] Furthermore, generating consistency or mismatch flags includes first determining whether the working condition bucket label of the current sampling point is consistent with the working condition bucket label corresponding to the verified PHM reference template within the preset verification window. Only when they are consistent, the health anchor value and the health anchor value tolerance range, and the fault event count and the fault event tolerance mode are compared respectively. A consistency flag is generated when both comparisons are true. Otherwise, a mismatch flag is generated.

[0013] Furthermore, the fault event tolerance mode includes a permissible count relationship and a permissible increment relationship. Comparing the fault event count with the fault event tolerance mode includes determining whether the fault event count at the current sampling point satisfies the permissible count relationship and whether the change in the fault event count at the current sampling point relative to the previous valid comparison sampling point satisfies the permissible increment relationship. The comparison is considered valid when both conditions are met.

[0014] Furthermore, both the first threshold and the second threshold are determined based on template verification samples corresponding to the current software state fingerprint and working condition bucket label. The first threshold is determined based on the false release ratio and release delay, and the second threshold is determined based on the false handling ratio and handling delay. They are also associated with the PHM configuration identifier when the verified PHM reference template is entered into the database.

[0015] Furthermore, the software outputs relevant exception handling instructions, including classifying exception categories based on template missing markers, comparison results of health anchor values ​​and health anchor value tolerance ranges, and comparison results of fault event counts and fault event tolerance modes, and outputting a set of exception handling instructions corresponding to the exception categories according to preset mapping relationships.

[0016] Compared with the prior art, the present invention has the following beneficial effects: This invention does not merely perform general monitoring of the vehicle's software status after an update, but rather establishes a progressively interconnected processing chain around the trigger point of software status change, from status identification, template retrieval, conclusion freezing, continuous verification, to action decision-making. Specifically, the current software status is first determined based on the target software cluster version identifier, parameter set summary, and operating condition bucket label. Then, a verified PHM reference template corresponding to the current software status is invoked. Based on this, the pre-change health conclusion is temporarily maintained, and health anchor values ​​and fault event counts are continuously compared. Only when the continuous verification results meet predetermined conditions is the freeze lifted and the system switches to the new PHM configuration. Thus, a clear one-to-one correspondence is established between software version changes, parameter changes, and health assessments, ensuring that health conclusion updates are based on operational verification, rather than on single sampling or simple version switching.

[0017] Based on the above processing method, this invention can distinguish short-term representation drift caused by software state changes from actual health anomalies in the target subsystem. During state change phases, it maintains continuous and stable external health conclusions while outputting corresponding configuration switching or anomaly handling actions based on continuous consistency counts and continuous mismatch counts. This reduces false alarms, incorrect component replacements, and lost work orders caused by software changes, and also provides clear boundaries and timing for PHM configuration activation. This facilitates maintaining consistency between health management results and actual operating status during vehicle platform software updates, parameter recalibration, and function configuration switching scenarios, thereby improving the accuracy of vehicle maintenance judgments, the controllability of handling rhythms, and the targeted nature of subsequent maintenance links. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of the equipment PHM operation software integrated management system for vehicle platforms according to the present invention. Detailed Implementation

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

[0020] Please see Figure 1 This invention provides an integrated management system for equipment PHM (Professional Health Management) operation software for vehicle platforms, comprising: The state modeling module collects the target software cluster version identifier, parameter set summary, health anchor value, fault event count and condition bucket label. Based on the target software cluster version identifier, parameter set summary and condition bucket label, it generates the current software state fingerprint and enters the state change phase when the target software cluster version identifier or parameter set summary changes. The template freeze module retrieves the PHM reference template based on the current software status fingerprint and working condition bucket label, and obtains the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier, and freezes the health conclusions before the change. The continuous verification module compares the health anchor value with the health anchor value tolerance range and the failure event count with the failure event tolerance mode, generates a consistency flag or mismatch flag, and updates the continuous consistency count and continuous mismatch count. The decision-making and handling module unfreezes and switches the PHM configuration corresponding to the PHM configuration identifier when the continuous consistency count reaches the first threshold, and outputs an exception handling instruction when the continuous mismatch count reaches the second threshold.

[0021] This invention addresses the core issue that existing health conclusions may become inapplicable after software version updates, parameter recalibration, or function configuration switching on a vehicle platform due to changes in software state. The overall logic involves first identifying the current software and configuration state of the target subsystem, then mapping this state to a verified health reference boundary. Subsequently, while freezing the health conclusions from before the change, continuous verification of health anchor values ​​and fault event counts is performed. Finally, based on the continuous verification results, a decision is made whether to unfreeze and switch to the health management configuration corresponding to the current state, or to output software-related anomaly handling instructions. The key is not in performing upgrade management, fault diagnosis, or health monitoring in isolation, but in organizing software state identification, template retrieval, operational verification, and action decision-making into a closed-loop chain process. This ensures that software changes are not directly misinterpreted as hardware degradation, and that health conclusions are not hastily switched without verification. Through this process, the present invention can maintain continuous and stable external health conclusions during the state change phase. At the same time, it distinguishes between short-term characterization drift and persistent deviation through continuous verification. This not only improves the accuracy of health assessment after software changes, but also reduces false alarms, incorrect parts replacements, and work orders. This is beneficial for improving vehicle operation and maintenance efficiency, reducing after-sales costs, and enhancing the consistency between health management results and the current operating software state.

[0022] After a software version update, parameter recalibration, or function configuration switch occurs on the vehicle platform, the operating boundary of the target subsystem is no longer equivalent to the state before the change. If the original health judgment criteria are still used directly, the software state change and the actual health change are easily mixed at the input level. Therefore, the state modeling module needs to first incorporate the target software cluster version identifier, parameter set summary, health anchor value, fault event count, and operating condition bucket label into a unified sampling caliber, and form a current software state fingerprint that can characterize the current software and configuration state, so as to provide a unified, stable and comparable input basis for the state change phase.

[0023] S101: Establishment of a unified sampling time and locking of sampling objects.

[0024] After the target subsystem enters a software version update, parameter recalibration, or function configuration switch, the template freezing module needs to call the current software state fingerprint and condition bucket label to retrieve the verified PHM reference template. The continuous verification module needs to call the health anchor value, fault event count, and condition bucket label to perform continuous consistency verification. Therefore, the state modeling module first establishes a unified sampling time and uses the unified sampling time as the common time reference for the target software cluster version identifier, parameter set summary, health anchor value, fault event count, and condition bucket label.

[0025] The unified sampling time is established by pre-defining a fixed sampling period in the target subsystem implementation configuration, and triggering a complete acquisition at the fixed sampling period. The time corresponding to a single complete acquisition is the unified sampling time. Starting from the unified sampling time, the target software cluster version identifier is read by the vehicle diagnostic interface, the parameter set summary is generated by the parameter management interface based on the fixed field directory, the health anchor value is obtained from the preset health channel, the fault event count is formed by the statistics of diagnostic event activation records, and the operating condition bucket label is mapped from the operating condition classification table. The aforementioned five types of data are all recorded at the same unified sampling time. Subsequent steps call the aforementioned five types of data one-to-one based on this unified sampling time, so that the template retrieval input and the consistency verification input are under the same temporal semantics.

[0026] The specific value of the fixed sampling period is not limited here. Its determination logic can be to use the common multiple of the target subsystem's main loop cycle and the diagnostic event refresh cycle as the candidate cycle, and then select the cycle that can cover the health anchor value refresh timer and does not lose the fault event activation record from the candidate cycle as the fixed sampling period.

[0027] S102: Reading the target software cluster version identifier and generating a parameter set summary.

[0028] Upon arrival of the unified sampling time, the target software cluster version identifier is read first. The target software cluster version identifier is used to characterize the actual software cluster version status of the target subsystem at the current unified sampling time. The reading result directly enters the subsequent process of constructing the current software state fingerprint.

[0029] After reading the target software cluster version identifier, a parameter set summary is generated according to the pre-defined fixed field directory of the target subsystem. The fixed field directory is not a temporarily selected set of parameters, but a parameter directory pre-defined in the implementation configuration. Each field in the directory corresponds to a unique field name, a unique data type, a unique unit conversion rule, a unique quantization precision rule, and a unique invalid identifier writing rule.

[0030] The parameter set summary generation process includes reading the original parameter values ​​sequentially according to a fixed field directory, performing normalization on each original parameter value, and then concatenating the normalization results into a parameter description string with a fixed order according to the fixed field directory. The normalization process involves writing Boolean parameter values ​​as fixed binary results, enumeration parameter values ​​as preset enumeration codes, integer and fixed-point parameter values ​​first converting them to a unified numerical domain according to the unit conversion and scaling rules recorded in the fixed field directory, and then writing the results according to the quantization precision rules. Floating-point parameter values ​​first undergo unit conversion, and then quantization is performed according to the quantization precision rules. Parameter values ​​that fail to read, are missing, or exceed the preset representation range are written with the corresponding field's preset invalid identifier. Subsequently, the field name encoding, data type encoding, unit and scaling rule encoding, and normalization results are continuously written in the fixed field directory order to form the parameter set summary.

[0031] The essence of a parameter set summary is not a simple concatenation of multiple original parameter values, but an ordered encoded expression of the parameter configuration state of the target subsystem. The encoding order, data type, unit, and invalid value are all fixed in advance during the implementation configuration. Therefore, the same parameter configuration state will form the same parameter set summary at different unified sampling times, and different parameter configuration states will form different parameter set summaries.

[0032] S103: Acquisition of health anchor values ​​and statistics of failure event counts.

[0033] After obtaining the target software cluster version identifier and parameter set summary, the health anchor value is read and the failure event count is recorded. The health anchor value is a unique health measure pre-specified in the implementation configuration of the target subsystem, used as a subjective measurement for continuous consistency verification in subsequent continuous verification modules. The source of the health anchor value is fixed to a single sensor point or a single output calculation caliber, and multiple health indicators are not superimposed, sorted, or filtered in parallel. If the health anchor value comes from a sensor point, the current measurement value of the sensor point is read at the unified sampling time, and written into the health anchor value according to the unit caliber preset in the implementation configuration; if the health anchor value comes from a single output calculation caliber, the input quantity required for that calculation caliber is obtained at the unified sampling time, and the health anchor value is formed according to the calculation order fixed in the implementation configuration.

[0034] The health anchor value is limited to a single health measure because the subsequent continuous verification module requires a single, stable, and repeatable observation to verify the continuous consistency of the verified PHM reference template. Introducing multiple health measures at this stage would change the underlying object of the subsequent verification logic. The statistical method for counting fault events is as follows: using the current unified sampling time as the statistical endpoint, a preset statistical time window is traced back. Within this preset statistical time window, all fault event activation records corresponding to the target fault event set are retrieved, and the count is completed according to the number of activations.

[0035] The fault event count does not accumulate the instantaneous reporting status point by point, but counts the activation behavior of the fault event. The same fault is only counted once during the continuous activation period, and is counted again when the fault exits the activation state and re-enters the activation state.

[0036] The specific duration of the preset statistical window is not specified here. Its determination logic can be based on the average re-trigger interval of the target fault event set in the historical operation data as a basic reference. Then, the target subsystem diagnostic refresh cycle selects a time window that can fully cover at least one fault activation and retention process as the preset statistical window, so that the fault event count can reflect the triggering frequency of the target fault event during the state change phase, rather than the code retention duration.

[0037] S104: Generation of working condition bucket labels and determination of working condition classification boundaries.

[0038] After obtaining the health anchor value and fault event count, operating condition bucket labels are generated. These labels are used by the template freezing module to perform operating condition constraint retrieval on the verified PHM reference template, and also by the continuous verification module to confirm whether the operating status at the current uniform sampling time falls within the applicable operating condition range of the corresponding reference template. The generation of operating condition bucket labels is not based on manual input, but rather on the discrete classification of the current operating status according to the pre-set operating condition classification table of the target subsystem.

[0039] The operating condition classification table is pre-established during implementation configuration. Each operating condition category corresponds to a unique operating condition bucket label, and operating condition categories are mutually exclusive. The logic for establishing the operating condition classification table can use operating conditions that are significantly related to changes in the health anchor value in the historical operating data of the target subsystem as the classification basis. First, in the implementation configuration phase, basic operating quantities representing the load, operating mode, or energy transfer status of the target subsystem are selected. Then, the basic operating quantities are segmented according to the stable range of the health anchor value and the distribution of fault event activation. The segmentation results correspond to operating condition categories, and the operating condition categories are then mapped to operating condition bucket labels. Once the operating condition bucket labels are formed, their scope remains unchanged under the same implementation configuration of the target subsystem. The state modeling module only outputs the operating condition bucket labels and no longer outputs the operating condition classification table itself. This is because subsequent steps only need to call the operating condition bucket labels to complete template retrieval and applicable operating condition confirmation, without needing to repeatedly perform operating condition segmentation modeling. Thus, the operating condition bucket labels become the unified operating condition description object connecting the state modeling module, template freezing module, and continuous verification module.

[0040] S105: Generation of the current software state fingerprint.

[0041] At the unified sampling time, the target software cluster version identifier, parameter set summary, and operating condition bucket label have all been obtained, and then the current software state fingerprint is generated. The current software state fingerprint is used by the template freezing module as the main retrieval basis for the verified PHM reference template. Therefore, its generation process needs to reflect the software and configuration status, without mixing in the operational observation status.

[0042] The specific processing method is as follows: First, the target software cluster version identifier, parameter set summary, and condition bucket label are written into a basic state string in a predefined order. The writing order is fixed: first the target software cluster version identifier, then the parameter set summary, and finally the condition bucket label. This "writing" is not a simple concatenation; rather, it involves organizing the aforementioned three objects into a complete state description string according to the predefined field boundaries, field lengths, or separation rules in the implementation configuration. After the basic state string is formed, a fixed hash mapping is performed on it, outputting a fixed-length encoded result, which is the current software state fingerprint. The fixed hash mapping remains unchanged throughout the implementation process; therefore, the same basic state string will produce the same current software state fingerprint, and different basic state strings will produce different current software state fingerprints. Health anchor values ​​and fault event counts are not included in the current software state fingerprint because they are used by subsequent continuous verification modules to check whether the verified PHM reference template matches the current operating state. The target software cluster version identifier, parameter set summary, and operating condition bucket label are used to characterize the current software and configuration state of the target subsystem. The former belongs to the operational observation results, while the latter belongs to the template retrieval state description. They have different processing functions in this invention, so they enter different processing links.

[0043] S106: Determining the state change flag and fixing the output relationship between steps.

[0044] After the current software state fingerprint is generated, the state change flag is determined. The state change flag indicates whether the current unified sampling time has entered the state change phase. Both the template freezing module and the continuous verification module use the state change flag as a trigger condition. The determination of the state change flag only includes two items: the target software cluster version identifier and the parameter set summary. Specifically, the target software cluster version identifier at the current unified sampling time is compared with that at the previous unified sampling time, and the parameter set summary at the current unified sampling time is also compared with that at the previous unified sampling time. If either of the two comparisons is inconsistent, the state change flag is set to indicate that the state change phase has begun; only when both comparisons are consistent is the state change flag set to indicate that the state change phase has not begun. The condition bucket label, health anchor value, and fault event count are not included in the determination of the state change flag because the determination of the state change flag is based on the fact that the software version has changed and the parameter configuration has changed, while the condition bucket label, health anchor value, and fault event count are inputs used for template constraints and continuous verification after the state change. At this point, the output relationships of the state modeling module are fixed as follows: the current software state fingerprint and condition bucket label are used by the template freezing module; the health anchor value, fault event count, and condition bucket label are used by the continuous verification module; and the state change flag is used by both the template freezing module and the continuous verification module. Subsequent steps will not rename the aforementioned output objects, thus ensuring that the state modeling module, template freezing module, continuous verification module, and decision-making module operate within the same terminology system.

[0045] S107: Summary of the results of this step.

[0046] After processing by the state modeling module, the target software cluster version identifier, parameter set summary, health anchor value, fault event count, and condition bucket label at the unified sampling time form a minimal input set with consistent caliber, time consistency, and clear purpose. The target software cluster version identifier, parameter set summary, and condition bucket label are written in a fixed order and mapped using a fixed hash to generate the current software state fingerprint. The health anchor value and fault event count are retained as observation inputs for subsequent continuous consistency verification, while the state change flag provides a clear determination of whether the state change phase has begun. Therefore, the template freezing module can directly retrieve the verified PHM reference template using the current software state fingerprint and condition bucket label, and the continuous verification module can directly perform continuous consistency verification using the health anchor value, fault event count, and condition bucket label. The data continuity and terminology mapping relationships between steps are thus fixed.

[0047] After the state modeling module is completed, the software state, parameter configuration state, health characterization, and operating condition information of the target subsystem at the current unified sampling time are converged into a consistent set of inputs. The current software state fingerprint is used to characterize the current software and configuration state, the state change flag is used to identify whether the state change phase has been entered, and the health anchor value and fault event count are used to retain the operational characterization. This gives the input objects clear boundaries and a unified source, which can reduce the judgment bias caused by inconsistent sampling standards, inconsistent parameter encoding, or unclear state identification.

[0048] After the state modeling module has clearly defined the current software state fingerprint and state change marker, whether the target subsystem can use a health judgment boundary that is compatible with the current state depends on whether there is a verified PHM reference template that is consistent with the current software state and current operating conditions. If the template is not accurately located, or if a new configuration is directly enabled before the template has been verified to be consistent with operation, the health conclusion may jump in the early stage of state change. Therefore, the template freezing module needs to complete the template retrieval, template validity confirmation and health conclusion freezing before the change, so as to establish controlled transition output conditions for the state change phase.

[0049] S201: Establishment of a retrieval entry triggered by a status change flag The state modeling module has already generated the current software state fingerprint, condition bucket label, and state change marker at the unified sampling time. The current software state fingerprint is used to characterize the software and configuration state of the target subsystem at the current unified sampling time. The condition bucket label is used to characterize the discrete condition category corresponding to the current unified sampling time. The state change marker is used to characterize whether the target subsystem has entered the state change phase. The template freezing module receives the aforementioned three objects and uses the state change marker as the retrieval trigger condition. When the state change marker indicates that the target subsystem has entered the state change phase, the verified PHM reference template retrieval process is started. When the state change marker indicates that the target subsystem has not entered the state change phase, the template retrieval and freezing process is not started. The normal output link of the most recent valid health conclusion before entering the current unified sampling time is directly maintained. At the same time, the template retrieval status is written to the untriggered state record area so that subsequent steps can identify that no template switching candidate action has occurred at the current unified sampling time.

[0050] After entering the template retrieval process, an input integrity check is first performed on the current software state fingerprint and the operating condition bucket label. This check includes verifying whether the current software state fingerprint has the preset encoding length obtained from the fixed mapping of the state modeling module, whether the operating condition bucket label belongs to the set of valid labels in the target subsystem's preset operating condition classification table, and whether the current software state fingerprint and operating condition bucket label contain null values, missing values, or illegal substitution values. The length check of the current software state fingerprint is performed separately because the software state fields in the reference template library are stored with fixed-length encodings; if the lengths are inconsistent, the index paths in the reference template library cannot be reliably matched. The validity check of the operating condition bucket label is performed separately because it has been verified that the applicable operating conditions of the PHM reference template are bounded by discrete operating condition categories; if the operating condition bucket label falls outside the classification table, it cannot be determined whether the target subsystem's current unified sampling time falls within the applicable operating condition range of any reference template.

[0051] The input integrity review result is written to the input validity status. When the input validity status indicates that the input is valid, the template freezing module continues to construct candidate templates. When the input validity status indicates that the input is invalid, the template freezing module does not enter template location, but directly writes the template missing flag and transfers the target subsystem to the exception handling preparation state. In this way, invalid inputs and inputs without templates are uniformly included in the subsequent exception branch processing.

[0052] S202: Construction of candidate template set and convergence of retrieval boundary.

[0053] After the input validity status indicates that the template is valid, a set of candidate templates is constructed from the reference template library. Each verified PHM reference template in the reference template library contains at least a software status field, a working condition field, a template validity status, a template effective start time, a template effective end time, a health anchor value tolerance range, a fault event tolerance mode, and a PHM configuration identifier. The software status field uses the same encoding standard as the current software status fingerprint output by the state modeling module, and the working condition field uses the same discrete label standard as the working condition bucket label output by the state modeling module. The template validity status is used to characterize whether the reference template has been verified and is allowed to participate in online retrieval. The template effective start time and template effective end time are used to limit the time applicability boundaries of the reference template.

[0054] The candidate template set is constructed in the following order: First, reference templates whose software state fields are completely consistent with the current software state fingerprint are selected from the reference template library. Then, reference templates whose operating condition fields are completely consistent with the operating condition bucket labels are selected from the previous results. Next, reference templates whose effective state is valid are selected from the further results. Finally, reference templates whose current unified sampling time is between the template's effective start time and effective end time are selected from the above results. This forms the candidate template set. "Complete consistency" here does not mean semantic approximation or partial field matching, but rather a complete equality relationship obtained by comparing each item according to the fixed coding standards of the state modeling module. "Between the template's effective start time and effective end time" means that the current unified sampling time is within the time window during which the template is allowed to be invoked. Through the above multi-level filtering, the candidate template set is not a generalized search result from the reference template library, but a template candidate set that converges layer by layer around the current software state fingerprint and operating condition bucket labels. Its function is to map the software state, parameter configuration state, and operating condition state of the target subsystem at the current unified sampling time to a set of template objects with a narrowed scope, thereby establishing a well-defined input set for the subsequent selection of a unique template. If the candidate template set is empty, it means that there is no verified PHM reference template in the reference template library that corresponds to the current software state fingerprint and working condition bucket label and is in the effective range. At this time, the template freezing module will no longer continue to execute template selection, but will switch to the template missing branch.

[0055] S203: Rules for selecting a unique template and rules for conflict resolution.

[0056] When the candidate template set is not empty, the template freezing module continues to perform unique template selection. If there is only one candidate template in the candidate template set, this candidate template is directly determined as the verified PHM reference template at the current unified sampling time; if there are multiple candidate templates in the candidate template set, a unique template is selected based on the template release time order. The template release time order is not a vague sequential concept, but a unique release order identifier written for each verified PHM reference template when it is added to the reference template library. This release order identifier monotonically increases according to the time when the reference template is verified and enters the reference template library, and is not rearranged or reused after being written.

[0057] The unique template selection logic is as follows: First, find the candidate template with the latest release time in the candidate template set, and then count the number of candidate templates with the same latest release time. If the number is one, this candidate template is determined as the verified PHM reference template at the current unified sampling time. If the number is not one, it is determined that there is a template conflict in the reference template library under the combined conditions of the current software state fingerprint and the current working condition bucket label. In this case, the verified PHM reference template is not output, but a template missing flag is written and the system enters the anomaly handling preparation state. The template release time order is used instead of similarity comparison, weight sorting, or mean evaluation because the template freezing module is responsible for online template localization rather than template training. The differences between reference templates have been verified before being added to the library. After entering the online stage, it is only necessary to select the latest verified and unique reference template from the candidate templates that meet the dual constraints of the current software state fingerprint and the working condition bucket label. If the template library allows multiple templates with identical release times to simultaneously meet the same software state and operating conditions, it indicates that the template library boundary itself has not converged. In this case, continuing to push down to the continuous verification module will cause the health anchor value tolerance range and the fault event tolerance mode to lose their definite source. Therefore, the template freezing module directly classifies this situation into the template missing branch.

[0058] S204: Review of the integrity of template content and extraction of template objects.

[0059] Once a verified PHM reference template is uniquely selected, the template freezing module does not immediately enter the freezing process, but continues to perform template content integrity review. The template content integrity review is limited to the health anchor value tolerance range, the fault event tolerance mode, and the PHM configuration identifier, because the continuous verification module must rely on the health anchor value tolerance range and the fault event tolerance mode to perform continuous consistency verification, and the decision-making module must rely on the PHM configuration identifier to complete configuration switching or anomaly handling.

[0060] The review of the health anchor value tolerance range includes whether the lower bound exists, whether the upper bound exists, and whether the order relationship between the lower and upper bounds is valid. The review of the fault event tolerance mode includes whether the fault event type constraint exists, whether the fault event count allowable relationship exists, and whether the mode description corresponds to the target fault event set preset by the target subsystem. The review of the PHM configuration identifier includes whether the configuration identifier is empty and whether the configuration identifier points to the reference template library or an actual configuration entity in the configuration library. Only when all three items pass the review is the template content integrity status written as valid. Subsequently, the health anchor value tolerance range, fault event tolerance mode, and PHM configuration identifier are extracted from the verified PHM reference template as formal input objects for subsequent steps. Among them, the health anchor value tolerance range is used in the subsequent continuous verification module to determine whether the health anchor value is within the numerical range allowed by the reference template, the fault event tolerance mode is used in the subsequent continuous verification module to determine whether the fault event count conforms to the event triggering relationship allowed by the reference template, and the PHM configuration identifier is used in the subsequent decision-making and handling module to complete the configuration switch after the freeze is lifted. If the template content integrity status is set to invalid, it means that although there is a template object that formally meets the software state and working condition constraints, the key fields inside the template are not executable. At this time, the template freezing module also writes the template missing flag and enters the exception handling preparation state, instead of passing the incomplete template to the continuous verification module or decision handling module.

[0061] S205: Freeze triggering and freeze output establishment for health conclusions before change.

[0062] Once the PHM reference template has been verified to be unique and its content integrity status is valid, the template freezing module begins to freeze the pre-change health conclusion. The pre-change health conclusion does not simply refer to the output result at the previous unified sampling time, but rather to the health conclusion that was in a valid output state most recently before entering the state change phase. This definition is adapted to the operating state of the target subsystem under abnormal sampling, delayed sampling, or sampling interruption scenarios.

[0063] The template freeze module first reads the most recent valid health conclusion before entering the state change phase from the health conclusion cache area, and recognizes the read result as the health conclusion before the change. Then, it writes the health conclusion before the change into the freeze output channel to form a frozen output health conclusion, and at the same time writes the freeze status as valid.

[0064] The freeze trigger conditions include three levels. The first level is that the state change flag must indicate that the state change phase has been entered. The second level is that the verified PHM reference template must be uniquely established. The third level is that the integrity status of the template content must be valid. Only when all three levels are met simultaneously can a freeze output health conclusion be established.

[0065] The so-called "writing to the frozen output channel" here does not mean immediately replacing the pre-change health conclusion after a one-time copy. Instead, it means continuously using the same pre-change health conclusion as the source of health conclusions published by the target subsystem during the frozen state, until the decision-making module decides to release the freeze or enter anomaly handling based on the continuous consistency count and continuous mismatch count. The significance of the freeze process is that the template freeze module has located the template boundary through the current software state fingerprint and operating condition bucket label, but the continuous verification module has not yet proven that the current health anchor value and fault event count are indeed consistent with the verified PHM reference template. Therefore, setting the frozen output health conclusion between these two steps ensures that the drift in the operational characteristics when the software state change just occurred will not immediately propagate to the external health conclusion.

[0066] S206: Writing template missing markers and exception handling preparation status.

[0067] In any processing branch of the template freezing module, if any of the following situations occur: invalid input validity, empty candidate template set, failure to select a unique template, or invalid template content integrity, the template freezing module will write a template missing flag and simultaneously write an exception handling preparation status flag.

[0068] The purpose of the template missing marker is to clearly indicate that the template freezing module has failed to provide a usable, validated PHM reference template for subsequent steps. The purpose of the anomaly handling preparatory status marker is to notify the decision-making and handling module that the status change stage corresponding to the current unified sampling time has met the prerequisites for entering the handling chain. To improve the sufficiency of disclosure, the reason for template missing should also be written into the template missing reason field. The template missing reason field should at least distinguish four categories of reasons: invalid input, no matching template, template conflict, and incomplete template content. The subsequent decision-making and handling module can refine the handling strategy based on the template missing reason field.

[0069] After the template missing flag and the anomaly handling preparation status flag are written, the frozen output health conclusion continues to maintain the output of the health conclusion before the change, and no new template objects are passed to the continuous verification module. The processing boundary here is very clear: the template retrieval failure branch does not undertake runtime consistency verification, and runtime consistency verification is only performed under the template retrieval success branch. The reason for this setting is that one of the input objects of the continuous verification module is the health anchor value tolerance range, and the other input object is the fault event tolerance mode. If the template freezing module has not yet formed a legal, unique and complete verified PHM reference template, then the continuous verification module lacks the constraint boundary for performing continuous consistency verification, and its results naturally lack interpretability.

[0070] S207: The processing result is connected to the input of subsequent steps.

[0071] After processing by the template freezing module, the current software state fingerprint, condition bucket label, and state change marker output by the state modeling module have been transformed into two clear results.

[0072] The first type of result is the successful template retrieval branch. In this branch, a verified PHM reference template, a health anchor value tolerance range, a fault event tolerance mode, a PHM configuration identifier, a frozen status, and a frozen output health conclusion are formed. The subsequent continuous verification module directly calls the health anchor value tolerance range and the fault event tolerance mode to perform continuous consistency verification on the health anchor value and fault event count output by the state modeling module. The subsequent decision-making and handling module directly calls the PHM configuration identifier, the frozen status, and the frozen output health conclusion to complete the configuration switch or freeze release.

[0073] The second type of result is the template retrieval failure branch. In this branch, a template missing marker, an anomaly handling preparation status marker, and a template missing reason field are generated. At the same time, the frozen output of the healthy conclusion continues. The subsequent decision-making and handling module enters the relevant software anomaly handling link based on the template missing marker, anomaly handling preparation status marker, and template missing reason field.

[0074] Thus, the template freezing module completes the transformation from the state description object of the state modeling module to the verification boundary object of the continuous verification module, and then to the disposal control object of the decision-making and disposal module. The terminology mapping and input-output relationship between the preceding and following steps are thus fixed.

[0075] After the template freezing module is completed, the current software state fingerprint and condition bucket label are mapped to a unique, valid and complete verified PHM reference template, and the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier are extracted. At the same time, the health conclusion before the change is kept as the frozen output health conclusion. This enables the target subsystem to have clear template boundaries and a stable conclusion output basis during the state change phase, which can reduce the uncertainty caused by directly switching the health conclusion when the template is missing, the template conflicts, or the template has not been verified.

[0076] After the template freezing module completes template positioning and freeze control, although the current software state has obtained the corresponding template boundary, the target subsystem may still experience short-term representation drift, operating condition switching effects, or fluctuations in fault event counts in the early stages of state change. The mere existence of the template cannot directly indicate that the current operating state is consistent with the template. Therefore, the continuous verification module needs to continuously sample and compare the health anchor value and fault event count within the same operating condition boundary, transforming single-point observations into continuous consistency counts and continuous mismatch counts to form a timing basis that can be used for final action decision.

[0077] S301: Verification window startup conditions and binding relationship established.

[0078] The template freezing module has completed the location of the verified PHM reference template and output the health anchor value tolerance range, fault event tolerance mode, freezing status and frozen output health conclusion. The subsequent decision-making and handling module needs to decide whether to unfreeze the state and switch the PHM configuration based on the continuous consistency count and continuous mismatch count. Therefore, the starting point of the continuous verification module is not the monitoring sampling in the general sense, but in the state change phase, to establish a dedicated verification window around the verified PHM reference template corresponding to the current software state fingerprint.

[0079] In specific processing, the continuous verification module first receives the health anchor value, fault event count, and condition bucket label output by the state modeling module. Simultaneously, it receives the verified PHM reference template, health anchor value tolerance range, fault event tolerance mode, frozen state, and frozen output health conclusion output by the template freezing module. When a state change flag indicates that the state change phase has begun, and the verified PHM reference template has been established and the frozen state is valid, the verification window is activated. Once activated, the verification window immediately establishes a one-to-one correspondence with the current software state fingerprint and the verified PHM reference template. During the validity of the verification window, each subsequent sampling point can only be verified based on this set of current software state fingerprints and verified PHM reference templates; cross-state calls to other templates are not allowed.

[0080] To ensure the verification window has a defined observation range, both the effective comparison length and the maximum number of extended samples need to be set. The effective comparison length indicates the minimum number of effective comparison sampling points required before the continuous verification module can submit continuous consistency counts and continuous mismatch counts as official results to the decision-making module. The maximum number of extended samples indicates the maximum number of times the verification window can be extended when inconsistent sampling points continue to occur. The effective comparison length can be determined by using verification samples from the PHM reference template's entry phase, calculating the number of consecutive samples required for the health anchor value to enter the acceptable range and remain valid under the same operating condition bucket label conditions, and the number of consecutive samples required for the fault event count to complete one stable refresh. The consecutive sample count with stronger coverage is then selected as the effective comparison length. The maximum number of extended samples can be determined by using the statistical results of consecutive invalid comparison sampling points when operating condition bucket labels switch within the same batch of verification samples, and then selecting the number of consecutive samples that covers most operating condition switching processes from the aforementioned statistical results as the maximum number of extended samples.

[0081] Through the aforementioned processing, the verification window is no longer a vague duration, but a verification interval with a clear starting point, a clear bound object, a clear valid comparison length, and a clear upper limit for extension.

[0082] S302: Confirmation of operating condition consistency and selection of effective comparison sampling points.

[0083] After the verification window opens, the continuous verification module does not directly use all sampling points within the window as comparison objects. Instead, it first performs a condition consistency verification. This is because the verified PHM reference template is retrieved from the template freezing module using the current software state fingerprint and condition bucket labels. The applicable boundaries of the health anchor value tolerance range and the fault event tolerance mode are established based on the condition category defined by the current condition bucket label. If the condition bucket label of a sampling point within the verification window has deviated from the condition bucket label corresponding to the template selected by the template freezing module, then the health anchor value and fault event count of this sampling point no longer meet the prerequisite for direct comparison with the current template. Therefore, the continuous verification module first reads the current condition bucket label at each sampling point and compares it with the condition bucket label corresponding to the starting point of the state change phase. When they match, the current sampling point is recorded as a valid comparison sampling point; when they do not match, the current sampling point is recorded as an invalid comparison sampling point. Invalid comparison sampling points do not enter health anchor value range matching, nor do they enter fault event mode matching, and they do not generate consistency or mismatch flags. Simultaneously, they do not change the continuous consistency count or continuous mismatch count; they only extend the verification window by a fixed sampling period and accumulate the count of invalid comparison sampling points. When the accumulated number of invalid comparison sampling points reaches the maximum extension sampling number, the continuous verification module stops extending the verification window and hands over the already formed continuous consistency and continuous mismatch counts to the decision-making module for processing. The significance of operating condition consistency verification is that it ensures that every valid comparison sampling point used by the continuous verification module is located within the same operating condition boundary as the verified PHM reference template, thereby maintaining the comparison premise of the health anchor value tolerance range and fault event tolerance mode, and distinguishing between the characterization changes caused by operating condition switching and those caused by software state changes.

[0084] S303: Execution process of health anchor value range matching.

[0085] After the current sampling point is confirmed as a valid comparison sampling point through operational condition consistency verification, the continuous verification module first performs interval matching on the health anchor value. The template freezing module has extracted the allowable interval of the health anchor value from the verified PHM reference template. The allowable interval of the health anchor value consists of a lower bound and an upper bound of the health anchor value, and the lower bound and upper bound of the health anchor value use the same measurement caliber and the same physical dimension as the health anchor value. The processing logic of the health anchor value interval matching is as follows: the health anchor value of the current valid comparison sampling point is compared sequentially with the lower bound and the upper bound of the health anchor value; when the health anchor value is not lower than the lower bound and not higher than the upper bound, the current sampling point is considered to meet the verified PHM reference template in the health anchor value dimension, and is marked as matched in the health anchor value interval matching; when the health anchor value is lower than the lower bound or higher than the upper bound, the current sampling point is considered to deviate from the verified PHM reference template in the health anchor value dimension, and is marked as mismatched in the health anchor value interval matching. The closed-interval comparison relationship is used here because the acceptable range of the health anchor value originates from the boundary of the acceptable running samples during the template verification and database entry stage. The boundary value itself is part of the template's allowed range, rather than a natural exclusion point. The continuous verification module compares the health anchor value of the currently valid comparison sampling point with the acceptable range of the health anchor value at this stage. This is because the target technical problem focuses on whether the representation of a single sampling period after a software state change still falls within the original template boundary. If the health anchor value is averaged first, it would mask the short-term transitional characteristics of the state change stage. Therefore, the health anchor value interval matching mark becomes the first criterion for subsequently generating consistency and mismatch marks.

[0086] S304: Execution process of fault event pattern matching.

[0087] After completing the health anchor value interval matching, the continuous verification module continues to perform pattern matching on the fault event counts of the current valid comparison sampling points. The template freezing module has extracted the fault event tolerance pattern from the verified PHM reference template. To ensure that the fault event tolerance pattern has clear comparison boundaries, in implementation, the fault event tolerance pattern is fixed into two parts: the allowable count relationship and the allowable increment relationship. The allowable count relationship is used to limit the range of values ​​that the fault event count of the current valid comparison sampling point can fall into, and the allowable increment relationship is used to limit the range of values ​​that the change in the fault event count of the current valid comparison sampling point relative to the previous valid comparison sampling point can fall into. The formation logic of the aforementioned two parts is as follows: during the verification PHM reference template storage stage, the fault event count sequence under the same operating condition bucket label conditions is first decomposed into an absolute count sequence and an adjacent valid comparison sampling point difference sequence. Then, the absolute count values ​​that are commonly allowed by all verified samples are written into the allowable count relationship, and the adjacent difference values ​​that are commonly allowed by all verified samples are written into the allowable increment relationship. When the verification window is opened, the fault event count corresponding to the start of the state change phase is identified as the initial comparison benchmark. Therefore, the preceding count benchmark for the first valid comparison sampling point is the fault event count corresponding to the start of the state change phase, rather than the fault event count of the previous invalid comparison sampling point within the window.

[0088] The specific logic of fault event pattern matching is as follows: First, it determines whether the fault event count of the current valid comparison sampling point falls within the value range defined by the allowed counting relationship. Then, it determines whether the change in the fault event count of the current valid comparison sampling point relative to the previous valid comparison sampling point falls within the value range defined by the allowed increment relationship. When both judgments are true, the fault event pattern matching is marked as a match; when either judgment is false, the fault event pattern matching is marked as a mismatch. Through this process, the continuous verification module not only checks whether the fault event count is reasonable at the current moment, but also checks whether the change process of the fault event count is reasonable, thus constraining both the static counting boundary and the dynamic change boundary of the fault event tolerance pattern. Since the fault event count itself comes from the fault event activation record within the preset statistical window, fault event pattern matching is essentially verifying whether the fault event triggering behavior after the state change is still within the behavior pattern allowed by the verified PHM reference template.

[0089] S305: Rules for generating consistency and mismatch tags.

[0090] After the current valid comparison sampling point completes health anchor value interval matching and fault event pattern matching, the continuous verification module generates a consistency flag and a mismatch flag. The consistency flag is generated when both the health anchor value interval matching flag and the fault event pattern matching flag are matched, indicating that the current valid comparison sampling point falls within the allowable boundaries of the verified PHM reference template in both the continuous health representation and fault event representation dimensions. The mismatch flag is generated when at least one of the health anchor value interval matching flag and the fault event pattern matching flag is mismatched, indicating that the current valid comparison sampling point has deviated from the allowable boundaries of the verified PHM reference template in at least one dimension. Inconsistent operating condition sampling points do not generate either a consistency flag or a mismatch flag.

[0091] The reason for adopting the rule of generating a consistency marker when both dimensions are met and a mismatch marker when a single dimension is not met is that this invention aims to address the question of whether the original health conclusions are still applicable after software state changes. If the conclusion is met only in the health anchor value dimension but deviates in the fault event count dimension, or only in the fault event count dimension but deviates in the health anchor value dimension, it cannot be concluded that the operational characterization is completely consistent with the verified PHM reference template. Through the aforementioned rules, the consistency marker and mismatch marker discretize the two-dimensional comparison results of a single valid comparison sampling point into judgment objects that can participate in continuous count updates, thereby providing direct input for the decision-making module to make overall decisions using the first and second thresholds.

[0092] S306: Update process for continuous consistency count and continuous mismatch count.

[0093] When the verification window opens, both the consecutive consistency count and the consecutive mismatch count are initialized to their initial states. For each consistency flag, the consecutive consistency count is incremented based on the result of the previous valid comparison sample point, while the consecutive mismatch count is reset to zero. For each mismatch flag, the consecutive mismatch count is incremented based on the result of the previous valid comparison sample point, while the consecutive consistency count is reset to zero. For each invalid comparison sample point, both the consecutive consistency count and the consecutive mismatch count remain unchanged. Through this process, the consecutive consistency count indicates how many consecutive valid comparison sample points have remained consistent with the verified PHM reference template since the most recent mismatch; the consecutive mismatch count indicates how many consecutive valid comparison sample points have deviated from the verified PHM reference template since the most recent consistency.

[0094] The continuous verification module simultaneously maintains the cumulative number of valid comparison sampling points. When the cumulative number of valid comparison sampling points reaches the valid comparison length, it indicates that the continuous verification module has obtained a sufficient number of valid comparison sampling points under the same operating conditions. The current continuous consistency count and the current continuous mismatch count can then be officially output to the decision-making module for judgment. If, before this, the cumulative number of invalid comparison sampling points reaches the maximum extension sampling number, the continuous verification module stops the current verification window and outputs the continuous consistency count and continuous mismatch count up to the point of stopping, which are also given to the decision-making module for judgment. This is because the continuous consistency count and continuous mismatch count are not simple counters, but rather compress the timing verification results within the state change phase into two continuous state variables that can be directly used by the decision-making module. The former supports unfreezing the state and switching the PHM configuration, while the latter supports entering the software-related anomaly handling chain.

[0095] S307: Explanation of the source of the threshold and summary of the processing results of this step.

[0096] The continuous verification module itself does not perform the first and second threshold judgments, but the continuous consistency count and continuous mismatch count output by the continuous verification module will be directly used as inputs to the decision-making and handling module. Therefore, it is necessary to clarify the source logic of the first and second thresholds in the continuous verification module. The determination process of the first and second thresholds can use the verification samples from the verification PHM reference template storage stage. First, the proportion of erroneous switching after unfreezing under different continuous consistency counts and the proportion of erroneous handling after triggering abnormal handling under different continuous mismatch counts are statistically analyzed in the verification samples. Then, the stability requirements of the frozen output health conclusion and the timeliness requirements of the handling response are used as constraints. The continuous count that can simultaneously meet the stability and timeliness requirements is selected as the first and second thresholds from the aforementioned statistical results. Since both the first and second thresholds come from the statistical results of the template verification samples, their values ​​are not arbitrarily assigned but have a clear data source. After processing by the continuous verification module, the verified PHM reference template boundary provided by the template freezing module has been converted into continuous verification results at the operational observation level. Among them, the condition consistency confirmation screens out the condition switching sampling points, the health anchor value interval matching judges whether the health anchor value falls within the health anchor value allowable interval, the fault event pattern matching judges whether the fault event count conforms to the fault event allowable pattern, the consistency mark and mismatch mark discretize the single-point comparison results, and the continuous consistency count and continuous mismatch count organize the discrete results into a time series that can directly drive the decision-making and handling module. Thus, the operational verification chain after the software state change is closed within the continuous verification module.

[0097] After the continuous verification module is completed, the correspondence between the health anchor value and the health anchor value tolerance range, and the correspondence between the fault event count and the fault event tolerance mode are organized into consistency flags, mismatch flags, continuous consistency counts, and continuous mismatch counts. Furthermore, the sampling points of inconsistent operating conditions are excluded from the valid comparison. This makes the operational characterization of the state change phase no longer dependent on the results of a single sampling, but obtains a stable criterion through continuous verification, which can improve the ability to distinguish between short-term fluctuations, instantaneous codes, and operating condition disturbances.

[0098] After the continuous verification module has generated continuous consistency counts and continuous mismatch counts, the target subsystem is still under the constraint of frozen output health conclusions. Only when the template boundary results and continuous verification results are unified and converged into a clear action can the state change phase be considered to have truly completed closed-loop processing. Therefore, the decision-making and handling module needs to determine whether to unfreeze and switch the PHM configuration or output relevant software abnormality handling instructions based on the template missing flag, abnormal handling preparatory state flag, continuous consistency count, and continuous mismatch count, thereby completing the final action decision of the state change phase.

[0099] S401: Establishment of decision entry and loading of threshold.

[0100] The continuous verification module has already output continuous consistency counts and continuous mismatch counts. The template freezing module has already output the freeze status, freeze output health conclusion, PHM configuration identifier, template missing marker, and anomaly handling preparation status marker. Therefore, before entering the action decision, the decision-making module first uses the aforementioned objects as the unique input objects within the same decision cycle, and uses the most recent valid comparison sampling point within the state change phase as the time reference for this decision. Based on this, the decision-making module first loads a first threshold and a second threshold. The first threshold is used to determine when to unfreeze the state and switch to the PHM configuration corresponding to the current software state fingerprint, and the second threshold is used to determine when to output software-related anomaly handling instructions.

[0101] The first and second thresholds are not manually set temporarily, but are determined based on template verification samples corresponding to the current software state fingerprint and the current operating condition bucket label. Furthermore, the maximum allowable false release ratio constraint, the maximum allowable release delay constraint, the maximum allowable false handling ratio constraint, and the maximum allowable handling delay constraint are pre-defined by the target subsystem's security level and operational response level. Specifically, the process involves first statistically analyzing the false release ratio and release delay corresponding to different consecutive consistency counts from the template verification samples, then selecting the minimum consecutive consistency count that simultaneously satisfies the maximum allowable false release ratio constraint and the maximum allowable release delay constraint as the first threshold. Next, the false handling ratio and handling delay corresponding to different consecutive mismatch counts are statistically analyzed from the same template verification samples, and the minimum consecutive mismatch count that simultaneously satisfies the maximum allowable false handling ratio constraint and the maximum allowable handling delay constraint is selected as the second threshold.

[0102] Through the aforementioned loading method, the first and second thresholds called by the decision-making and handling module have clear data sources, clear statistical boundaries, and clear risk control implications. Therefore, subsequent action decisions are not triggered by experience, but are based on the sample statistical results already formed in the template verification stage.

[0103] S402: Action priority determination and exception handling priority rules.

[0104] After the first and second thresholds are loaded, the decision-making module does not immediately compare the continuous consistency count and the continuous mismatch count. Instead, it first performs an action priority determination. The fixed order of action priorities is: template missing branch first, software-related exception handling branch second, PHM configuration switching branch third, and hold branch last.

[0105] The aforementioned order means that as long as the template missing flag or the anomaly handling preparation status flag is set, the current state of the target subsystem is directly considered not to meet the prerequisites for entering the configuration switching branch, and the continuous consistency count is no longer evaluated to see if it has reached the first threshold. Only when the template missing flag and the anomaly handling preparation status flag are not set will the decision-making module continue to compare the relationship between the continuous mismatch count and the second threshold, and between the continuous consistency count and the first threshold. The reason for this order is that the template missing flag and the anomaly handling preparation status flag are derived from the prior review results of the template freezing module on the existence, uniqueness, and completeness of the template. Once the aforementioned prior conditions are not met, the continuous consistency count output by the continuous verification module no longer has the meaning of supporting configuration switching, so the software-related anomaly handling link should be entered first. The action priority is pre-fixed in the implementation configuration and remains unchanged throughout the entire operation phase of the same target subsystem, thereby eliminating the possibility of different implementation paths making different action decisions for the same input object.

[0106] S403: Freeze / Unfreeze Determination and PHM Configuration Switching.

[0107] When the template missing flag is not set, the anomaly handling preparation status flag is not set, and the frozen status is valid, the decision-making and handling module enters the freeze release determination. The condition for freeze release determination is not the single fact that the template has been successfully retrieved, but that the continuous consistency count has reached the first threshold, and the frozen status remains valid within the current decision period.

[0108] When the continuous consistency count reaches the first threshold, it means that a sufficient number of valid comparison sampling points have been obtained since the most recent mismatch, and the aforementioned valid comparison sampling points simultaneously satisfy the boundaries of the verified PHM reference template in both the health anchor value dimension and the fault event count dimension. Therefore, the decision-making module can determine that the operational representation corresponding to the current software state fingerprint has completed state convergence.

[0109] The execution sequence of the freeze release action is as follows: first, the freeze status is rewritten to invalid; then, the output of the freeze health conclusion is stopped; then, the PHM configuration identifier is written to the running configuration register area, and the current software status fingerprint is written to the configuration binding field, so that the subsequent health assessment link switches to the PHM configuration running mode that uniquely corresponds to the current software status fingerprint.

[0110] After the aforementioned actions are completed, the configuration switch completion status is written, and the continuous consistency count, continuous mismatch count, freeze release time, PHM configuration identifier, and current software state fingerprint generated during this state change phase are all written to the state archive area. After the state archive is completed, the verification window corresponding to the current state change phase is terminated, and the continuous consistency count and continuous mismatch count are no longer accumulated, because at this time the target subsystem has completed the switch from the frozen output health conclusion mode to the PHM configuration mode corresponding to the current software state fingerprint. Subsequent sampling points should enter the normal operation link under the new configuration, instead of continuing to use the old verification window.

[0111] S404: Software-related exception handling judgment and exception category classification.

[0112] When the template missing flag or the anomaly handling preparation status flag is set, the decision-making and handling module directly determines that the software-related anomaly handling conditions are met. When neither the template missing flag nor the anomaly handling preparation status flag is set, but the continuous mismatch count reaches the second threshold, the decision-making and handling module also determines that the software-related anomaly handling conditions are met. This means that in the case of a missing template boundary, the module does not wait for the continuous mismatch count to reach the second threshold, but instead directly enters the handling process as a priori condition not met. In the case of a continuous mismatch count reaching the second threshold, it indicates that although the template boundary exists, the current operational behavior has continuously deviated from the template boundary and met the handling requirements. After the software-related anomaly handling conditions are met, the decision-making and handling module continues to perform anomaly category classification. The anomaly categories are fixed as template boundary missing anomalies, health anchor value deviation anomalies, fault event deviation anomalies, and dual-dimensional common deviation anomalies.

[0113] When classifying anomalies, the aforementioned template missing marker, health anchor value range matching marker, and fault event pattern matching marker are used as the basis for judgment. If the template missing marker is set, it means that no verifiable PHM reference template has been formed under the current software status fingerprint and operating condition bucket label, and it is directly classified as a template boundary missing anomaly. If the template missing marker is not set, but the health anchor value range matching marker is mismatched and the fault event pattern matching marker is matched, it means that the continuous quantity representation has deviated from the health anchor value tolerance range, but the fault event count still conforms to the fault event tolerance pattern. For example, after the software version update, the health anchor value of electric drive temperature rise continues to exceed the template boundary, but the fault code count has not increased abnormally. In this case, it is classified as a health anchor value deviation anomaly. If the template missing marker is set, it indicates that no verifiable PHM reference template has been formed under the current software status fingerprint and operating condition bucket label, and it is directly classified as a template boundary missing anomaly. If the missing marker is not set, and the health anchor value interval matching marker is matched while the fault event pattern matching marker is mismatched, it indicates that the health anchor value is still within the template's allowable range, but the fault event count has deviated from the fault event's allowable pattern. For example, after parameter recalibration, the number of repeated code reports is consistently higher than the template's allowable relationship within a short period of time, while health anchor values ​​such as current, temperature rise, or vibration remain normal. In this case, it is classified as a fault event deviation anomaly. If the template missing marker is not set, and both the health anchor value interval matching marker and the fault event pattern matching marker are mismatched, it indicates that both the continuous quantity representation and the event counting behavior have deviated from the template boundary. For example, after software configuration switching, the battery health anchor value continuously exceeds the limit, and the corresponding fault event count increases abnormally. In this case, it is classified as a dual-dimensional common deviation anomaly.

[0114] Template boundary missing anomalies indicate that the template freezing module failed to generate a validated PHM reference template usable by the continuous verification module and the decision-making module; health anchor value deviation anomalies indicate that the health anchor value has consistently exceeded the health anchor value tolerance range, while the fault event count still conforms to the fault event tolerance pattern; fault event deviation anomalies indicate that the fault event count has consistently failed to conform to the fault event tolerance pattern, while the health anchor value still remains within the health anchor value tolerance range; dual-dimensional deviation anomalies indicate that both the health anchor value and the fault event count consistently deviate from the template boundary. The aforementioned anomaly category classification is not a conceptual naming but is strictly based on the combination of values ​​for template missing markers, health anchor value range matching markers, and fault event pattern matching markers. Therefore, each anomaly category has a clear judgment basis and a clear physical meaning.

[0115] S405: Generation of software-related exception handling instructions and mapping of ordered instruction sets.

[0116] Once the anomaly category is determined, the decision-making and handling module generates software-related anomaly handling instructions. These instructions are defined as an ordered set of instructions, rather than a single action label, because some anomaly categories require multiple actions to be triggered simultaneously, and these actions have a specific order. The mapping rules are as follows: Template boundary missing anomalies are mapped to at least a rollback request instruction, which is used to send a request to the version management link to roll back to the software cluster version corresponding to the target software cluster version identifier that was effective before entering the state change phase; health anchor value deviation anomalies are mapped to at least a threshold reload instruction, which is used to write the pre-stored health anchor value judgment threshold corresponding to the current software state fingerprint into the PHM configuration cache; fault event deviation anomalies are mapped to at least an alarm suppression instruction, which is used to prohibit the external transmission of software-related alarms corresponding to the target fault event set within a preset suppression period; and dual-dimensional common deviation anomalies are mapped to at least an ordered set of instructions consisting of maintenance work order instructions and rollback request instructions, with maintenance work order instructions preceding rollback request instructions. Maintenance work order instructions are used to write a target subsystem-specific investigation task into the operation and maintenance management link.

[0117] Once a software-related anomaly handling instruction is generated, the frozen state remains in effect, and the frozen output health conclusion continues to serve as the sole source of external health conclusions until the first instruction in the ordered instruction set is received by the execution channel and a completion status is reported, or the higher-level management link explicitly returns a new status handling result. The purpose of the aforementioned process is to ensure that the external health conclusions of the target subsystem remain stable before the software-related anomaly handling is actually implemented, and the frozen state should not be prematurely lifted.

[0118] S406: Keep branches and decisions closed.

[0119] When the template missing flag is not set, the anomaly handling preparation status flag is not set, the continuous mismatch count has not reached the second threshold, and the continuous consistency count has not reached the first threshold, the decision-making and handling module enters the hold branch. The hold branch indicates that the current state change phase is still in the verification process. The verified PHM reference template has existed and is complete, and the frozen state is still valid. However, the running performance has not been continuously stable enough to unfreeze, nor has it continuously deviated enough to trigger software-related anomaly handling. Therefore, the frozen output health conclusion continues to be output externally, the PHM configuration identifier is not written to the running configuration register, and software-related anomaly handling instructions are not generated.

[0120] The role of the branch in the decision chain is not simply to wait, but to confine the current state change phase to a repeatable, continuous, and stopable intermediate state. This allows the decision-making module to continue its judgment based on the continuous consistency count and continuous mismatch count formed in the previous decision cycle when the next valid comparison sampling point arrives. The decision closure rule is determined accordingly: if the configuration switch has been completed, the current state change phase terminates with the completion of the configuration switch; if software-related exception handling instructions have been generated, the current state change phase terminates with the output of software-related exception handling instructions; if neither of the above two situations occurs, the output of the health conclusion remains frozen, and the system waits for the continuous verification module to output the result of the next valid comparison sampling point.

[0121] Through this hold branch and termination rule, the decision-making module can only enter one of the following branches in any given decision cycle: configuration switching branch, software-related exception handling branch, or hold branch, thereby completing the conclusion continuity maintenance chain around the current software state fingerprint at the action level.

[0122] S407: Summary of processing results.

[0123] After processing by the decision-making and handling module, the frozen status, frozen output health conclusion, PHM configuration identifier, template missing marker, and anomaly handling preparation status marker output by the template freezing module, as well as the continuous consistency count, continuous mismatch count, health anchor value range matching marker, and fault event pattern matching marker output by the continuous verification module, have been uniformly converted into three types of mutually exclusive action results for the execution layer: configuration switching result, software-related anomaly handling result, and hold result. The configuration switching result corresponds to the unfreezing and activation of the PHM configuration uniquely corresponding to the current software state fingerprint; the software-related anomaly handling result corresponds to the generation of an ordered set of software-related anomaly handling instructions; and the hold result corresponds to the continued maintenance of the frozen output health conclusion. Thus, the state modeling module is responsible for forming the state description object, the template freezing module is responsible for establishing the template boundary and maintaining the frozen output health conclusion, the continuous verification module is responsible for completing continuous verification of operational consistency, and the decision-making and handling module is responsible for completing action judgment and action output. The state change phase processing chain centered around the current software state fingerprint is thus closed at the execution level.

[0124] After the decision-making and handling module is completed, the frozen state, frozen output health conclusion, continuous consistency count, and continuous mismatch count are uniformly converted into configuration switching results, software-related anomaly handling results, or maintenance results. This ensures that the target subsystem can only enter a single and clear action branch during the state change phase. When the stable consistency condition is met, it switches to the PHM configuration corresponding to the current software state fingerprint. When there is a continuous deviation or template boundary anomaly, it outputs software-related anomaly handling instructions. This gives the conclusion processing during the state change phase a clear convergence path and stable action boundaries.

[0125] The above embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0126] The parameters preset in the instruction manual can be pre-calibrated through offline simulation testing, or set to fixed values ​​according to the on-site operating procedures.

[0127] In the description of this specification, references to terms such as "an embodiment," "example," and "specific example" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0128] The above embodiments are only used to help understand the technical solutions of the present invention, and do not describe all implementation details in detail, nor do they limit the present invention to the specific embodiments described above. Based on the content disclosed in this specification, those skilled in the art can make corresponding modifications or substitutions, but as long as they do not depart from the spirit and scope of the present invention, they should fall within the protection scope of the present invention.

Claims

1. An integrated management system for equipment PHM (Professional Health Management) operation software for vehicle platforms, characterized in that: include: The state modeling module collects the target software cluster version identifier, parameter set summary, health anchor value, fault event count and condition bucket label. Based on the target software cluster version identifier, parameter set summary and condition bucket label, it generates the current software state fingerprint and enters the state change phase when the target software cluster version identifier or parameter set summary changes. The template freeze module retrieves the PHM reference template based on the current software status fingerprint and working condition bucket label, and obtains the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier, and freezes the health conclusions before the change. The continuous verification module compares the health anchor value with the health anchor value tolerance range and the failure event count with the failure event tolerance mode, generates a consistency flag or mismatch flag, and updates the continuous consistency count and continuous mismatch count. The decision-making and handling module unfreezes and switches the PHM configuration corresponding to the PHM configuration identifier when the continuous consistency count reaches the first threshold, and outputs an exception handling instruction when the continuous mismatch count reaches the second threshold.

2. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The state modeling module includes: Generating the current software state fingerprint involves extracting parameter fields that act on the target subsystem according to a preset field order, performing unified encoding on each parameter field to form a parameter set summary, and writing the target software cluster version identifier, parameter set summary, and operating condition bucket label into a basic state string in a fixed order. The current software state fingerprint is then generated from the basic state string.

3. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The state modeling module also includes: Entering the state change phase involves comparing the target software cluster version identifier and parameter set summary of the current sampling period with the corresponding content of the previous sampling period. If any comparison result is inconsistent, a state change flag is written.

4. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The template freeze module includes: The corresponding PHM reference template is retrieved. This includes using the current software status fingerprint as the main search condition, the working condition bucket label as the working condition constraint condition, and the template validity status and template effective time as filtering conditions to determine the unique verified PHM reference template corresponding to the current unified sampling time.

5. The equipment PHM operation software integrated management system for vehicle platforms according to claim 4, characterized in that, The template freeze module also includes: The determination of the unique verified PHM reference template includes comparing the candidate templates according to the order of their verification and entry into the database when there is more than one candidate template that meets the main search conditions and operating condition constraints. The candidate template that was most recently verified and entered into the database and whose content is complete is selected as the verified PHM reference template, and the health anchor value tolerance range, fault event tolerance mode and PHM configuration identifier are extracted.

6. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The template freeze module also includes: Freeze the health conclusions before the change, which includes reading the health conclusion of the most recent valid output before entering the state change phase from the health conclusion cache at the start of the state change phase and writing it into the freeze output channel to form the freeze output health conclusion.

7. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The continuous verification module includes: Generate consistency or mismatch flags, including first determining whether the working condition bucket label of the current sampling point is consistent with the working condition bucket label corresponding to the verified PHM reference template within the preset verification window. Only when they are consistent, compare the health anchor value with the health anchor value tolerance range and the fault event count with the fault event tolerance mode respectively. Generate a consistency flag when both comparisons are true at the same time; otherwise, generate a mismatch flag.

8. The equipment PHM operation software integration management system for vehicle platforms according to claim 7, characterized in that, The continuous verification module also includes: The fault event tolerance mode includes the allowable count relationship and the allowable increment relationship. Comparing the fault event count with the fault event tolerance mode includes determining whether the fault event count of the current sampling point satisfies the allowable count relationship and whether the change in the fault event count of the current sampling point relative to the previous valid comparison sampling point satisfies the allowable increment relationship. The comparison is considered valid when both are satisfied.

9. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The decision-making and handling module includes: Both the first threshold and the second threshold are determined based on template verification samples corresponding to the current software status fingerprint and working condition bucket label. The first threshold is determined based on the false release ratio and release delay, and the second threshold is determined based on the false handling ratio and handling delay. They are stored in association with the PHM configuration identifier when the verified PHM reference template is entered into the database.

10. The equipment PHM operation software integrated management system for vehicle platforms according to claim 1, characterized in that, The decision-making and handling module also includes: Output software-related exception handling instructions, including classifying exception categories based on template missing markers, comparison results of health anchor values ​​and health anchor value tolerance ranges, and comparison results of fault event counts and fault event tolerance modes, and outputting a set of exception handling instructions corresponding to the exception categories according to preset mapping relationships.

Images