Vehicle terminal operation risk identification method, device, equipment and medium

Abstract

The application discloses a kind of running risk identification method, device, equipment and medium of vehicle terminal, it is related to intelligent network connection automobile technical field, method includes: the response time delay sequence of real-time acquisition vehicle terminal internal service message, the fluctuation rate of response time delay sequence is calculated;According to current vehicle operating state and network signal condition, corresponding fluctuation rate baseline value is read from pre-set scene bucket, the deviation ratio of fluctuation rate relative to fluctuation rate baseline value is calculated;When deviation ratio exceeds pre-set threshold and continues to exceed pre-set length of time, according to pre-set root cause identification rule, verification is carried out, after verification, it is judged that vehicle terminal enters sub-health state, and corresponding root cause label is output;According to the pre-set classification interval where deviation ratio is located, determine corresponding early warning level, and according to root cause label, determine early warning strategy, construct corresponding early warning message and report to cloud end.The application can perceive abnormal change in time, so as to realize risk identification in the transition stage before failure occurs.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, specifically to a method, device, equipment, and medium for identifying operational risks of an in-vehicle terminal. Background Technology

[0002] Commercial vehicle T-Boxes (vehicle-mounted terminals) operate continuously under dual-mode monitoring (running / parking). Internal software risks (such as memory leaks, task scheduling anomalies, and slow protocol stack degradation) typically accumulate slowly, exhibiting a gradual transition from a normal state to a faulty state—a phase defined as sub-health. Existing solutions can only identify faults after they have occurred or performance has severely deteriorated. They lack effective monitoring methods for the gradual degradation process from normal to faulty performance, failing to detect risks in advance during the transition phase before a fault occurs. During this transition, while the system service experience is substantially affected, existing solutions do not provide any response, resulting in a severely insufficient window for maintenance intervention. Furthermore, when detecting performance anomalies, existing solutions cannot distinguish whether the anomaly originates from changes in the device's own operating state or from changes in the external communication environment, making it difficult to pinpoint the true cause of the problem. In addition, some existing solutions rely on external servers or platforms for judgment, and cannot perform the identification function in scenarios where the network connection between the device and the server is unavailable or the communication quality is poor. In addition, the judgment criteria of the existing scheme are relatively fixed. When the equipment operating environment changes, the judgment criteria cannot be adaptively adjusted. The difference in the performance of the same anomaly under different environments may lead to misjudgment or missed judgment. Summary of the Invention

[0003] This application provides a method, apparatus, device, and medium for identifying operational risks of vehicle-mounted terminals, which can solve the technical problems of low immediacy and accuracy in providing early warnings of risks to commercial vehicle-mounted terminals in the prior art.

[0004] In a first aspect, embodiments of this application provide a method for identifying operational risks of an in-vehicle terminal, the method comprising: The response delay sequence of internal service messages of the vehicle terminal is acquired in real time, and the volatility of the response delay sequence is calculated. Based on the current vehicle operating status and network signal conditions, the corresponding volatility baseline value is read from the preset scenario bucket, and the deviation ratio of the volatility relative to the volatility baseline value is calculated. When the deviation ratio exceeds a preset threshold and continues to exceed a preset duration, verification is performed according to the preset root cause identification rules. After the verification is passed, the vehicle terminal is determined to have entered a sub-healthy state and the corresponding root cause label is output. The corresponding warning level is determined based on the preset grade range in which the deviation ratio is located, and the warning strategy is determined based on the root cause label. The corresponding warning message is then constructed and reported to the cloud.

[0005] In conjunction with the first aspect, in one implementation, calculating the volatility of the response delay sequence includes: The response delay sequence is maintained within a sliding window, and the statistics of the samples within the window are updated in real time using the Welford incremental algorithm. The sample standard deviation of the response delay sequence is calculated within the sliding window, specifically as follows:

[0006] in, This represents the current standard deviation, which is equivalent to volatility. This represents the sum of squared deviations accumulator. This indicates the number of samples currently in the sliding window; Specifically, when a new response delay sample is enqueued, the number of samples, mean, and sum of squared deviations accumulator within the sliding window are updated, as follows:

[0007]

[0008]

[0009]

[0010] in, This indicates the deviation of the current sample from the mean before the update. This represents a new sample of response delay. This represents the mean before the update. This represents the updated mean. This indicates the deviation of the current sample from the updated mean. This represents the updated sum of squared deviations accumulator. This represents the sum of squared deviations accumulator before the update; When the sliding window is full and new response latency samples are enqueued, the oldest sample needs to be removed. A dequeue update is then performed, specifically:

[0011]

[0012]

[0013]

[0014] in, This indicates the number of samples after dequeueing. This represents the difference between the oldest sample and the mean before removal. This represents the oldest sample.

[0015] In conjunction with the first aspect, in one implementation, calculating the volatility of the response delay sequence further includes: When the vehicle terminal is in a parked monitoring state, based on the response latency sample at the current moment, the exponentially weighted mean at the previous moment, and the exponentially weighted variance at the previous moment, the exponentially weighted mean and exponentially weighted variance at the current moment are calculated, specifically as follows: The volatility at the current moment is calculated based on the index-weighted variance, specifically as follows:

[0016]

[0017]

[0018] in, Represents the smoothing coefficient. This represents the exponentially weighted average at the current moment. This represents the exponentially weighted average of the previous time step. This represents the exponentially weighted variance at the previous time step.

[0019] In conjunction with the first aspect, in one implementation, the step of reading the corresponding volatility baseline value from a preset scenario bucket based on the current vehicle operating status and network signal conditions, and calculating the deviation ratio of the volatility relative to the volatility baseline value, includes: The vehicle status category is determined based on the current vehicle operating status, and the network signal level is determined based on the current cellular signal strength. The combination of these factors yields the current scene bucket index. Read the corresponding volatility baseline value from the current scenario bucket, and calculate the deviation ratio of the volatility relative to the volatility baseline value, specifically:

[0020] in, Indicates the deviation ratio. This represents the baseline value of volatility.

[0021] In conjunction with the first aspect, in one implementation, the step of verifying according to preset root cause identification rules, and determining that the vehicle terminal has entered a sub-healthy state after successful verification, and outputting the corresponding root cause label, includes: Collect auxiliary status parameters, which include at least cellular signal strength, CPU utilization, memory utilization, bus load rate, message retransmission rate, watchdog reset count increment, and chip junction temperature; Based on the auxiliary state parameters, the first, second, third, fourth, fifth, and sixth sub-rules of the preset root cause identification rules are executed sequentially. The process stops when a root cause is hit and the corresponding root cause label is output. The first sub-rule is that when the volatility increases and the cellular signal strength is less than the first preset strength threshold, it is attributed to external network degradation, the verification fails, and a suppression warning is issued. The second sub-rule is that when volatility increases and the increase in the number of watchdog resets within a preset time period is greater than or equal to the preset increment, it is attributed to a watchdog-triggered anomaly, and the verification is passed. The third sub-rule is that when the volatility increases and the cellular signal strength is greater than or equal to the second preset strength threshold, and the memory occupancy rate increases monotonically for multiple consecutive sampling intervals and the increase exceeds the preset range, it is attributed to memory leak-type sub-health, and the verification is passed. The fourth sub-rule is that when the volatility increases and the cellular signal strength is greater than or equal to the second preset strength threshold and the message retransmission rate is greater than the preset retransmission rate, it is attributed to a protocol stack or driver abnormality, and the verification is passed. The fifth sub-rule states that when volatility increases and bus load rate is less than preset load rate while CPU utilization is greater than preset utilization rate, the cause is attributed to software resource conflict or task scheduling anomaly, and the verification is passed. The sixth sub-rule states that when volatility increases and the chip junction temperature is greater than or equal to the preset junction temperature, the performance degradation is attributed to thermal throttling, and the verification is passed. If the preset root cause identification rule is not matched, it is marked as unclassified, verified and reported to the cloud.

