A method and apparatus for handling abnormal operation of vehicle-mounted TBOX terminals.

Abstract

This application provides a method and apparatus for handling abnormal operation of a vehicle-mounted TBOX terminal. The method includes: receiving a request signal from a multi-source wake-up source after filtering; determining a corresponding operation status evaluation rule based on the attribute parameters of the request signal, and analyzing the request signal using the operation status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally; if not, acquiring real-time monitoring data under each pre-set multi-dimensional evaluation index, and performing real-time data comparison and abnormal pattern recognition based on a built-in abnormal evaluation rule library to determine the current abnormal alarm information of the vehicle-mounted TBOX terminal; determining a processing strategy corresponding to the determined abnormal alarm information based on the determined abnormal alarm information, and executing the determined processing strategy according to a progressive fault recovery mechanism until the vehicle-mounted TBOX terminal operates normally.

Description

Technical Field

[0001] This application relates to the field of vehicle anomaly handling technology, and in particular to a method and apparatus for handling abnormal operation of vehicle-mounted TBOX terminals. Background Technology

[0002] As a core component of the vehicle-to-everything (V2X) system, the in-vehicle telematics box (TBOX) undertakes key functions such as data communication, remote control, and fault diagnosis between the vehicle and the cloud platform and mobile app. With the continuous improvement of vehicle intelligence and connectivity, the operational stability and power consumption management level of the TBOX directly affect the user experience and electrical system reliability of the entire vehicle.

[0003] Currently, existing vehicle-mounted TBOX terminals typically use a single wake-up signal (such as a GPS signal or a CAN bus signal) for wake-up. This wake-up mechanism is prone to failure when the signal fails or is interfered with, preventing the TBOX terminal from being woken up properly. Furthermore, the sleep threshold of the TBOX is often a fixed value, which cannot adapt to dynamic changes in network status and data traffic under different operating conditions, potentially causing unnecessary sleep or wake-up, affecting system performance and increasing the vehicle's static power consumption. In addition, existing fault diagnosis mechanisms are not perfect, making it difficult to identify and locate the root cause of abnormal sleep or wake-up in a timely manner, thus prolonging fault handling time. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method and apparatus for handling abnormal operation of vehicle-mounted TBOX terminals, which can effectively solve the defects of low wake-up reliability, poor sleep adaptability and slow fault location in the prior art.

[0005] This application provides a method for handling abnormal operation of a vehicle-mounted TBOX terminal, the method including: Receive the filtered request signal from the multi-source wake-up source; Based on the attribute parameters of the request signal, the corresponding operation status evaluation rule is determined, and the operation status evaluation rule is used to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally. If not, based on the pre-set multi-dimensional evaluation indicators, obtain the real-time monitoring data under each evaluation indicator, and perform real-time data comparison and abnormal pattern recognition according to the built-in abnormal evaluation rule library to determine the abnormal alarm information of the current vehicle TBOX terminal. Based on the identified abnormal alarm information, a corresponding processing strategy is determined, and the determined processing strategy is executed according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

[0006] Optionally, after executing the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally, the processing method further includes: The abnormal event information, abnormal event diagnosis process information, abnormal event handling process information, and handling result information during this abnormal operation will be stored in the rule base; And update the weights of the corresponding processing strategies in the rule base based on the stored information.

[0007] Optionally, the attribute parameters include request mode type and signal type; the step of determining the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and using the operating status evaluation rule to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally includes: Based on the request mode type of the request signal, determine whether it is a wake-up request; If the signal is a wake-up request, based on the signal type, if the request signal is determined to be a pre-set signal with the highest priority, then the vehicle-mounted TBOX terminal is determined to be operating normally; or, if the request signal is not a pre-set signal with the highest priority, but there are at least a predetermined number of independent wake-up request signals with a continuous effective duration exceeding a set time, then the vehicle-mounted TBOX terminal is determined to be operating normally; otherwise, the vehicle-mounted TBOX terminal is determined to be operating abnormally; wherein, the predetermined number and the set time are dynamic values. If no wake-up request is made, and it is determined that all wake-up sources meet the sleep requirements based on the request signal, the vehicle TBOX terminal is determined to be operating normally; or, if the request signal includes a specified sleep instruction, the vehicle TBOX terminal is determined to be operating normally; otherwise, the vehicle TBOX terminal is determined to be operating abnormally.

[0008] Optionally, the multidimensional evaluation metrics include: wake-up response time, signal packet loss rate, CPU load, sleep process state, and communication module state machine.

[0009] Optionally, the abnormal alarm information includes: the type of abnormality, the cause of the fault, and the key monitoring data on which the abnormality is determined. The step of determining the abnormal alarm information of the current vehicle-mounted TBOX terminal by performing real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule base includes: When it is determined from real-time monitoring data that the wake-up time exceeds the threshold, the anomaly type is determined to be excessively long wake-up response time, and this real-time monitoring data is identified as critical monitoring data. When the number of wake-ups per unit time exceeds the preset number based on real-time monitoring data, the anomaly type is determined to be an abnormal increase in the number of wake-ups, and the real-time monitoring data is identified as critical monitoring data. When it is determined from real-time monitoring data that the vehicle has met the sleep conditions, but the vehicle TBOX terminal has not entered the specified low power state after the sleep command is issued for more than a preset time, the abnormality type is determined to be sleep timeout abnormality, and the real-time monitoring data is determined to be critical monitoring data. When it is determined from real-time monitoring data that the module's state remains unchanged for more than a preset time, the anomaly type is determined to be a communication module status freeze, and the real-time monitoring data is determined to be critical monitoring data. When the detected anomaly types are sleep timeout and communication module status freeze, the cause of the fault is determined to be communication module driver uninstallation anomaly. When an abnormal increase in the number of wake-ups is detected, and the corresponding wake-up is determined to be a network-side fake wake-up based on real-time monitoring data, the cause of the fault is determined to be a network fake wake-up attack.

[0010] Optionally, executing the determined processing strategy according to the progressive fault recovery mechanism includes: Set the handling strategy for forcibly uninstalling drivers or resetting specific software modules as the primary handling strategy and execute it first; The processing strategy for restarting the communication module hardware will be set to a medium-level processing strategy, which will be executed after the primary processing strategy fails to recover. The TBOX system will be restarted. The final processing policy will be set and executed if the intermediate processing policy fails to recover.

[0011] Optionally, updating the weights of the corresponding processing strategies in the rule base based on the stored information includes: The success rate of each processing strategy is determined based on the stored information and historical information in the database. For each processing strategy, the product of the success rate of the processing strategy and the basic weight coefficient is determined as the current weight of the processing strategy.

[0012] This application embodiment also provides a processing device for abnormal operation of a vehicle-mounted TBOX terminal, the processing device comprising: The receiving module is used to receive the request signal sent by the multi-source wake-up source after filtering. The first determining module is used to determine the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and to analyze the request signal using the operating status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally. The second determination module is used to determine the abnormal alarm information of the vehicle TBOX terminal if the vehicle TBOX terminal is operating abnormally, based on the pre-set multi-dimensional evaluation indicators, to obtain real-time monitoring data under each evaluation indicator, and to perform real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule library. The processing module is used to determine the processing strategy corresponding to the determined abnormal alarm information based on the determined abnormal alarm information, and execute the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

[0013] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the processing method described above are performed.

[0014] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the processing method described above.

[0015] This application provides a method and apparatus for handling abnormal operation of a vehicle-mounted TBOX terminal. The method includes: receiving a request signal from a multi-source wake-up source after filtering; determining a corresponding operation status evaluation rule based on the attribute parameters of the request signal, and analyzing the request signal using the operation status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally; if not, acquiring real-time monitoring data under each pre-set multi-dimensional evaluation index, and performing real-time data comparison and abnormal pattern recognition based on a built-in abnormal evaluation rule library to determine the current abnormal alarm information of the vehicle-mounted TBOX terminal; determining a processing strategy corresponding to the determined abnormal alarm information based on the determined abnormal alarm information, and executing the determined processing strategy according to a progressive fault recovery mechanism until the vehicle-mounted TBOX terminal operates normally. Thus, the technical solution of this application can achieve the following technical effects: First, this application solves the problem of communication modules getting stuck in the pre-sleep phase by forcibly uninstalling the driver as a targeted recovery operation, without requiring a restart of the module or the entire system. Furthermore, compared to resetting the module in existing technologies, the recovery operation in this application does not cause bus re-enumeration, does not wake up other modules, and does not affect the vehicle's sleep order. This reduces vehicle network wake-up events caused by module malfunctions and lowers static power consumption.