[0022] In conjunction with the first aspect, in one implementation, determining the corresponding warning level based on the preset severity level range into which the deviation ratio falls includes: When the deviation ratio is within the first preset range and continues to exceed the duration threshold, it is determined to be the first sub-health warning level; When the deviation ratio is within the second preset range and continues to exceed the duration threshold, it is determined to be the second sub-health warning level; When the deviation ratio is within the third preset range and continues to exceed the duration threshold, it is determined to be the third sub-health warning level; When the deviation ratio is in the third preset range and continues to exceed the upgrade time threshold, it is upgraded to a formal fault mode and written into the fault history.

[0023] In conjunction with the first aspect, in one implementation method: During the initial learning period, each scene bucket disables the warning output and does not calculate the deviation ratio. The learning period is calculated by accumulating the effective sampling time independently for each scene bucket. After each scene bucket reaches the learning period, it independently enters the working period. During the working period, each scenario bucket updates the baseline value using an exponentially weighted moving average based on samples that have not triggered the sub-health assessment. Samples that have triggered the assessment do not participate in the baseline update. Specifically, when it is detected that the volatility baseline value of any scenario bucket changes by more than a preset amount within a preset time window, the volatility baseline value of that scenario bucket is determined to be abnormal, the volatility baseline value of that scenario bucket is reverted to the factory default baseline value, and the learning period is restarted.

[0024] Secondly, embodiments of this application provide an operational risk identification device for a vehicle-mounted terminal, the operational risk identification device for the vehicle-mounted terminal comprising: The acquisition module is used to acquire the response delay sequence of internal service messages of the vehicle terminal in real time and calculate the volatility of the response delay sequence. The calculation module is used to read the corresponding volatility baseline value from the preset scenario bucket according to the current vehicle operating status and network signal conditions, and calculate the deviation ratio of the volatility relative to the volatility baseline value; The attribution module is used to verify the root cause identification rule according to the preset root cause identification rule when the deviation ratio exceeds the preset threshold and continues to exceed the preset time. After the verification is passed, the vehicle terminal is determined to enter a sub-healthy state and the corresponding root cause label is output. The early warning module is used to determine the corresponding early warning level based on the preset grade range in which the deviation ratio is located, determine the early warning strategy based on the root cause label, construct the corresponding early warning message, and report it to the cloud.

[0025] Thirdly, this application provides an operational risk identification device for a vehicle terminal. The operational risk identification device for a vehicle terminal includes a processor, a memory, and an operational risk identification program for the vehicle terminal stored in the memory and executable by the processor. When the operational risk identification program for the vehicle terminal is executed by the processor, it implements the steps of the operational risk identification method for the vehicle terminal as described in any of the above embodiments.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing a vehicle-mounted terminal operation risk identification program, wherein when the vehicle-mounted terminal operation risk identification program is executed by a processor, it implements the steps of the vehicle-mounted terminal operation risk identification method as described in any of the above embodiments.

[0027] The beneficial effects of the technical solutions provided in this application include: This application embodiment calculates the volatility of the response delay sequence and monitors its deviation from the baseline. This allows for the detection of abnormal changes in system state before the absolute values ​​of performance indicators deteriorate significantly, thus enabling risk identification during the transition phase before a failure occurs. This application embodiment further verifies the deviation ratio according to preset root cause identification rules by performing multi-dimensional verification after the deviation ratio exceeds a preset threshold and persists for a preset duration. Only after successful verification is the system determined to be in a sub-healthy state and a root cause label is output. This distinguishes whether the performance anomaly originates from the device itself or changes in the external environment, reducing false positives. This application embodiment calculates the deviation ratio by reading the volatility baseline value from the corresponding preset scenario bucket based on the current vehicle operating status and network signal conditions. Different operating scenarios use their own independent baseline values, allowing the judgment benchmark to adaptively adjust with changes in the device's operating environment, avoiding false positives or false negatives due to environmental differences. This application embodiment, through the setting of preset graded intervals, can distinguish different degradation stages and output corresponding warning levels, enabling the system to perceive and respond to performance degradation during the transition process. Attached Figure Description

[0028] Figure 1 A flowchart illustrating the operational risk identification method for an in-vehicle terminal provided in this application embodiment; Figure 2 This is a comparison chart of the timing for determining the threshold method and the volatility method provided in the embodiments of this application; Figure 3 The overall architecture diagram of the vehicle terminal operation risk identification system provided in the embodiments of this application; Figure 4 A schematic diagram of the pre-fault snapshot double buffering and token bucket rate limiting mechanism provided in the embodiments of this application; Figure 5 This is an end-to-end flowchart of an embodiment of the active warning system for driving status provided in this application; Figure 6 A timing diagram for identifying parking monitoring state memory leaks, provided in another embodiment of this application; Figure 7 A state machine diagram of the cold start learning period and anti-pollution mechanism provided in another embodiment of this application; Figure 8 A schematic diagram of the functional modules of the vehicle terminal operation risk identification device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of the vehicle-mounted terminal operation risk identification device involved in the embodiments of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0031] This application provides a method, apparatus, device, and medium for identifying operational risks of vehicle-mounted terminals, which can solve the technical problems of low immediacy and accuracy in providing early warnings of risks to commercial vehicle-mounted terminals in the prior art.

[0032] In a first aspect, embodiments of this application provide a method for identifying operational risks of an in-vehicle terminal.

[0033] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the method for identifying operational risks of an in-vehicle terminal provided in an embodiment of this application. Figure 1 As shown, the method for identifying operational risks of vehicle-mounted terminals specifically includes the following steps: Step S1: Obtain the response delay sequence of internal service messages of the vehicle terminal in real time, and calculate the volatility of the response delay sequence.

[0034] Specifically, the time interval between the sending of a service request message and the receiving of the corresponding response message within the vehicle terminal is recorded as a response delay sample.

[0035] In this embodiment of the application, the calculation of the volatility of the response delay sequence in step S1 specifically includes the following steps: The response delay sequence is maintained within a sliding window, and the statistics of the samples within the window are updated in real time using the Welford incremental algorithm. The sample standard deviation of the response delay sequence is calculated within the sliding window, specifically as follows:

[0036] in, This represents the current standard deviation, which is equivalent to volatility. This represents the sum of squared deviations accumulator. This indicates the number of samples currently in the sliding window.

[0037] Specifically, the sample standard deviation calculated for the response delay sequence within the current sliding window is used to characterize the dispersion of each response delay sample relative to its mean within the window. The larger the sample standard deviation, the more dispersed the distribution of the response delay samples; the smaller the sample standard deviation, the more concentrated the distribution of the response delay samples.

[0038] The Welford incremental algorithm only requires a constant number of arithmetic operations when new samples are enqueued or old samples are dequeued to update the statistics. The algorithm's execution process consists of two phases: enqueue update and dequeue update.

[0039] The enqueue update specifically involves updating the number of samples, mean, and sum of squared deviations accumulator within the sliding window when a new response delay sample is enqueued.

[0040]

[0041]

[0042]

[0043] in, This indicates the deviation of the current sample from the mean before the update. This represents a new sample of response delay. This represents the mean before the update. This represents the updated mean. This indicates the deviation of the current sample from the updated mean. This represents the updated sum of squared deviations accumulator. This represents the sum of squared deviations accumulator before the update; Specifically, the deviation of the current sample from the mean before the update represents the direction and magnitude of the new sample's deviation from the average level of all samples within the window before the update. The updated mean equals the mean before the update plus the deviation divided by the number of samples after the update. Since the deviation can be positive or negative, the mean shifts accordingly in the direction of the new sample, with the magnitude of the shift being directly proportional to the magnitude of the deviation and inversely proportional to the total number of samples. The deviation of the current sample from the updated mean is used to subsequently update the sum of squared deviations accumulator. The updated sum of squared deviations accumulator is the accumulated amount needed to subsequently calculate the sample standard deviation; its physical meaning is the sum of the squared deviations of each sample within the window from the mean.

[0044] The dequeue update is specifically performed when the sliding window is full and the oldest sample needs to be removed when a new response latency sample is enqueued.

[0045]

[0046]

[0047]

[0048] in, This indicates the number of samples after dequeueing. This represents the difference between the oldest sample and the mean before removal. This represents the oldest sample.