[0016] Secondly, this application can identify abnormal types that cannot be covered by existing technologies, such as pre-hibernation driver uninstallation jamming, through in-depth monitoring of the hibernation process status.

[0017] Third, the graded recovery mechanism of this application achieves targeted solutions: for driver layer blockage, driver unloading is used; for module hardware abnormality, module restart is used; and for system-level failure, system restart is used, thereby improving recovery efficiency and system stability.

[0018] Fourth, the database dynamic update mechanism of this application makes the system more and more accurate in identifying abnormal patterns under specific vehicle models and operating conditions, and optimizes the recovery strategy as the usage time increases.

[0019] Fifth, the multi-source wake-up + priority arbitration + threshold dynamic adjustment mechanism of this application ensures reliable wake-up of TBOX under various operating conditions and improves system reliability.

[0020] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a method for handling abnormal operation of an in-vehicle TBOX terminal provided in an embodiment of this application; Figure 2 This is one of the structural schematic diagrams of a processing device for abnormal operation of a vehicle-mounted TBOX terminal provided in an embodiment of this application; Figure 3 This is a second schematic diagram of a processing device for abnormal operation of a vehicle-mounted TBOX terminal provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0024] Existing vehicle-mounted TBOX terminals typically use a single wake-up signal, such as a GPS signal or a CAN bus signal, for activation. This wake-up mechanism is susceptible to failure or interference, preventing the TBOX terminal from waking up. Furthermore, fixed sleep thresholds fail to adapt to varying network conditions and data traffic, potentially causing unnecessary sleep or wake-up cycles and impacting system performance. Insufficient fault diagnosis mechanisms make it difficult to promptly identify and locate the causes of abnormal sleep or wake-up cycles, prolonging troubleshooting time.

[0025] Existing technology recovers from TBOX malfunctions by resetting the module. The reset operation interrupts the module's current state and reloads the firmware and drivers. During this process, the communication interface between the module and the main control chip is reinitialized, potentially generating bus activity (such as I2C, SPI, and USB re-enumeration). This often wakes up other related modules that are currently in sleep mode (such as the main control CPU and power management IC). If the entire vehicle is already in sleep mode at this time, this partial wake-up caused by the module reset disrupts the vehicle's sleep order, leading to the entire vehicle network being woken up, increasing static power consumption, and even triggering a chain reaction such as abnormal CAN network wake-up, affecting user experience and the stability of the vehicle's electrical system.

[0026] Furthermore, existing anomaly detection technologies primarily target network communication functions (such as IMS registration failure), addressing the issue of the TBOX failing to connect to the network. However, in practical applications, the TBOX exhibits another critical anomaly: the inability of the TBOX to properly hibernate. For example, the communication module may freeze during the pre-hibernation unloading driver phase of the hibernation process, preventing the module from entering low-power mode and consequently preventing the entire TBOX from completing hibernation. This type of anomaly does not manifest as network unavailability but rather as abnormal power consumption. Existing technologies fail to identify and handle such blocking anomalies in the hibernation process.

[0027] Furthermore, the existing solution employs a simplistic recovery strategy, resetting the module regardless of its abnormal state. While resetting the module might resolve the issue in the aforementioned hibernation / freeze scenario, it's an overreaction, as the reset operation restarts the entire module hardware, causing unnecessary power consumption and system disturbances.

[0028] This solution is a one-time anomaly detection and recovery method, lacking a mechanism for recording, analyzing, and learning from abnormal events. It cannot automatically optimize recovery strategies for frequent occurrences of the same type of anomalies, nor can it provide data support for subsequent system improvements.

[0029] Based on this, this application provides a method for handling abnormal operation of vehicle-mounted TBOX terminals, in order to solve the defects of low wake-up reliability, poor sleep adaptability, and slow fault location in the prior art.

[0030] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for handling abnormal operation of a vehicle-mounted TBOX terminal, as provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the processing method includes: S101, Receive the request signal sent by the multi-source wake-up source after filtering; S102. Based on the attribute parameters of the request signal, determine the corresponding operation status evaluation rule, and use the operation status evaluation rule to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally. S103. If not, according to the pre-set multi-dimensional evaluation indicators, obtain the real-time monitoring data under each evaluation indicator, and perform real-time data comparison and abnormal pattern recognition according to the built-in abnormal evaluation rule library to determine the abnormal alarm information of the current vehicle TBOX terminal. S104. Based on the determined abnormal alarm information, determine the processing strategy corresponding to the abnormal alarm information, and execute the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

[0031] The exemplary steps of the embodiments of this application are described below: For step S101, the multi-source wake-up sources in this step may specifically include: six independent wake-up signal sources: IG ON signal (hard wire), CAN message (network), vehicle towing signal (hard wire), internal system timer wake-up (internal), telephone / SMS wake-up (network), and cellular network signal (network).

[0032] Filtering specifically includes noise and glitch removal.

[0033] Regarding step S102, in one embodiment provided in this application, the attribute parameters include a request mode type and a signal type; the step of determining the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and using the operating status evaluation rule to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally includes: S1021. Determine whether it is a wake-up request based on the request mode type of the request signal; S1022. If it is a wake-up request, according to the signal type, if it is determined that the request signal is a pre-set signal with the highest priority, then it is determined that the vehicle TBOX terminal is operating normally; or, if it is determined that the request signal is not a pre-set signal with the highest priority, but there are at least a predetermined number of independent wake-up request signals with a continuous effective duration exceeding a set time, then it is determined that the vehicle TBOX terminal is operating normally; otherwise, it is determined that the vehicle TBOX terminal is operating abnormally; wherein, the predetermined number and the set time are dynamic values. S1023. If no wake-up request is made, and it is determined that all wake-up sources meet the sleep requirements based on the request signal, the vehicle TBOX terminal is determined to be operating normally; or, if the request signal includes a specified sleep instruction, the vehicle TBOX terminal is determined to be operating normally; otherwise, the vehicle TBOX terminal is determined to be operating abnormally.

[0034] For step S1021, the request mode type may specifically include requesting wake-up or requesting hibernation.

[0035] Regarding step S1022, the IG ON signal is set to have the highest priority. That is, when IG ON is active, it directly overrides all other signals to avoid multiple signal conflicts.

[0036] The predetermined quantity and set time are dynamic values. Specifically, they can be based on a sliding window to statistically analyze historical wake-up times, identifying peak periods, off-peak periods, and nighttime sleep modes. The wake-up threshold is dynamically adjusted according to the mode (e.g., increasing the threshold during peak periods to ensure response and decreasing the threshold during off-peak periods to save energy). Alternatively, the threshold can be updated periodically or based on specific events (low battery, idle).

[0037] The pre-order quantity can be set to 2, and the set time can be 50ms.

[0038] Regarding step S103, in one embodiment provided in this application, the multidimensional evaluation indicators include: wake-up response time, signal packet loss rate, CPU load, sleep process state, and communication module state machine.

[0039] Here, the real-time monitoring data for the multidimensional evaluation metrics can be determined by the low-power coprocessor (or the low-power domain of the MCU) mounted on the TBOX. This domain maintains low-power operation when the system is in sleep mode and independently monitors key signals and status.