[0049] Specifically, a full sliding window means that the number of samples within the window has reached the preset window size, and when a new response delay sample needs to be enqueued, the sample with the longest storage time in the window must be removed first to make room for the new sample. The updated mean is equal to the original mean minus the deviation of the removed samples divided by the number of samples after removal. Since the deviation of the removed samples can be positive or negative, the mean shifts accordingly in the opposite direction, with the magnitude of the shift being directly proportional to the magnitude of the deviation and inversely proportional to the total number of samples after removal.

[0050] In this embodiment of the application, calculating the volatility of the response delay sequence further includes: When the vehicle terminal is in a parked monitoring state, based on the response latency sample at the current moment, the exponentially weighted mean at the previous moment, and the exponentially weighted variance at the previous moment, the exponentially weighted mean and exponentially weighted variance at the current moment are calculated, specifically as follows: The volatility at the current moment is calculated based on the index-weighted variance, specifically as follows:

[0051]

[0052]

[0053] in, Represents the smoothing coefficient. This represents the exponentially weighted average at the current moment. This represents the exponentially weighted average of the previous time step. This represents the exponentially weighted variance at the previous time step.

[0054] Specifically, after the vehicle is turned off, the in-vehicle terminal typically enters a parking monitoring state. In this state, the terminal maintains low power consumption and continuously monitors network signals and remote wake-up commands. The parking monitoring state can last from several days to several weeks. During this time, the memory usage, task scheduling, and protocol stack state of the in-vehicle terminal's internal software may slowly deteriorate over time. Therefore, volatility calculation in the parking monitoring state requires continuous monitoring of the response latency sequence with extremely low storage and computational overhead. In the parking monitoring state, volatility is calculated using an exponentially weighted moving average variance method.

[0055] The exponentially weighted mean is an estimate obtained by exponentially weighting and smoothing the mean of the response delay sequence. The exponentially weighted variance is an estimate obtained by exponentially weighting and smoothing the variance of the response delay sequence. The smoothing coefficient is a parameter used to control the weight of historical and current data in the estimate, and can be set between 0.05 and 0.1. A smaller smoothing coefficient indicates a greater weight of historical data in the estimate, resulting in smaller short-term fluctuations and a more stable baseline. A larger smoothing coefficient indicates a greater weight of current data in the estimate, making the estimate more sensitive to real-time changes in the system state.

[0056] In the parking monitoring state, the volatility is calculated using the exponentially weighted moving variance (EWMV) method. Compared with the Welford incremental algorithm using a sliding window, only a constant number of multiplication and addition operations need to be performed at each sampling time. There is no need to perform enqueue, dequeue and window full judgment operations, which helps to reduce power consumption in the parking monitoring state.

[0057] Step S2: Based on the current vehicle operating status and network signal conditions, read the corresponding volatility baseline value from the preset scenario bucket and calculate the deviation ratio of volatility relative to the volatility baseline value.

[0058] In this embodiment of the application, step S2 specifically includes the following steps: Step S21: Determine the vehicle status category based on the current vehicle operating status, determine the network signal level based on the current cellular signal strength, and combine them to obtain the current scene bucket index.

[0059] Specifically, vehicle operating states are categorized into four types: driving, parking and monitoring, charging, and OTA upgrade. OTA upgrade specifically refers to the onboard terminal downloading, verifying, installing, or activating a new version of software package via wireless network. Network signal strength is categorized into three levels: strong, medium, and weak. Preset scenario buckets are used to store and update the baseline values ​​of response latency volatility under different operating scenarios. Each scenario bucket is uniquely identified by a tuple of vehicle operating state and network signal level. There are four vehicle operating states and three network signal levels, resulting in a total of 12 preset scenario buckets. Each scenario bucket independently maintains its corresponding volatility baseline value. A scenario bucket index is used to uniquely identify a scenario bucket among the 12 preset scenario buckets. The volatility baseline value represents the normal level of response latency volatility under that scenario. The volatility baseline value is continuously updated from the historical normal samples of that scenario bucket using an exponentially weighted moving average (EWMA). During the working period, only samples that have not triggered the sub-health determination participate in the baseline update, while samples that have been determined to be sub-healthy do not participate in the baseline update, in order to prevent the volatility baseline value from being contaminated by abnormal samples.

[0060] Step S22: Read the corresponding volatility baseline value from the current scenario bucket, and calculate the deviation ratio of volatility relative to the volatility baseline value, specifically:

[0061] in, Indicates the deviation ratio. This represents the baseline value of volatility.

[0062] The embodiments of this application maintain baseline values ​​independently for each scenario, so that the judgment benchmark for each scenario is determined by the normal operation data of that scenario itself, thus avoiding baseline mismatch caused by different scenarios.

[0063] Step S3: When the deviation ratio exceeds the preset threshold and continues for a preset duration, verification is performed according to the preset root cause identification rules. After the verification is passed, the vehicle terminal is determined to have entered a sub-healthy state and the corresponding root cause label is output.

[0064] Specifically, a larger deviation ratio indicates a more significant deviation of the response delay sequence from the baseline. This application divides the deviation ratio into several intervals, each corresponding to a different operational state level. A duration condition is also introduced to prevent misjudgments caused by transient fluctuations. The quantitative judgment criteria for sub-health states are shown in Table 1 below.

[0065]

[0066] Table 1. Quantitative Judgment Criteria for Sub-health Status The system uses three thresholds: First threshold k1, which is the boundary value for the deviation ratio between the normal state and the sub-health L1 level, defaulting to 1.5. When the deviation ratio is below k1, the system classifies it as a normal state; when the deviation ratio reaches k1 but is below k2, the system classifies it as entering the sub-health L1 level. Second threshold k2, which is the boundary value for the deviation ratio between the sub-health L1 and sub-health L2 levels, defaulting to 3.0. When the deviation ratio reaches k2 but is below k3, the system classifies it as entering the sub-health L2 level. Third threshold k3, which is the boundary value for the deviation ratio between the sub-health L2 and sub-health L3 levels, defaulting to 5.0. When the deviation ratio reaches k3 or above, the system classifies it as entering the sub-health L3 level. The preset duration includes a duration threshold and an upgrade time threshold. The duration threshold is the shortest duration used to exclude false judgments caused by transient fluctuations, defaulting to 5 seconds. The time limit for upgrading from sub-health L3 state to formal DTC after exceeding this time threshold is the default value, defaulting to 60 seconds. In some other embodiments of this application, k1 can be 1.2~2.0, k2 can be 2.0~4.0, k3 can be 4.0~8.0, and the duration threshold can be 2s~30s.

[0067] The normal operating state is when the deviation ratio is below the first threshold k1, indicating that the current response latency volatility is within the normal range for this scenario, and the system has not experienced significant performance degradation. Sub-health L1 level is when the deviation ratio reaches k1 but is below k2, indicating a slight deviation in the current response latency volatility. At this level, the system records event information locally but does not actively report to the cloud to maintain reasonable use of communication resources. Sub-health L2 level is when the deviation ratio reaches k2 but is below k3, indicating a moderate deviation in the current response latency volatility. At this level, the system must actively report a warning message to the cloud and trigger a snapshot freeze to save the pre-fault data. Sub-health L3 level is when the deviation ratio reaches k3 or higher, indicating a severe deviation in the current response latency volatility. At this level, the system must immediately report a warning message to the cloud and trigger a snapshot freeze. The fault state is when the deviation ratio continuously maintains L3 level and the escalation time exceeds the escalation time threshold. In this state, the system escalates the event to a formal Diagnostic Trouble Code (DTC) and writes it to the fault history.

[0068] Normal response delay samples are allowed to participate in the exponentially weighted moving average update of the current scenario bucket volatility baseline value to reflect slow changes under normal system operation. Samples in sub-healthy states (L1, L2, L3) are not included in the baseline update to prevent abnormal samples from being included in the baseline, which would lead to an increase in the baseline and a subsequent decrease in sensitivity.