[0040] Wake-up Response Time: The time from when the wake-up signal becomes valid to when the system fully starts up. Signal Packet Loss Rate: The proportion of heartbeat packets lost between the communication module and the network side. CPU Load: The load of the main control CPU under different operating states. Hibernation Process Status: Records the timing and time taken for each module to enter hibernation after the hibernation command is issued. Communication Module State Machine: Real-time acquisition of the module's current operating status (e.g., normal operation, pre-hibernation, driver unloading, low power consumption, etc.).

[0041] In addition, during data monitoring, information on all wake-up and sleep events is recorded, including: timestamp, trigger signal source and type, current threshold configuration, wake-up / sleep completion status, and time elapsed.

[0042] In another embodiment provided in this application, the abnormal alarm information includes: abnormality type, fault cause, and key monitoring data on which the abnormality is determined. The step of determining the abnormal alarm information of the current vehicle-mounted TBOX terminal by performing real-time data comparison and abnormal pattern recognition based on a built-in abnormality evaluation rule base includes: When it is determined from real-time monitoring data that the wake-up time exceeds the threshold, the anomaly type is determined to be excessively long wake-up response time, and this real-time monitoring data is identified as critical monitoring data. When the number of wake-ups per unit time exceeds the preset number based on real-time monitoring data, the anomaly type is determined to be an abnormal increase in the number of wake-ups, and the real-time monitoring data is identified as critical monitoring data. When it is determined from real-time monitoring data that the vehicle has met the sleep conditions, but the vehicle TBOX terminal has not entered the specified low power state after the sleep command is issued for more than a preset time, the abnormality type is determined to be sleep timeout abnormality, and the real-time monitoring data is determined to be critical monitoring data. When it is determined from real-time monitoring data that the module's state remains unchanged for more than a preset time, the anomaly type is determined to be a communication module status freeze, and the real-time monitoring data is determined to be critical monitoring data. When the detected anomaly types are sleep timeout and communication module status freeze, the cause of the fault is determined to be communication module driver uninstallation anomaly. When an abnormal increase in the number of wake-ups is detected, and the corresponding wake-up is determined to be a network-side fake wake-up based on real-time monitoring data, the cause of the fault is determined to be a network fake wake-up attack.

[0043] Regarding step S104, in one embodiment provided in this application, the execution of the determined processing strategy according to the progressive fault recovery mechanism includes: setting the processing strategy of forcibly uninstalling the driver or resetting a specific software module as a primary processing strategy and executing it first; setting the processing strategy of restarting the communication module hardware as an intermediate processing strategy and executing it after the primary processing strategy fails to recover; and setting the processing strategy of restarting the TBOX system as a final processing strategy and executing it after the intermediate processing strategy fails to recover.

[0044] Here, the driver uninstallation only targets the malfunctioning module and does not affect the hibernation state of other modules, avoiding the possibility of the entire vehicle system being woken up by a traditional restart. For example, if the communication module fails to hibernate, causing the entire TBOX to fail to hibernate, the troubleshooting program checks the communication module's operating status. If it is in the pre-hibernation driver uninstallation state, and the hibernation time is too long, it is determined that the communication module's driver uninstallation is malfunctioning. In this case, the module driver is forcibly uninstalled, and the system enters hibernation. This operation does not require a restart and the hibernation process can continue without affecting the hibernation of other modules. If a traditional restart operation is used, it will wake up other modules and then put them into hibernation, causing disorder in the entire vehicle's hibernation system and reducing the usability and comfort for end users.

[0045] Furthermore, in one embodiment provided in this application, after the determined processing strategy is executed according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally, the processing method further includes: storing abnormal event information, abnormal event diagnosis process information, abnormal event processing process information, and processing result information during this abnormal operation into a rule base; and updating the weight of the corresponding processing strategy in the rule base according to the stored information.

[0046] In one embodiment provided in this application, updating the weights of corresponding processing strategies in the rule base based on the stored information includes: determining the success rate of each processing strategy based on the stored information and historical information in the database; and determining the current weight of each processing strategy as the product of the success rate of the processing strategy and the basic weight coefficient.

[0047] For example, the weight optimization process can be illustrated through the following: The rule base assigns dynamic weights to each processing method based on historical recovery success rates. The calculation formula is: Weight = (Number of successful attempts / Total number of attempts) × Basic weight coefficient.

[0048] The rule base assigns weights to processing methods based on recovery success rates. When similar faults are encountered subsequently, the higher-weighted scheme is prioritized, and the system prioritizes the recovery scheme with the highest weight. For example, if a forced driver uninstallation succeeds 9 out of 10 times in the same type of anomaly (90% success rate), its weight is higher than that of the restart module with a 60% success rate. The system recalculates the weights of each strategy periodically (e.g., weekly) and fine-tunes them in real time based on newly generated fault data. This dynamic optimization mechanism enables: Reduce false positive rate: For occasional anomalies caused by certain environmental factors, recovery methods will not be blindly upgraded; To prevent repeated error triggering: For stubborn faults that cannot be resolved after multiple attempts, the system will reduce the weight of this strategy to avoid repeatedly executing invalid operations and consuming resources; Adaptive optimization: The recovery strategy can automatically adapt as software versions are updated or the usage environment changes.

[0049] Based on the same inventive concept, this application also provides a processing device corresponding to the processing method. Since the principle of the device in this application to solve the problem is similar to the processing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0050] Please see Figure 2 , Figure 3 , Figure 2 This is one of the structural schematic diagrams of a processing device for abnormal operation of an in-vehicle TBOX terminal provided in an embodiment of this application. Figure 3 This is a second schematic diagram of a processing device for abnormal operation of an in-vehicle TBOX terminal provided in an embodiment of this application. Figure 2 As shown, the processing device 200 includes: The receiving module 210 is used to receive the request signal sent by the multi-source wake-up source after filtering. The first determining module 220 is used to determine the corresponding operating status evaluation rule according to the attribute parameters of the request signal, and to analyze the request signal using the operating status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally. The second determining module 230 is used to determine the abnormal alarm information of the vehicle TBOX terminal if the vehicle TBOX terminal is operating abnormally, based on the pre-set multi-dimensional evaluation indicators, to obtain real-time monitoring data under each evaluation indicator, and to perform real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule library. The processing module 240 is used to determine the processing strategy corresponding to the determined abnormal alarm information based on the determined abnormal alarm information, and execute the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

[0051] Optional, such as Figure 3 As shown, the processing device 200 further includes a storage module 250, which is used for: After the determined processing strategy is executed according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally, the abnormal event information, abnormal event diagnosis process information, abnormal event processing process information and processing result information during this abnormal operation are stored in the rule base. And update the weights of the corresponding processing strategies in the rule base based on the stored information.

[0052] Optionally, the attribute parameters include request mode type and signal type; when the first determining module 220 determines the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and analyzes the request signal using the operating status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally, the first determining module 220 is used to: Based on the request mode type of the request signal, determine whether it is a wake-up request; If the signal is a wake-up request, based on the signal type, if the request signal is determined to be a pre-set signal with the highest priority, then the vehicle-mounted TBOX terminal is determined to be operating normally; or, if the request signal is not a pre-set signal with the highest priority, but there are at least a predetermined number of independent wake-up request signals with a continuous effective duration exceeding a set time, then the vehicle-mounted TBOX terminal is determined to be operating normally; otherwise, the vehicle-mounted TBOX terminal is determined to be operating abnormally; wherein, the predetermined number and the set time are dynamic values. If no wake-up request is made, and it is determined that all wake-up sources meet the sleep requirements based on the request signal, the vehicle TBOX terminal is determined to be operating normally; or, if the request signal includes a specified sleep instruction, the vehicle TBOX terminal is determined to be operating normally; otherwise, the vehicle TBOX terminal is determined to be operating abnormally.

[0053] Optionally, the multidimensional evaluation metrics include: wake-up response time, signal packet loss rate, CPU load, sleep process state, and communication module state machine.