[0069] In one specific embodiment, Figure 2 This is a comparison chart showing the timing of judgment between the traditional threshold method and the volatility method provided in the embodiments of this application. See also... Figure 2 , Figure 2 The study recorded the state determination results of the traditional threshold method (fixed threshold 3000ms) and the volatility method of this scheme as the response latency gradually increased from 100ms to 1150ms. In the t=40s~50s interval, the absolute value of the response latency had not yet reached the judgment threshold of the traditional threshold method, and the traditional threshold method had no output during this stage. However, in the t=40s~60s interval of this scheme, the deviation ratio r corresponding to the response latency volatility had reached the lower limit of the second preset interval (r≥k2=3.0) and continued to exceed the duration threshold, triggering an L2 warning. When t=120s, the absolute value of the response latency was still far below the traditional judgment threshold of 3000ms, but this scheme had already completed the sub-health state determination in the t=40s~60s interval, forming an advance window of approximately 5~30 minutes (depending on the degradation rate).

[0070] The upgrade rules for sub-health levels are as follows: when the deviation ratio jumps from the current level range to a higher level range and the duration reaches the duration threshold, the system immediately reports an early warning message according to the response method of the new level, without waiting for the original level to recover. The downgrade rules for sub-health levels are as follows: when the deviation ratio remains below the lower limit threshold corresponding to the current level and the duration exceeds the recovery delay threshold (default is 30 seconds), the system sends a recovery message, indicating that the system has exited the sub-health state. For example, if the current sub-health warning level is the second level (r≥k2), and the deviation ratio recovery delay time remains below k2, the system determines that it has recovered. The upgrade and downgrade rules enable the system state to dynamically adjust according to changes in the actual operating quality of the system. When the degree of deterioration deepens, the level jumps upward and is reported immediately; when the system recovers, it can notify the cloud to lift the warning through a recovery message.

[0071] In this embodiment, the tiered judgment enables the system to distinguish different degrees of degradation and match them with differentiated response methods. Small deviations are not reported locally to avoid wasting communication resources; larger deviations are proactively reported to ensure the cloud can promptly detect anomalies; severe deviations are reported immediately to shorten maintenance response time. Simultaneously, the introduction of a duration threshold eliminates misjudgments caused by single-sample jitter or instantaneous interference. Only events with sustained deviations exceeding this time window trigger a judgment, improving the reliability of the judgment.

[0072] In this embodiment of the application, step S3 involves verifying the root cause based on preset root cause identification rules. Upon successful verification, the vehicle terminal is determined to be in a sub-healthy state, and the corresponding root cause label is output, including: Step S31: Collect auxiliary status parameters, which include at least cellular signal strength, CPU utilization, memory utilization, bus load rate, message retransmission rate, watchdog reset count increment, and chip junction temperature.

[0073] The acquisition frequency and data source of each auxiliary status parameter are shown in Table 2 below.

[0074]

[0075] Table 2. Acquisition frequency and data sources of auxiliary status parameters The AT (Attention Command) command set is used to control the operation of the cellular module. The API (Application Programming Interface) is a function interface provided by the cellular module manufacturer. The host can directly obtain cellular network status parameters such as RSRP by calling this interface without parsing the return string of the AT command. The OS scheduler (Operating System Scheduler) is responsible for task scheduling and CPU time allocation. ` / proc / stat` and ` / proc / meminfo` are both virtual file system nodes in the Linux operating system. CAN (Controller Area Network) and CAN-FD (CAN with Flexible Data-Rate) are both serial communication protocols used in automotive networks. The SoC (System on Chip) chip of the automotive terminal integrates a temperature sensor to monitor the chip junction temperature.

[0076] Step S32: Based on the auxiliary state parameters, execute the first sub-rule, the second sub-rule, the third sub-rule, the fourth sub-rule, the fifth sub-rule, and the sixth sub-rule in the preset root cause identification rules in sequence. Stop when a root cause is hit and output the corresponding root cause label.

[0077] Specifically, when the deviation ratio exceeds the first threshold k1 and the duration exceeds the duration threshold, the system determines that the current response delay volatility has an abnormal deviation, but the source of this abnormal deviation is not yet clear. The root cause identification process is used to perform cross-validation based on preset root cause identification rules and multiple auxiliary state parameters to determine the specific attribution direction of the abnormal deviation and output the corresponding root cause label. The preset root cause identification rules are shown in Table 3 below.

[0078]

[0079] Table 3 Preset Root Cause Identification Rules The six root cause rules are arranged in descending order of priority. During execution, the system evaluates each rule sequentially, starting with the first sub-rule. If all conditions of the first sub-rule are met, the evaluation of subsequent rules stops, and the root cause label corresponding to that rule is output along with the corresponding action. If none of the rules are met, 0xFF is output as an unclassified flag. This represents the volatility of the response delay sequence, which is the sample standard deviation of the response delay calculated in step S1.

[0080] The first sub-rule is that when volatility increases and cellular signal strength is less than a first preset strength threshold, it is attributed to external network degradation, the verification fails, and the warning is suppressed. The first preset strength threshold is specifically... 100dBm. When this rule is triggered, the cause of the current abnormal deviation is determined to be external network degradation, which is a communication environment issue rather than a software failure of the vehicle terminal itself. Therefore, the action of this rule is to suppress alarms, that is, not to trigger warning reports for vehicle terminal software problems, but only to record the event locally. This rule has the highest priority; once triggered, the evaluation of all subsequent rules is stopped. The root cause label of the first sub-rule is 0x10, external network degradation.

[0081] The second sub-rule attributes an increase in volatility and a watchdog reset count increase greater than or equal to a preset increment within a preset time period to a watchdog-triggered anomaly, and this has been verified. The preset time period is 10 minutes, and the preset increment is 1 reset. Watchdog reset is a hardware monitoring mechanism within the vehicle terminal, independent of software operation. When a serious software anomaly prevents the system from feeding the watchdog within a preset time, the watchdog timer times out and triggers a hardware reset. One or more watchdog resets within 10 minutes indicate that the system was forced to reset due to a serious software failure. The action for this rule is to execute an L3 alert and report it immediately. The root cause label for the second sub-rule is 0x40, watchdog-triggered anomaly.

[0082] The third sub-rule states that when volatility increases, cellular signal strength is greater than or equal to a second preset strength threshold, and memory occupancy increases monotonically across multiple consecutive sampling intervals with an increase exceeding a preset threshold, it is attributed to a memory leak-type sub-health condition, and the verification is passed. The second preset strength threshold is specifically... 90dBm, with a preset amplitude of 3%. In this rule, the cellular signal strength condition is used to exclude the impact of network issues on memory usage. A continuous monotonically increasing memory usage rate across multiple sampling intervals, with a cumulative increase exceeding 3%, indicates a sustained growth trend in system memory resources, meaning that memory allocation has not been fully released, resulting in a memory leak. Memory leaks lead to a gradual decrease in available memory, potentially triggering frequent garbage collection or memory allocation failures, thus increasing response latency volatility. The action taken when this rule is triggered is to execute an L2 alert and trigger a snapshot freeze. The root cause label for the third sub-rule is 0x20, indicating a memory leak-related sub-health condition.

[0083] The fourth sub-rule attributes an increase in volatility, a cellular signal strength greater than or equal to a second preset strength threshold, and a message retransmission rate greater than a preset retransmission rate to a protocol stack or driver anomaly, and passes verification. The preset retransmission rate is 5%. In this rule, the cellular signal strength condition is also used to exclude the impact of network problems on the retransmission rate. If the message retransmission rate consistently exceeds 5% even with a good cellular signal, it indicates an anomaly in data transmission between the vehicle terminal and the base station, possibly stemming from a protocol stack state anomaly or an underlying communication driver anomaly. The action taken when this rule is triggered is to execute an L2 response and trigger a snapshot freeze. The root cause label for the fourth sub-rule is 0x50, indicating a protocol stack or driver anomaly.

[0084] The fifth sub-rule, when volatility increases and the bus load rate is less than the preset load rate while the CPU utilization rate is greater than the preset utilization rate, attributes the increase to software resource conflicts or task scheduling anomalies, and the verification passed. The preset load rate is specifically 80%, and the preset utilization rate is specifically 85%. In this rule, a CPU utilization rate exceeding 85% indicates that the system's computing resources are under high load, and task scheduling may experience delays due to resource contention. The bus load rate condition is used to exclude busy vehicle bus communication as a cause of increased response latency—when the bus load rate is below 80%, there is no communication congestion on the bus itself, therefore the increased response latency should be attributed to software resource conflicts or task scheduling anomalies within the vehicle terminal. The action taken when this rule is triggered is to execute an L2 warning and trigger a snapshot freeze. The root cause label for the fifth sub-rule is 0x30, software resource conflicts or task scheduling anomalies.

[0085] The sixth sub-rule attributes performance degradation caused by thermal throttling when volatility increases and the chip junction temperature is greater than or equal to a preset junction temperature. This has been verified. The preset junction temperature is 80°C. When the chip junction temperature reaches 80°C or higher, the chip's internal temperature protection mechanism may trigger throttling to reduce power consumption and heat generation. Throttling leads to a decrease in processor processing speed, longer task execution time, and may cause increased response latency volatility. The action taken when this rule is triggered is to execute an L1 warning and provide a thermal alert. The root cause label for the sixth sub-rule is 0x60: thermal throttling causing performance degradation.

[0086] Furthermore, to prevent the same abnormal event from being repeatedly reported within a short period, causing cloud message congestion and wasting storage resources, this application embodiment stipulates that the same root cause tag is only reported once within the debouncing window (default 60 seconds). If an abnormal event of the same root cause tag is repeatedly triggered within the debouncing window, the system only retains the first report, and subsequent triggers within the window will not be reported repeatedly. The debouncing and rate limiting rules avoid the same abnormal event being repeatedly reported in a short period, reducing communication resource consumption and cloud storage pressure.

[0087] In the embodiments of the present application, the root cause label points the abnormality cause to a specific category, providing actionable positioning information for troubleshooting and handling by remote operation and maintenance personnel. Each rule uses both the volatility increase condition and at least one auxiliary state parameter condition in combination, and a hit is determined only when both are satisfied, eliminating false alarms caused by instantaneous abnormality of a single parameter.

[0088] Step S4: Determine the corresponding warning level according to the preset grading interval where the deviation ratio is located, determine the warning strategy according to the root cause label, construct a corresponding warning message, and report it to the cloud.

[0089] In the embodiments of the present application, determining the corresponding warning level according to the preset severity level interval where the deviation ratio falls in step S4 includes: when the deviation ratio is in the first preset interval and lasts longer than the duration threshold, determining it as the first sub-health warning level; when the deviation ratio is in the second preset interval and lasts longer than the duration threshold, determining it as the second sub-health warning level; when the deviation ratio is in the third preset interval and lasts longer than the duration threshold, determining it as the third sub-health warning level; when the deviation ratio is in the third preset interval and lasts longer than the upgrade time threshold, upgrading to the formal fault mode and writing it into the fault history.

[0090] Specifically, with reference to Table 1, the first preset interval is k1≤r<k2, the second preset interval is k2≤r<k3, and the third preset interval is r≥k3. Step S4 is configured to determine the warning level corresponding to the current sub-health state according to the preset severity level interval where the deviation ratio calculated in step S2 falls, in combination with the duration condition, and execute the corresponding response according to the warning level. The root cause label output by the root cause identification process in step S3 and the warning level determined in step S4 jointly determine the final warning strategy. The final reporting strategy is determined jointly by the warning level and the root cause label, for example: when the root cause label 0x10 (network degradation) is matched with the second sub-health warning level, the alarm is suppressed; when the root cause label 0x40 (watchdog trigger) is matched with the third sub-health warning level, the alarm is reported immediately.

[0091] A data message actively constructed by the vehicle-mounted terminal and sent to the cloud, configured to report relevant information of the current sub-health state to the remote operation and maintenance system. The message contains the following fields: timestamp, deviation ratio, root cause label, scene context, and CRC-16 (16-bit cyclic redundancy check code).

[0092] In the embodiments of the present application: each scenario bucket shields early warning output and does not calculate the deviation ratio during the initialization learning period. The learning period independently accumulates the valid sampling time for each scenario bucket, and each scenario bucket independently enters the working period after reaching the learning period; during the working period, each scenario bucket performs exponentially weighted moving average update of the baseline value based on samples that do not trigger the sub-health determination, and samples that have triggered the determination do not participate in the baseline update; wherein, when it is detected that the variation amplitude of the volatility baseline value of any scenario bucket within a preset time window exceeds a preset variation amplitude, the volatility baseline value of this scenario bucket is determined to be abnormal, the volatility baseline value of this scenario bucket is rolled back to the factory default baseline value, and the scenario bucket re-enters the learning period.

[0093] Specifically, each scenario bucket is in the initialization learning period when it enters the use state for the first time (including the first factory installation of the vehicle-mounted terminal, restart after long-term power failure, or first activation after OTA upgrade of a major software version), and the default duration of the learning period is 300 seconds. During the learning period, this scenario bucket performs the following operations: collect response delay samples, and continuously update the sliding estimates of the mean value and the volatility baseline value in the bucket; do not calculate the deviation ratio, do not output any early warning, and do not trigger snapshot freezing. The learning period independently accumulates the valid sampling time for each scenario bucket. Specifically, each scenario bucket maintains a timer respectively, and the timer of this bucket only accumulates when a valid sample is collected under the (vehicle running state, network signal level) condition corresponding to this scenario bucket. After each bucket reaches the duration of the learning period, each bucket independently enters the working period, which is irrelevant to the states of other buckets.

[0094] During the working period, each scenario bucket decides whether to use the current sample for baseline update according to whether the current sample triggers the sub-health determination. When the deviation ratio r<k1 (that is, the first sub-health warning level and above warnings are not triggered), the current sample is determined as a normal sample, and is used for the exponentially weighted moving average update of the volatility baseline value of the corresponding scenario bucket. When the deviation ratio r≥k1, the current sample is determined as a sub-health sample, and does not participate in the update of the volatility baseline value of the corresponding scenario bucket. The contribution of this sample to the baseline value is discarded. During the working period, the system continuously monitors the stability of the volatility baseline value of each scenario bucket. When it is detected that the variation amplitude of any scenario bucket within a preset time window exceeds the preset variation amplitude, the volatility baseline value of this scenario bucket is determined to be abnormal. After the baseline abnormality is detected, the system performs the following self-healing operations: roll back the volatility baseline value of this scenario bucket to the factory default baseline value; make this scenario bucket re-enter the learning period, and re-collect normal samples to establish a baseline; at the same time, report the baseline abnormality event to the cloud, and notify remote operation and maintenance personnel to pay attention to the state of this scenario bucket. The allowable ranges and default values of each parameter are shown in Table 4 below.

[0095]

[0096] Table 4. Allowable ranges and default values ​​for each parameter. Figure 3 This is a diagram illustrating the overall architecture of the vehicle-mounted terminal operation risk identification system provided in this application embodiment. Figure 3 As shown, the system consists of a data acquisition module, a volatility calculation module, an adaptive benchmark comparison module, a multidimensional root cause identification module, and a hierarchical reporting module on the vehicle terminal. The data acquisition module acquires the response delay sequence and auxiliary state parameters. The response delay sequence is used by the volatility calculation module to calculate the real-time volatility. The adaptive benchmark comparison module reads the volatility baseline value from a preset scenario bucket based on the current vehicle operating status and network signal conditions and calculates the deviation ratio. When the deviation ratio exceeds a preset threshold and continues to exceed a preset duration, the multidimensional root cause identification module matches the auxiliary state parameters and outputs a root cause label. The hierarchical reporting module determines the warning level based on the deviation ratio and determines the warning strategy based on the root cause label, constructs a warning message, and actively reports it to the cloud. At L2 and above levels, a snapshot freeze is triggered and sent along with the message.