[0054] Optionally, the abnormal alarm information includes: the type of abnormality, the cause of the fault, and the key monitoring data on which the abnormality is determined. When the second determining module 230 performs real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule library to determine the abnormal alarm information of the current vehicle TBOX terminal, the second determining module 230 is used to: When it is determined from real-time monitoring data that the wake-up time exceeds the threshold, the anomaly type is determined to be excessively long wake-up response time, and this real-time monitoring data is identified as critical monitoring data. When the number of wake-ups per unit time exceeds the preset number based on real-time monitoring data, the anomaly type is determined to be an abnormal increase in the number of wake-ups, and the real-time monitoring data is identified as critical monitoring data. When it is determined from real-time monitoring data that the vehicle has met the sleep conditions, but the vehicle TBOX terminal has not entered the specified low power state after the sleep command is issued for more than a preset time, the abnormality type is determined to be sleep timeout abnormality, and the real-time monitoring data is determined to be critical monitoring data. When it is determined from real-time monitoring data that the module's state remains unchanged for more than a preset time, the anomaly type is determined to be a communication module status freeze, and the real-time monitoring data is determined to be critical monitoring data. When the detected anomaly types are sleep timeout and communication module status freeze, the cause of the fault is determined to be communication module driver uninstallation anomaly. When an abnormal increase in the number of wake-ups is detected, and the corresponding wake-up is determined to be a network-side fake wake-up based on real-time monitoring data, the cause of the fault is determined to be a network fake wake-up attack.

[0055] Optionally, when the processing module 240 executes the determined processing strategy according to the progressive fault recovery mechanism, the processing module 240 is configured to: Set the handling strategy for forcibly uninstalling drivers or resetting specific software modules as the primary handling strategy and execute it first; The processing strategy for restarting the communication module hardware will be set to a medium-level processing strategy, which will be executed after the primary processing strategy fails to recover. The TBOX system will be restarted. The final processing policy will be set and executed if the intermediate processing policy fails to recover.

[0056] Optionally, when the storage module 250 updates the weights of the corresponding processing strategies in the rule base based on the stored information, the storage module 250 is used to: The success rate of each processing strategy is determined based on the stored information and historical information in the database. For each processing strategy, the product of the success rate of the processing strategy and the basic weight coefficient is determined as the current weight of the processing strategy.

[0057] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0058] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps in the method embodiment shown are specifically implemented in the method embodiment and will not be repeated here.

[0059] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 as well as Figure 2 The steps in the method embodiment shown are specifically implemented in the method embodiment and will not be repeated here.

[0060] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0061] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0062] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0064] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A processing method for abnormal operation of a vehicle-mounted TBOX terminal, characterized by, The processing method includes: Receive the filtered request signal from the multi-source wake-up source; Based on the attribute parameters of the request signal, the corresponding operation status evaluation rule is determined, and the operation status evaluation rule is used to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally. If not, based on the pre-set multi-dimensional evaluation indicators, obtain the real-time monitoring data under each evaluation indicator, and perform real-time data comparison and abnormal pattern recognition according to the built-in abnormal evaluation rule library to determine the abnormal alarm information of the current vehicle TBOX terminal. Based on the identified abnormal alarm information, a corresponding processing strategy is determined, and the determined processing strategy is executed according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

2. The processing method according to claim 1, characterized in that, After executing the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally, the processing method further includes: The abnormal event information, abnormal event diagnosis process information, abnormal event handling process information, and handling result information during this abnormal operation will be stored in the rule base; And update the weights of the corresponding processing strategies in the rule base based on the stored information.

3. The processing method according to claim 1, characterized in that, The attribute parameters include request mode type and signal type; the step of determining the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and using the operating status evaluation rule to analyze the request signal to determine whether the vehicle-mounted TBOX terminal is operating normally includes: Based on the request mode type of the request signal, determine whether it is a wake-up request; If the signal is a wake-up request, based on the signal type, if the request signal is determined to be a pre-set signal with the highest priority, then the vehicle-mounted TBOX terminal is determined to be operating normally; or, if the request signal is not a pre-set signal with the highest priority, but there are at least a predetermined number of independent wake-up request signals with a continuous effective duration exceeding a set time, then the vehicle-mounted TBOX terminal is determined to be operating normally; otherwise, the vehicle-mounted TBOX terminal is determined to be operating abnormally; wherein, the predetermined number and the set time are dynamic values. If no wake-up request is made, and it is determined that all wake-up sources meet the sleep requirements based on the request signal, the vehicle TBOX terminal is determined to be operating normally; or, if the request signal includes a specified sleep instruction, the vehicle TBOX terminal is determined to be operating normally; otherwise, the vehicle TBOX terminal is determined to be operating abnormally.

4. The processing method according to claim 1, characterized in that, The multidimensional evaluation metrics include: wake-up response time, signal packet loss rate, CPU load, sleep process status, and communication module state machine.

5. The processing method according to claim 1, characterized in that, The abnormal alarm information includes: the type of abnormality, the cause of the fault, and the key monitoring data on which the abnormality is determined. The process of determining the abnormal alarm information of the current vehicle-mounted TBOX terminal by performing real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule base includes: When it is determined from real-time monitoring data that the wake-up time exceeds the threshold, the anomaly type is determined to be excessively long wake-up response time, and this real-time monitoring data is identified as critical monitoring data. When the number of wake-ups per unit time exceeds the preset number based on real-time monitoring data, the anomaly type is determined to be an abnormal increase in the number of wake-ups, and the real-time monitoring data is identified as critical monitoring data. When it is determined from real-time monitoring data that the vehicle has met the sleep conditions, but the vehicle TBOX terminal has not entered the specified low power state after the sleep command is issued for more than a preset time, the abnormality type is determined to be sleep timeout abnormality, and the real-time monitoring data is determined to be critical monitoring data. When it is determined from real-time monitoring data that the module's state remains unchanged for more than a preset time, the anomaly type is determined to be a communication module status freeze, and the real-time monitoring data is determined to be critical monitoring data. When the detected anomaly types are sleep timeout and communication module status freeze, the cause of the fault is determined to be communication module driver uninstallation anomaly. When an abnormal increase in the number of wake-ups is detected, and the corresponding wake-up is determined to be a network-side fake wake-up based on real-time monitoring data, the cause of the fault is determined to be a network fake wake-up attack.

6. The processing method according to claim 1, characterized in that, The execution of the determined processing strategy according to the progressive fault recovery mechanism includes: Set the handling strategy for forcibly uninstalling drivers or resetting specific software modules as the primary handling strategy and execute it first; The processing strategy for restarting the communication module hardware will be set to a medium-level processing strategy, which will be executed after the primary processing strategy fails to recover. The TBOX system will be restarted. The final processing policy will be set and executed if the intermediate processing policy fails to recover.

7. The processing method according to claim 2, characterized in that, The step of updating the weights of the corresponding processing strategies in the rule base based on the stored information includes: The success rate of each processing strategy is determined based on the stored information and historical information in the database. For each processing strategy, the product of the success rate of the processing strategy and the basic weight coefficient is determined as the current weight of the processing strategy.

8. A processing device for abnormal operation of a vehicle-mounted TBOX terminal, characterized in that, The processing device includes: The receiving module is used to receive the request signal sent by the multi-source wake-up source after filtering. The first determining module is used to determine the corresponding operating status evaluation rule based on the attribute parameters of the request signal, and to analyze the request signal using the operating status evaluation rule to determine whether the vehicle-mounted TBOX terminal is operating normally. The second determination module is used to determine the abnormal alarm information of the vehicle TBOX terminal if the vehicle TBOX terminal is operating abnormally, based on the pre-set multi-dimensional evaluation indicators, to obtain real-time monitoring data under each evaluation indicator, and to perform real-time data comparison and abnormal pattern recognition based on the built-in abnormal evaluation rule library. The processing module is used to determine the processing strategy corresponding to the determined abnormal alarm information based on the determined abnormal alarm information, and execute the determined processing strategy according to the progressive fault recovery mechanism until the vehicle-mounted TBOX terminal is running normally.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the machine-readable instructions are executed by the processor to perform the steps of the processing 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 a computer program that, when executed by a processor, performs the steps of the processing method as described in any one of claims 1 to 7.

Images