[0097] Figure 4 This diagram illustrates the pre-fault snapshot double buffering and token bucket rate limiting mechanism provided in this application embodiment. Figure 4 As shown, the left side illustrates a dual-buffered rolling maintenance mechanism. Buffer A and Buffer B are written alternately, continuously maintaining rolling data for nearly 60 seconds. When an L2 or L3 alert is triggered, the current buffer block is immediately frozen, generating a snapshot handle (including address, timestamp, and sequence number). The handle is reported along with the alert message, and writing continues to the other buffer block. If no alert is triggered, data continues to be overwritten. The right side illustrates a token bucket rate limiting mechanism. The token bucket initially has a capacity of 3 tokens and resets every 24 hours. When an L2 or L3 snapshot trigger request arrives, if the token bucket has spare capacity, 1 token is consumed to perform a full snapshot freeze. If the token bucket is exhausted, the snapshot data for this round is discarded, and only event metadata is recorded to prevent frequent erasures and writes from shortening the lifespan of the Flash memory.

[0098] Furthermore, according to Table 1, the L1 warning mentioned in this application can be understood as the first sub-health warning level, the L2 warning as the second sub-health warning level, and the L3 warning as the third sub-health warning level.

[0099] In this embodiment, the following pseudocode provides a complete decision-making process from response delay sample input to warning output, which can be directly used as a logical reference for embedded implementation: FUNCTION on_response_sample(t_new, now_ms): / / Step 1: Extreme Value Clipping IF |t_new - μ_t|>3×σ_t AND t_new>30000ms THEN extreme_counter++; RETURN / / Not entering the window / / Step 2: Update volatility σ_t = welford_update(t_new) / / / / Step 3: Read the current scenario baseline bucket = get_bucket(vehicle_state, network_bin(RSRP)) IF bucket.state == LEARNING THEN bucket.update_learning(σ_t); RETURN / / Learning period: No alert / / Step 4: Calculate the deviation ratio r = σ_t / bucket.σ_b / / Step 5: Level classification + Duration constraint IF r<k1(1.5) THEN level = NORMAL bucket.ewma_update(σ_t) / / Normal samples participate in baseline update RETURN ELSE IF r<k2(3.0) THEN level = L1 ELSE IF r<k3(5.0) THEN level = L2 ELSE level = L3 IF dwell_duration(now_ms)<T_dwell(5s) THEN RETURN / / Wait / / Step 6: Multi-dimensional root cause identification (executed according to the priority table) cause = root_cause_infer(aux_channels) / / IF cause == NETWORK_DEGRADATION THEN RETURN / / Suppress / / Step 7: Debounce check IF same_cause_within(ΔT=60s) THEN local_log(); RETURN / / Step 8: Snapshot Freeze (L2+) IF level>= L2 AND token_bucket.acquire() THEN snap_id = snapshot.freeze(now_ms) / / Step 9: Construct and send the message msg = build_alert(level, cause, σ_t, bucket.σ_b, r, snap_id) send(msg, carrier=UDS|J1939|MQTT) / / Step 10: Abnormal samples are not included in baseline updates (to prevent contamination) / / (bucket.ewma_update is not called here) Figure 5 This is an end-to-end flowchart of an embodiment of the active warning system for driving conditions provided in this application. See also: Figure 5 In one specific embodiment, the application scenario is as follows: the vehicle is in motion, and the network signal is strong. A software resource conflict or task scheduling anomaly occurs in a high-priority task within the vehicle terminal, resulting in a change in the standard deviation of the response latency sequence. The response latency volatility is showing a slow upward trend, but the absolute value of the response latency has not yet reached the traditional timeout threshold.

[0100] Step 1: The vehicle terminal retrieves request-response pairs of service messages at the application layer and records response latency samples for each interaction. The Welford incremental algorithm is used to maintain the sample standard deviation of the response delay sequence within a sliding window (window size N is set to 10 samples by default). , which serves as the volatility characteristic value at the current moment.

[0101] Step 2: Based on the current vehicle operating status (driving state) and network signal conditions (strong signal), construct a tuple and read the volatility baseline value corresponding to the scenario from the persistent baseline bucket. and mean baseline value Calculate the deviation ratio r.

[0102] Step 3: When the deviation ratio r reaches the lower limit of the second preset interval (i.e., r ≥ k2 = 3.0) and the duration exceeds Candidate alerts are generated after 5 seconds (default).

[0103] Step 4: Perform root cause identification in combination with auxiliary state parameters. In this scenario, the cellular signal strength RSRP is stabilized in the strong signal range, and the bus load rate is stable (lower than the preset load rate threshold of 80%), and the CPU usage rate increases significantly (exceeding the preset usage rate threshold of 85%). According to the fifth sub-rule in the root cause identification rules (root cause label 0x30), it is determined that the current abnormality is attributed to software resource conflict or task scheduling abnormality, the verification is passed, and the root cause label 0x30 is output.

[0104] Step 5: According to that the deviation ratio r=3.25 falls into the second preset interval (k2≤r<k3), and the duration has exceeded , the warning level is determined as the second sub-health warning level. According to the handling action corresponding to the root cause label 0x30, the warning strategy is executed, a custom sub-health warning message is constructed and actively reported to the cloud, and a pre-fault snapshot freeze is triggered at the same time, so that the snapshot data is uploaded together with the warning message.

[0105] Numerical example: The current scenario volatility baseline value =80ms, the real-time volatility in a certain period =260ms, the deviation ratio r=260 / 80=3.25, the duration is 7 seconds, which triggers the warning of the second sub-health warning level. At this time, the absolute value of the response delay is up to about 800ms, which has not yet reached the traditional preset timeout threshold (typical value is 3000ms), but the present solution has completed the sub-health state determination and output the warning and root cause label within this period.

[0106] Figure 6 is a timing diagram for identifying memory leaks in the parking monitoring state provided by another embodiment of the present application. Referring to Figure 6 , in another specific embodiment, the application scenario is: the vehicle is in the parking monitoring state, and the vehicle-mounted terminal operates at a low load for more than 30 days for a long time. In this scenario, the traditional absolute threshold method cannot identify the risk — the absolute value of the response delay never reaches the preset timeout threshold, but the internal software of the vehicle-mounted terminal is already in a chronic resource depletion state, and continuous development will lead to battery power loss or passive system reset.

[0107] Step 1: Calculate the response delay volatility by using the exponentially weighted moving variance method, instead of the sliding window standard deviation used in the driving state. This method only needs to maintain the exponentially weighted mean and the exponentially weighted variance two state variables, without storing the historical response delay sample sequence, which meets the low storage overhead requirement of long-term operation in the parking monitoring state.

[0108] Step 2: Monitor the memory usage rate in parallel Samples are taken every 60 seconds. If there are K consecutive sampling intervals (K is set to 10 by default, corresponding to 10 minutes) within... If the memory usage continues to rise monotonically and the cumulative increase ΔU exceeds 5%, it is marked as having a memory growth trend.

[0109] Step 3: When the deviation ratio corresponding to the response latency volatility calculated in Step 1 exceeds the preset threshold and continues to exceed the preset duration, and the memory growth trend marked in Step 2 is also valid, according to the third sub-rule in the root cause identification rules (root cause label 0x20), it is determined that the current anomaly is attributed to memory leak type sub-health, the verification is successful, and the root cause label 0x20 is output.

[0110] Step 4: Determine the warning level based on the deviation ratio falling within the preset severity level range, and execute the warning strategy for the second sub-health warning level in conjunction with the action corresponding to root cause label 0x20, proactively report the warning message and trigger snapshot freeze. The snapshot contains a top-N list of task-level memory usage, used to locate the specific task or module with memory leaks in the cloud. If the memory usage rate... If the deviation ratio continues to rise to 90%, it will fall into the third preset range (r≥k3). The system will upgrade the warning level to the third sub-health warning level according to the upgrade and downgrade rules and immediately report it. The cloud can remotely trigger the vehicle terminal to self-heal and reset in order to avoid continuous memory consumption that could lead to battery depletion or system crash.

[0111] Figure 7 A state machine diagram of the cold start learning period and anti-pollution mechanism provided in another embodiment of this application. See also Figure 7 In another specific embodiment, the application scenarios are: initial installation of the vehicle terminal after leaving the factory, initial activation after the vehicle's EOL test, restart after a long power outage, or initial startup after a major software OTA upgrade. In this scenario, the vehicle terminal has not yet established any scenario-based volatility baseline value. If the environment in which the vehicle terminal is located during a cold start has adverse external conditions such as weak signal or abnormal base station conditions, there is a risk that samples under abnormal conditions will be learned into the baseline, causing the baseline to deviate from the normal level during the initialization phase. This embodiment corresponds to the engineering implementation of the baseline anti-pollution triple mechanism in the adaptive baseline for this scenario.

[0112] Step 1: After the vehicle terminal detects cold start conditions such as first activation, power failure recovery, or first startup after OTA, all 12 scene buckets enter the initialization learning period. The learning period duration is accumulated independently by bucket—after the cumulative effective sampling time of each scene bucket reaches T0 (default 300 seconds), the scene bucket ends its own learning period and enters the working period, regardless of the state of other scene buckets.

[0113] Step 2: During the learning period, the scene bucket only performs baseline initialization sampling and continuously updates the mean baseline value within the bucket. and volatility baseline value The sliding estimate is used. During the learning period, the deviation ratio is not calculated, no warnings are output, and snapshot freeze is not triggered, thus avoiding false alarms during the cold start phase when the baseline has not yet been established.

[0114] Step 3: After the learning period, the scene bucket enters the working period. The rule for updating the exponentially weighted moving average of the baseline value is: the sample only participates in the baseline value of the corresponding scene bucket if the current sample has not triggered the sub-health judgment (i.e., the deviation ratio r is lower than the first threshold k1). and volatility baseline value The EWMA iteration is performed; if a sample has been determined to be in a sub-healthy state (deviation ratio r reaches or exceeds k1), the contribution of the sample to the baseline value is discarded to avoid abnormal samples being learned into the baseline, which would lead to a decrease in the sensitivity of subsequent similar abnormalities.

[0115] Step 4: Each of the 12 scene buckets independently performs the state transition between the learning and working periods. After a cold start, the vehicle may first activate in the underground parking garage (parking listening state - weak signal scene bucket enters the learning period), then drive out to the surface (driving state - strong signal scene bucket enters the learning period), and then enter the tunnel (driving state - weak signal scene bucket enters the learning period). Each scene bucket goes through the learning period and enters the working period one by one in the order of its first access time, without interfering with each other; the cloud can view the learning status and the number of learned samples of each scene bucket through the reported information.

[0116] Step 5: During the working period, the system continuously monitors the stability of the volatility baseline value of each scenario bucket. If the volatility baseline value of a certain scenario bucket... If the change exceeds the preset change range (default 50%) within a preset time window (default 10 minutes), the baseline value of the scenario bucket is determined to be abnormal, marked as untrustworthy, the volatility baseline value of the bucket is rolled back to the factory default baseline value, and the baseline abnormality event is reported to the cloud. The scenario bucket then re-enters the initialization learning period.

[0117] Numerical Example: The vehicle-mounted terminal is first activated in an underground parking lot after leaving the factory. The "Parked Listening State - Weak Signal" scenario bucket enters a 300-second learning period, during which no warnings are generated. After the vehicle leaves the parking lot, the baseline of this scenario bucket is ready for learning. When the vehicle switches to the "Driving State - Strong Signal" scenario, the latter enters a new 300-second learning period. On the 7th day, while the user's vehicle is parked in the underground garage of the residential area, a suspected memory leak occurred in the vehicle-mounted terminal. (From 35% to 78%), real-time volatility The corresponding deviation ratio r = 4.2, exceeding the duration threshold, triggers the second sub-health warning level. The key to this embodiment is that the abnormal sample does not participate in the EWMA baseline update of the "Parking Monitoring State - Weak Signal" scenario bucket; therefore, the volatility baseline value of this scenario bucket... The value will not increase due to this abnormal event, and subsequent similar abnormalities can still be identified and judged with the same sensitivity based on the original baseline value.

[0118] This application embodiment calculates the volatility of the response delay sequence and monitors its deviation from the benchmark. This allows for the detection of abnormal changes in system state before the absolute values ​​of performance indicators deteriorate significantly, thus enabling risk identification during the transition phase before a failure occurs. This application embodiment further verifies the deviation ratio according to preset root cause identification rules by performing multi-dimensional verification after the deviation ratio exceeds a preset threshold and persists for a preset duration. Only after successful verification is the system determined to be in a sub-healthy state and a root cause label is output. This distinguishes whether the performance anomaly originates from the device itself or changes in the external environment, reducing false positives. This application embodiment calculates the deviation ratio by reading the volatility baseline value from the corresponding preset scenario bucket based on the current vehicle operating status and network signal conditions. Different operating scenarios use their own independent baseline values, allowing the judgment benchmark to adaptively adjust with changes in the device's operating environment, avoiding false positives or false negatives due to environmental differences. This application embodiment, through the setting of preset graded intervals, can distinguish different degradation stages and output corresponding warning levels, enabling the system to perceive and respond to performance degradation during the transition process.

[0119] Secondly, embodiments of this application also provide an operational risk identification device for an in-vehicle terminal.

[0120] In one embodiment, reference is made to Figure 8 , Figure 8 This is a schematic diagram of the functional modules of the vehicle-mounted terminal operation risk identification device provided in an embodiment of this application. Figure 8 As shown, the vehicle-mounted terminal's operational risk identification device includes: The acquisition module is used to acquire the response delay sequence of internal business messages of the vehicle terminal in real time and calculate the volatility of the response delay sequence. The calculation module is used to read the corresponding volatility baseline value from the preset scenario bucket according to the current vehicle operating status and network signal conditions, and calculate the deviation ratio of volatility relative to the volatility baseline value. The attribution module is used to verify the root cause identification rules according to the preset root cause identification rules when the deviation ratio exceeds the preset threshold and continues to exceed the preset duration. After the verification is passed, the vehicle terminal is determined to have entered a sub-healthy state and the corresponding root cause label is output. The early warning module is used to determine the corresponding early warning level based on the preset grade range where the deviation ratio is located, determine the early warning strategy based on the root cause label, construct the corresponding early warning message and report it to the cloud.

[0121] The functions of each module in the above-mentioned vehicle terminal operation risk identification device correspond to the steps in the above-mentioned vehicle terminal operation risk identification method embodiment, and their functions and implementation processes will not be described in detail here.

[0122] Thirdly, this application provides an operational risk identification device for a vehicle terminal. The operational risk identification device for a vehicle terminal includes a processor, a memory, and an operational risk identification program for the vehicle terminal stored in the memory and executable by the processor. When the operational risk identification program for the vehicle terminal is executed by the processor, it implements the steps of the operational risk identification method for the vehicle terminal as described in any of the above embodiments.

[0123] The operational risk identification device for the vehicle terminal can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0124] Reference Figure 9 , Figure 9 This is a schematic diagram of the hardware structure of the vehicle-mounted terminal operation risk identification device involved in the embodiments of this application. In this embodiment, the vehicle-mounted terminal operation risk identification device may include a processor, a memory, a communication interface, and a communication bus.

[0125] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0126] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the vehicle-mounted terminal's operational risk identification device, as well as interfaces used for interconnecting the vehicle-mounted terminal's operational risk identification device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0127] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0128] The processor can be a general-purpose processor, which can call the vehicle terminal's operational risk identification program stored in the memory and execute the vehicle terminal's operational risk identification method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle terminal's operational risk identification program is called can refer to the various embodiments of the vehicle terminal's operational risk identification method of this application, and will not be repeated here.

[0129] Those skilled in the art will understand that Figure 9 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0130] Fourthly, embodiments of this application provide a computer-readable storage medium storing a vehicle-mounted terminal operation risk identification program, wherein when the vehicle-mounted terminal operation risk identification program is executed by a processor, it implements the steps of the vehicle-mounted terminal operation risk identification method as described in any of the above embodiments.

[0131] The present application provides a computer-readable storage medium storing a vehicle terminal operation risk identification program, wherein when the vehicle terminal operation risk identification program is executed by a processor, it implements the steps of the vehicle terminal operation risk identification method described above.

[0132] The method implemented when the vehicle terminal's operational risk identification program is executed can be referred to in various embodiments of the vehicle terminal's operational risk identification method of this application, and will not be repeated here.

[0133] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0134] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0135] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0136] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0137] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0139] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for identifying operational risks of an in-vehicle terminal, characterized in that, The method for identifying operational risks of the vehicle-mounted terminal includes: The response delay sequence of internal service messages of the vehicle terminal is acquired in real time, and the volatility of the response delay sequence is calculated. Based on the current vehicle operating status and network signal conditions, the corresponding volatility baseline value is read from the preset scenario bucket, and the deviation ratio of the volatility relative to the volatility baseline value is calculated. When the deviation ratio exceeds a preset threshold and continues to exceed a preset duration, verification is performed according to the preset root cause identification rules. After the verification is passed, the vehicle terminal is determined to have entered a sub-healthy state and the corresponding root cause label is output. The corresponding warning level is determined based on the preset grade range in which the deviation ratio is located, and the warning strategy is determined based on the root cause label. The corresponding warning message is then constructed and reported to the cloud.

2. The method for identifying operational risks of an on-board terminal according to claim 1, characterized in that, The calculation of the volatility of the response delay sequence includes: The response delay sequence is maintained within a sliding window, and the statistics of the samples within the window are updated in real time using the Welford incremental algorithm. The sample standard deviation of the response delay sequence is calculated within the sliding window, specifically as follows: in, This represents the current standard deviation, which is equivalent to volatility. This represents the sum of squared deviations accumulator. This indicates the number of samples currently in the sliding window; Specifically, when a new response delay sample is enqueued, the number of samples, mean, and sum of squared deviations accumulator within the sliding window are updated, as follows: in, This indicates the deviation of the current sample from the mean before the update. This represents a new sample of response delay. This represents the mean before the update. This represents the updated mean. This indicates the deviation of the current sample from the updated mean. This represents the updated sum of squared deviations accumulator. This represents the sum of squared deviations accumulator before the update; When the sliding window is full and new response latency samples are enqueued, the oldest sample needs to be removed. A dequeue update is then performed, specifically: in, This indicates the number of samples after dequeueing. This represents the difference between the oldest sample and the mean before removal. This represents the oldest sample.

3. The method for identifying operational risks of an on-board terminal according to claim 2, characterized in that, The calculation of the volatility of the response delay sequence further includes: When the vehicle terminal is in a parked monitoring state, based on the response latency sample at the current moment, the exponentially weighted mean at the previous moment, and the exponentially weighted variance at the previous moment, the exponentially weighted mean and exponentially weighted variance at the current moment are calculated, specifically as follows: The volatility at the current moment is calculated based on the index-weighted variance, specifically as follows: in, Represents the smoothing coefficient. This represents the exponentially weighted average at the current moment. This represents the exponentially weighted average of the previous time step. This represents the exponentially weighted variance at the previous time step.

4. The method for identifying operational risks of an on-board terminal according to claim 2, characterized in that, The step of reading the corresponding volatility baseline value from a preset scenario bucket based on the current vehicle operating status and network signal conditions, and calculating the deviation ratio of the volatility relative to the volatility baseline value, includes: The vehicle status category is determined based on the current vehicle operating status, and the network signal level is determined based on the current cellular signal strength. The combination of these factors yields the current scene bucket index. Read the corresponding volatility baseline value from the current scenario bucket, and calculate the deviation ratio of the volatility relative to the volatility baseline value, specifically: in, Indicates the deviation ratio. This represents the baseline value of volatility.

5. The method for identifying operational risks of an on-board terminal according to claim 2, characterized in that, The verification is performed according to preset root cause identification rules. After successful verification, the vehicle terminal is determined to be in a sub-healthy state, and the corresponding root cause label is output, including: Collect auxiliary status parameters, which include at least cellular signal strength, CPU utilization, memory utilization, bus load rate, message retransmission rate, watchdog reset count increment, and chip junction temperature; Based on the auxiliary state parameters, the first, second, third, fourth, fifth, and sixth sub-rules of the preset root cause identification rules are executed sequentially. The process stops when a root cause is hit and the corresponding root cause label is output. The first sub-rule is that when the volatility increases and the cellular signal strength is less than the first preset strength threshold, it is attributed to external network degradation, the verification fails, and a suppression warning is issued. The second sub-rule is that when volatility increases and the increase in the number of watchdog resets within a preset time period is greater than or equal to the preset increment, it is attributed to a watchdog-triggered anomaly, and the verification is passed. The third sub-rule is that when the volatility increases and the cellular signal strength is greater than or equal to the second preset strength threshold, and the memory occupancy rate increases monotonically for multiple consecutive sampling intervals and the increase exceeds the preset range, it is attributed to memory leak-type sub-health, and the verification is passed. The fourth sub-rule is that when the volatility increases and the cellular signal strength is greater than or equal to the second preset strength threshold and the message retransmission rate is greater than the preset retransmission rate, it is attributed to a protocol stack or driver abnormality, and the verification is passed. The fifth sub-rule states that when volatility increases and bus load rate is less than preset load rate while CPU utilization is greater than preset utilization rate, the cause is attributed to software resource conflict or task scheduling anomaly, and the verification is passed. The sixth sub-rule states that when volatility increases and the chip junction temperature is greater than or equal to the preset junction temperature, the performance degradation is attributed to thermal throttling, and the verification is passed. If the preset root cause identification rule is not matched, it is marked as unclassified, verified and reported to the cloud.

6. The method for identifying operational risks of an on-board terminal according to claim 2, characterized in that, The step of determining the corresponding warning level based on the preset severity level range into which the deviation ratio falls includes: When the deviation ratio is within the first preset range and continues to exceed the duration threshold, it is determined to be the first sub-health warning level; When the deviation ratio is within the second preset range and continues to exceed the duration threshold, it is determined to be the second sub-health warning level; When the deviation ratio is within the third preset range and continues to exceed the duration threshold, it is determined to be the third sub-health warning level; When the deviation ratio is in the third preset range and continues to exceed the upgrade time threshold, it is upgraded to a formal fault mode and written into the fault history.

7. The method for identifying operational risks of an on-board terminal according to claim 2, characterized in that: During the initial learning period, each scene bucket disables the warning output and does not calculate the deviation ratio. The learning period is calculated by accumulating the effective sampling time independently for each scene bucket. After each scene bucket reaches the learning period, it independently enters the working period. During the working period, each scenario bucket updates the baseline value using an exponentially weighted moving average based on samples that have not triggered the sub-health assessment. Samples that have triggered the assessment do not participate in the baseline update. Specifically, when it is detected that the volatility baseline value of any scenario bucket changes by more than a preset amount within a preset time window, the volatility baseline value of that scenario bucket is determined to be abnormal, the volatility baseline value of that scenario bucket is reverted to the factory default baseline value, and the learning period is restarted.

8. A vehicle-mounted terminal operation risk identification device, characterized in that, The operational risk identification device of the vehicle terminal includes: The acquisition module is used to acquire the response delay sequence of internal service messages of the vehicle terminal in real time and calculate the volatility of the response delay sequence. The calculation module is used to read the corresponding volatility baseline value from the preset scenario bucket according to the current vehicle operating status and network signal conditions, and calculate the deviation ratio of the volatility relative to the volatility baseline value; The attribution module is used to verify the root cause identification rule according to the preset root cause identification rule when the deviation ratio exceeds the preset threshold and continues to exceed the preset time. After the verification is passed, the vehicle terminal is determined to enter a sub-healthy state and the corresponding root cause label is output. The early warning module is used to determine the corresponding early warning level based on the preset grade range in which the deviation ratio is located, determine the early warning strategy based on the root cause label, construct the corresponding early warning message, and report it to the cloud.

9. A vehicle-mounted terminal operation risk identification device, characterized in that, The vehicle terminal operation risk identification device includes a processor, a memory, and a vehicle terminal operation risk identification program stored in the memory and executable by the processor, wherein when the vehicle terminal operation risk identification program is executed by the processor, it implements the steps of the vehicle terminal operation risk identification method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an operational risk identification program for a vehicle-mounted terminal, wherein when the operational risk identification program for the vehicle-mounted terminal is executed by a processor, it implements the steps of the operational risk identification method for a vehicle-mounted terminal as described in any one of claims 1 to 7.

Images