Log collection method and device

Abstract

The invention discloses a log collection method and device, and relates to the technical field of vehicle management. The method comprises the following steps: continuously monitoring operation indexes of the vehicle-mounted system; judging whether the vehicle-mounted system is abnormal or not through a preset abnormality recognition rule based on the operation index; when it is determined that the vehicle-mounted system is abnormal, a corresponding first target module is determined, a log switch corresponding to the first target module is turned on, and a log corresponding to the first target module is collected. According to the method and the device, the abnormity is automatically identified according to the preset abnormity identification rule through the operation index, the first target module is accurately positioned when the abnormity is determined to exist, the corresponding log switch is immediately turned on to collect the log, and log capture is completed at the first time when the abnormity occurs; the situation that context information of a key abnormal site and system operation data are lost due to time difference is effectively avoided, the real scene where the abnormality occurs is completely restored, and the success rate of fault root cause analysis is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of vehicle management technology, and in particular to a log collection method and apparatus. Background Technology

[0002] With the continuous improvement of automotive intelligence and connectivity, intelligent connected vehicles have evolved into complex embedded terminals integrating multiple modules and systems. Their in-vehicle systems encompass multiple core functional modules such as multimedia, Bluetooth, navigation, network communication, and positioning, requiring continuous and stable operation during driving to ensure driving safety and user experience. Logs, as a "data mirror" of the in-vehicle system's operational status, can comprehensively record key information such as module interaction processes, abnormal triggering scenarios, and resource usage. They serve as core data support for fault diagnosis, quality issue tracing, software iteration optimization, and R&D testing and verification.

[0003] In real-world applications, intelligent connected vehicles face diverse log collection needs, including intermittent faults (such as Bluetooth disconnection, navigation freezes, and audio stuttering), monitoring of specific vehicles (pre-production vehicles, VIP user vehicles, and vehicles with potential problems), and specialized R&D testing. These needs place stringent requirements on the real-time performance, completeness, and accuracy of log collection. It is essential to capture on-site data immediately upon the occurrence of a fault, ensuring no critical vehicle logs are missed, while simultaneously meeting the convenient configuration requirements of R&D testing, providing a reliable basis for subsequent problem localization and system optimization.

[0004] In current technology, log collection in intelligent connected vehicles is mainly passively triggered. When the vehicle system experiences occasional failures (such as process crashes or functional abnormalities), the vehicle system does not enable log collection by default. Users need to discover the fault afterward and actively report the problem. Then, the R&D personnel will remotely guide the users to manually enable the log switch or export the data to complete the collection of fault-related logs.

[0005] Therefore, it can be seen that in the current technology, passively triggered log collection relies on users reporting faults after the fact and manual operation, which leads to a delay in log collection. Key contextual information of the abnormal situation and system operation data may have been lost, making it difficult to reproduce intermittent faults and resulting in a low success rate of root cause analysis. Summary of the Invention

[0006] To address the aforementioned issues, this application provides a log collection method and apparatus. By monitoring the operational indicators of the vehicle system, it automatically identifies anomalies based on preset anomaly identification rules. When an anomaly is detected in the vehicle system, it accurately locates the first target module and immediately activates the corresponding log switch to collect logs. Log capture can be completed immediately upon the occurrence of an anomaly without any user intervention, effectively avoiding the loss of contextual information and system operation data at the critical anomaly scene due to time differences. It fully restores the real scenario of the anomaly occurrence, provides core data support for the reproduction of intermittent faults, and significantly improves the success rate of root cause analysis.

[0007] The embodiments of this application disclose the following technical solutions:

[0008] In a first aspect, embodiments of this application disclose a log collection method applied to an in-vehicle terminal, the method comprising:

[0009] Continuously monitor the operational indicators of the vehicle system;

[0010] Based on the aforementioned operational metrics, and through preset anomaly identification rules, it is determined whether the in-vehicle system exhibits any anomalies.

[0011] When an anomaly is detected in the vehicle system, the corresponding first target module is identified, and the log switch corresponding to the first target module is turned on to collect the logs of the first target module.

[0012] In one possible implementation, after activating the log switch corresponding to the first target module and collecting the logs corresponding to the first target module, the method further includes:

[0013] Monitor the duration of log collection corresponding to the first target module;

[0014] When the data collection duration reaches the preset duration, the log switch corresponding to the first target module is turned off.

[0015] In one possible implementation, the preset anomaly identification rules include: multiple sets of anomaly triggering conditions and anomaly modules corresponding to each of the multiple sets of anomaly triggering conditions; the step of determining whether the vehicle system has anomalies based on the operating indicators and the preset anomaly identification rules includes:

[0016] The system matches the operating indicators with multiple sets of abnormal triggering conditions included in the preset abnormality identification rules to determine whether there are any abnormal triggering conditions that match the operating indicators, so as to determine whether there is an abnormality in the vehicle system.

[0017] When it is determined that there is an anomaly in the vehicle system, the corresponding first target module is determined, including:

[0018] When an abnormal triggering condition matching the operational metric is identified, it is determined that the system is abnormal, and based on the preset abnormal identification rules, the abnormal module corresponding to the matching abnormal triggering condition is identified as the corresponding first target module.

[0019] In one possible implementation, the method includes:

[0020] Receive log collection instructions sent by the cloud server; wherein, the log collection instructions include: a log collection strategy, and the log collection strategy includes: the identifier of the vehicle terminal and the identifier of the second target module;

[0021] Perform security authentication on the log collection command;

[0022] Once the security authentication is successful, based on the log collection strategy included in the log collection instruction, the log switch corresponding to the second target module indicated by the second target module identifier is turned on, and the logs corresponding to the second target module are collected.

[0023] In one possible implementation, the log collection strategy further includes: log levels; wherein the log levels include: a first level, a second level, and a third level; the first level represents the collection of key result logs of the second target module, with the least amount of log output; the second level represents the collection of core process logs of the second target module, with a log output greater than that of the first level and less than that of the third level; the third level represents the collection of full-process detailed logs of the second target module, with the largest amount of log output.

[0024] In one possible implementation, after collecting the logs corresponding to the second target module, the method further includes:

[0025] When a data collection termination command is received from the cloud server, the log switch corresponding to the second target module is turned off.

[0026] In one possible implementation, the method further includes:

[0027] In response to an access request triggered by a user through a preset operation, display an identity authentication interface to the user;

[0028] Receive authentication information input by the user through the authentication interface, and verify the authentication information;

[0029] Once the authentication information is verified, the log configuration interface is displayed to the user, and the user's selection instructions for the third target module and log configuration are received through the log configuration interface.

[0030] In response to the input of the selection command, the log switch corresponding to the third target module is turned on, and the logs corresponding to the third target module are collected.

[0031] In one possible implementation, the authentication information includes: an initial password and a secondary verification code generated using the vehicle identification number (VIN) as the seed.

[0032] In one possible implementation, the method further includes:

[0033] The collected logs are stored in a local cache, and the network connection status of the vehicle terminal is monitored in real time.

[0034] Based on the importance level of the locally cached logs and the network connection status, the locally cached logs are encrypted and uploaded to the cloud server in batches.

[0035] Secondly, embodiments of this application disclose a log generation device, characterized in that it is applied to an in-vehicle terminal, the device comprising:

[0036] The performance indicator monitoring module is used to continuously monitor the operating indicators of the vehicle system.

[0037] An anomaly detection module is used to determine whether there is an anomaly in the vehicle system based on the operating indicators and through preset anomaly identification rules;

[0038] The acquisition trigger module is used to determine the corresponding first target module when it is determined that there is an anomaly in the vehicle system, and to activate the log switch corresponding to the first target module and collect the logs corresponding to the first target module.

[0039] Compared with existing technologies, this application has the following advantages: by monitoring the operating indicators of the vehicle system, it can automatically identify anomalies according to preset anomaly identification rules, and accurately locate the first target module when an anomaly is determined to exist in the vehicle system and immediately turn on the corresponding log switch to collect logs. Log capture can be completed at the first moment when the anomaly occurs without any user intervention, effectively avoiding the loss of context information and system operating data at the critical anomaly scene due to time difference, completely restoring the real scene of the anomaly, providing core data support for the reproduction of intermittent faults, and significantly improving the success rate of root cause analysis of faults. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 A flowchart illustrating a log collection method provided in an embodiment of this application;

[0042] Figure 2 This is a connection diagram of an in-vehicle terminal provided in an embodiment of this application;

[0043] Figure 3 A flowchart illustrating another log collection method provided in this application embodiment;

[0044] Figure 4 A flowchart illustrating another log collection method provided in this application embodiment;

[0045] Figure 5 This is a schematic diagram of the structure of a log collection device provided in an embodiment of this application. Detailed Implementation

[0046] As described earlier, one common method for log collection in current intelligent connected vehicles is passively triggered log collection. When an intermittent fault occurs in the vehicle system, log collection is not enabled by default. Users need to discover the fault and actively report it afterward. Developers then remotely guide users to manually enable the log switch or export the data to complete the collection of fault-related logs. Therefore, passively triggered collection relies on user reports and manual operations, resulting in a lag in log collection. There is a significant time difference between the occurrence of the fault and the activation of the log, during which contextual information of the abnormal situation and system operating status data may be lost. This makes intermittent faults difficult to reproduce and results in a low success rate of root cause analysis.

[0047] In addition to the above, current technologies commonly employ user-dependent vehicle log collection methods, such as user-dependent log collection. Specifically, for vehicles requiring close monitoring, such as those undergoing trial installations of new software, VIP user vehicles, and vehicles with known potential problems, users are guided to manually enable log collection via push notifications or customer service calls to obtain relevant logs from the target vehicles. Therefore, current technologies heavily rely on user cooperation for log collection from critical vehicles. However, users may fail to enable the function due to cumbersome procedures, lack of understanding of the function, or forgetfulness, leading to failure in collecting core operational data from key monitored vehicles. This directly impacts the tracking and closed-loop processing of quality issues.

[0048] Current technologies commonly employ several methods for collecting logs in intelligent connected vehicles, including specialized, configurable test log collection. Specifically, when conducting specialized tests, R&D or testing personnel need to temporarily enable detailed logs for multiple target modules by connecting to a development computer, entering debugging commands, or modifying system configuration files to meet the data collection requirements during the testing process. This demonstrates that configuring specialized test logs requires specialized tools and involves complex and demanding operations. This not only increases the preparation costs for R&D testing and reduces testing efficiency but may also affect the normal functionality of the vehicle system due to modifications to system configuration files.

[0049] This application provides a log collection method, including: continuously monitoring the operating indicators of an in-vehicle system; determining whether there is an anomaly in the in-vehicle system based on the operating indicators and through preset anomaly identification rules; when an anomaly is determined in the in-vehicle system, identifying the corresponding first target module, and activating the log switch corresponding to the first target module to collect the logs corresponding to the first target module. This application achieves automatic anomaly identification by monitoring the operating indicators of the in-vehicle system and according to preset anomaly identification rules. When an anomaly is determined, it accurately locates the first target module and immediately activates the corresponding log switch to collect logs. Log capture can be completed immediately upon the occurrence of an anomaly without any user intervention, effectively avoiding the loss of contextual information and system operating data due to time differences in the critical anomaly scene. It fully reconstructs the real scenario of the anomaly occurrence, providing core data support for the reproduction of intermittent faults and significantly improving the success rate of root cause analysis.

[0050] 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.

[0051] Example 1:

[0052] The following is combined with Figures 1-4 This application provides a detailed description of a log collection method based on its embodiments.

[0053] First, the log collection method provided in this application is applied to an in-vehicle terminal. The in-vehicle terminal refers to a hardware and software complex deployed inside an intelligent connected vehicle, integrating log collection, monitoring, and storage functions; it is the main entity responsible for log collection.

[0054] like Figure 1 As shown in the figure, a log collection method provided in this application includes the following steps:

[0055] S101. Continuously monitor the operating indicators of the vehicle system.

[0056] Among them, the operating indicators refer to the data that reflect the operating status of the vehicle system and its various functional modules, including but not limited to: core process crash and application unresponsiveness (ANR) status, CPU (central processing unit) utilization, memory utilization, disk input / output (I / O) rate, and the operating status of each functional module, function response latency, and network connection status (such as connection success, failure, timeout, disconnection, etc.).

[0057] A functional module refers to a collection of hardware and software units within an in-vehicle system that possess independent core functions, can operate independently, and have clearly defined boundaries. These are the fundamental functional components of an in-vehicle system. Examples of functional modules include: multimedia modules, Bluetooth modules, navigation modules, audio decoding modules, and positioning modules.

[0058] Specifically, "intelligent log analyzer" software is deployed on the vehicle terminal. The intelligent log analyzer continuously scans the core processes, resource usage, module interactions, and other data of the vehicle system to capture the operating indicators of the vehicle system in real time.

[0059] S102. Based on operational indicators, determine the presence of the vehicle system using preset anomaly identification rules.

[0060] Among them, the preset anomaly identification rules refer to those obtained from historical fault data of the vehicle system (such as the Jira database problem list) and positive analysis at the module source code level, which clearly define the triggering conditions and corresponding functional modules under different anomaly scenarios.

[0061] In one possible implementation, the preset anomaly identification rules include: multiple sets of anomaly triggering conditions and anomaly modules corresponding to the multiple sets of anomaly triggering conditions (i.e., functional modules that cause the abnormality of the set of operating indicators of the vehicle system, such as functional module A being abnormal, thus causing anomaly triggering condition a).

[0062] For example, anomaly identification rules can be constructed in the following ways: One approach is to analyze historical fault cases recorded in the Jira database, extract operational metrics when various faults occur (such as the number of pairing failures during Bluetooth disconnection, and the error logs of the decoding module corresponding to audio stuttering), and obtain anomaly identification rules of "anomaly triggering condition - corresponding abnormal module". Another approach is for developers of each functional module to define the operational metrics of typical operating states when each functional module is abnormal based on the source code logic (such as thread blocking characteristics during process ANR, and resource contention scenarios when CPU usage is high), and obtain anomaly identification rules of "anomaly triggering condition - corresponding abnormal module".

[0063] To facilitate understanding, Table 1 below provides examples illustrating the anomaly detection rules:

[0064] Table 1

[0065]

[0066] As shown in Table 1, when the abnormal triggering conditions are: system CPU utilization ≥ 90% for 30 seconds, the corresponding abnormal module is the system resource management module; when the abnormal triggering condition is that the Bluetooth module fails to pair / connect 3 times consecutively, the corresponding abnormal module is the Bluetooth module; when the abnormal triggering condition is that the system audio focus application fails, the corresponding abnormal module is the audio strategy module; when the abnormal triggering condition is that the navigation position does not change within 15 seconds while the vehicle is in motion, the corresponding abnormal module is the positioning module; when the abnormal operating state is that the network connection status is abnormal, the corresponding abnormal module is the network communication module.

[0067] Furthermore, in one possible implementation, the operating indicators are matched with multiple sets of anomaly triggering conditions included in the preset anomaly identification rules to determine whether there are any anomaly triggering conditions that match the operating indicators, thereby determining whether there is an anomaly in the vehicle system. If there is an anomaly triggering condition that matches the operating indicators, it is determined that there is an anomaly in the vehicle system; if there is no anomaly triggering condition that matches the operating indicators, it is determined that there is no anomaly in the vehicle system.

[0068] Specifically, the collected operational metrics are compared one by one with multiple sets of anomaly triggering conditions in the anomaly identification rules to verify whether the collected operational metrics meet the anomaly triggering conditions; when the operational metrics meet the anomaly triggering conditions, the anomaly triggering conditions match the operational metrics.

[0069] In one possible implementation, multi-dimensional parallel matching is used to simultaneously detect different dimensions of real-time operational metrics (process status, resource usage, module functionality, and log output), comparing them one by one with each set of anomaly triggering conditions in the anomaly identification rules. For example, for quantitative metrics (such as CPU utilization, duration, and number of failures), a numerical threshold is used to determine whether a match exists; for log-related metrics (such as error log printing), keyword matching (such as "timeout" and "failed") and frequency statistics (such as ≥3 error logs within 10 seconds) are used to determine whether a match exists.

[0070] S103. When it is determined that there is an anomaly in the vehicle system, the corresponding first target module is identified, and the log switch corresponding to the first target module is turned on to collect the logs corresponding to the first target module.

[0071] The first target module refers to the functional module (i.e., the module to which the fault source belongs) that is directly related to the anomaly when the vehicle system malfunctions, determined by matching anomaly identification rules.

[0072] The log switch refers to the software control node that controls the start and stop of log collection for each functional module. It supports independent enabling / disabling of a single module to avoid redundant data caused by full log collection.

[0073] Specifically, when an anomaly is detected in the vehicle system, the corresponding primary target module is identified. The vehicle system automatically activates the logging switch for the primary target module and collects its logs, without involving other unrelated modules, ensuring that the collected logs are specific to that module. For example, the collected logs include: module interaction data, parameter configuration information, error codes, underlying call logs, etc., fully recording the module's operating status at the time of the anomaly.

[0074] In one possible implementation, when it is determined that there is an abnormal triggering condition that matches the operating indicators, it is determined that there is an abnormality in the system, and based on the preset abnormality identification rules, the abnormal module corresponding to the matching abnormal triggering condition is determined as the corresponding first target module.

[0075] For example, as shown in Table 1, when the real-time monitored operating indicators include: Bluetooth module fails to pair / connect three times consecutively, the operating indicator matches the abnormal trigger condition in the preset abnormal identification rules, and it is determined that there is an abnormality in the vehicle system; and according to the abnormal trigger condition of "Bluetooth module fails to pair / connect three times consecutively", the abnormal module "Bluetooth module" corresponding to the abnormal trigger condition is determined as the first target module; then the log switch of the Bluetooth module is turned on, and the log of the Bluetooth module is collected.

[0076] Furthermore, monitor the duration of log collection corresponding to the first target module; when the collection duration reaches the preset duration, turn off the log switch corresponding to the first target module.

[0077] The data collection duration refers to the time elapsed from when the log switch of the first target module was turned on to the current moment.

[0078] The preset duration refers to the maximum log collection time preset based on system resource usage assessment. The default setting is 5 minutes (which can be adjusted according to the actual scenario). The core purpose is to balance the integrity of log collection with the system's operating load.

[0079] Specifically, when the log switch of the first target module is turned on, the vehicle terminal automatically starts timing and begins to count the duration of log collection; it compares the current collection duration with the preset duration in real time: if the preset duration has not been reached, the log switch remains on and log collection continues; when the collection duration reaches the preset duration, the log switch of the first target module is turned off, and log collection of the first target module is terminated.

[0080] As mentioned above Figure 1 The log collection method described in this application features a continuous monitoring and automatic identification mechanism. It eliminates the need for user reporting and manual operation, initiating log collection the moment an anomaly occurs. This completely eliminates the time lag between fault occurrence and log activation, preventing the loss of contextual information and system operation data at critical anomaly points. This significantly increases the reproducibility of intermittent faults, transforming passive collection into proactive capture, thus resolving the issue of delays. Furthermore, the entire process requires no user intervention, avoiding log collection failures caused by cumbersome operations, forgetfulness, or misunderstanding. This ensures that every system anomaly is effectively recorded, improving the data support coverage for fault diagnosis.

[0081] Furthermore, based on preset anomaly identification rules, this application embodiment only collects logs for the first target module and does not collect data from irrelevant modules. This reduces log storage usage and subsequent analysis workload while ensuring the relevance of log data and improving the efficiency of root cause analysis.

[0082] Furthermore, this application embodiment uses a mechanism to automatically turn off the log switch after a preset time to avoid long-term occupation of system resources such as CPU, memory, and storage by log collection, thereby preventing the vehicle system from experiencing functional lag or performance degradation due to log collection, and achieving a balance between collection needs and system stability.

[0083] The following is combined with Figure 2 and Figure 3 This paper details another log collection method provided in the embodiments of this application.

[0084] First, such as Figure 2 As shown in the embodiment of this application, another log collection method is applied to an in-vehicle terminal, and the in-vehicle terminal interacts with a cloud server.

[0085] The cloud server is not a single physical server, but a distributed architecture cluster composed of multiple servers, possessing high reliability, scalability, and security protection capabilities. Essentially, it serves as the policy center, command center, and data center for log collection. The cloud server does not directly participate in the log collection execution of the vehicle terminal, but rather achieves remote control, data aggregation, and subsequent analysis of the log collection process through secure communication with the vehicle terminal, thus forming a "vehicle-cloud collaborative" log collection system together with the vehicle terminal.

[0086] like Figure 3 As shown in the figure, a log collection method provided in this application includes the following steps:

[0087] S301: Receive log collection instructions sent by the cloud server.

[0088] The log collection instructions include: a log collection strategy, which includes: the identifier of the vehicle terminal and the identifier of the second target module.

[0089] Log collection commands refer to standardized commands generated by cloud servers. They are the core basis for triggering remote log collection by vehicle terminals, and include log collection strategies and command validity verification information, which are sent through a secure communication link.

[0090] The log collection strategy refers to the core content of the log collection instructions, which clarifies the target objects and scope of log collection. Specifically, it includes the identification of the vehicle terminal and the identification of the second target module to ensure the targeted nature of the collection.

[0091] The identification of an in-vehicle terminal refers to the information used to uniquely identify the target in-vehicle terminal. The Vehicle Identification Number (VIN) is preferred to support the accurate location of a single vehicle; it can also be combined with vehicle model, software version, etc. to form a group identification to meet the needs of batch vehicle data collection.

[0092] The second target module identifier refers to the code or name (such as "Bluetooth module", "navigation module", "network communication module") used to uniquely identify the functional module whose logs need to be collected. It corresponds one-to-one with each functional module in the vehicle terminal to ensure accurate and targeted log collection.

[0093] In one possible implementation, the log collection command is created by operations, quality, or development personnel through the "log collection policy configuration interface" provided by the cloud server's web backend. That is, operations, quality, or development personnel create a log collection policy through the "log collection policy configuration interface" provided by the cloud server's web backend and send the log collection policy to the vehicle terminal via the log collection command.

[0094] For example, the cloud server provides a visual web-based "log collection strategy configuration interface," through which maintenance, quality, or R&D personnel can create log collection strategies: input the identifier of the target vehicle terminal (such as a single VIN code, or filter for vehicles with "2024 XX model + software version V2.0"), and select the identifier of the second target module (such as "Bluetooth module" or "Location positioning module"). The cloud server's command delivery service encapsulates the log collection strategy into standardized log collection commands and sends the commands to the target vehicle terminal through a secure communication link established by the 4G / 5G network (using TLS encryption), ensuring that the command transmission process is not stolen or tampered with.

[0095] Furthermore, while the cloud server sends the log collection command to the vehicle terminal, it digitally signs the log collection command (adding a legitimate cloud identity identifier) ​​to ensure the security of the log collection command.

[0096] In one possible implementation, the log collection strategy also includes: log levels, which include: first level, second level, and third level.

[0097] Log level refers to the classification standard of log collection detail, which is used to flexibly adjust the breadth and depth of the collected content according to actual needs, and balance log integrity and system resource consumption.

[0098] The first level represents the collection of key result logs from the second target module, with the least amount of log output. The first level is the lowest level of log collection detail, focusing only on core results, with the least amount of log output, and is suitable for routine monitoring and traffic-sensitive scenarios.

[0099] The second level represents the collection of core process logs of the second target module. The log output volume is greater than that of the first level but less than that of the third level. The second level is a log collection level with medium detail, covering the core process. The log output volume is between that of the first and third levels and is suitable for routine troubleshooting scenarios.

[0100] The third level represents the collection of detailed logs from the second target module throughout the entire process, with the largest log output. The third level is the highest level of log collection detail, recording all details throughout the process, with the largest log output, and is suitable for in-depth fault diagnosis and R&D testing scenarios.

[0101] S302. Perform security authentication on log collection commands.

[0102] Among them, security authentication refers to the process by which the vehicle terminal verifies the legality and integrity of the received log collection commands. Its core purpose is to prevent malicious commands from intruding and being tampered with, and to ensure the security of the vehicle system and log data.

[0103] In one possible implementation, security authentication could involve verifying whether the digital signature in the log collection command comes from a legitimate cloud server, confirming the sender's identity (i.e., digital signature verification); and verifying the validity of the certificate used during the transmission of the log collection command, ensuring that the command has not been tampered with and that the transmission link is secure (i.e., certificate check).

[0104] When security authentication fails (e.g., invalid signature, expired certificate), the vehicle terminal directly discards the log collection command and does not perform any collection operation; when security authentication passes, it proceeds to S303.

[0105] S303. When the security authentication is successful, based on the log collection strategy included in the log collection instruction, the log switch corresponding to the second target module indicated by the second target module identifier is turned on, and the logs corresponding to the second target module are collected.

[0106] Specifically, the vehicle terminal parses the log collection instructions, including the log collection strategy, extracts the second target module identifier, and locates the corresponding functional module based on the second target module identifier to obtain the second target module; it automatically turns on the log switch corresponding to the second target module, and only collects the operation log of this module (without involving other unrelated modules). The collected content includes module interaction data, operation status parameters, abnormal error information, etc., to ensure the relevance of the log data.

[0107] In one possible implementation, after the vehicle terminal parses the log level, it collects the logs of the second target module according to the corresponding log level. When the log level is the first level, only the core result information of the second target module's operation is collected, such as the success / failure of the functional module startup, the execution results of core functions (Bluetooth pairing success / failure, navigation startup completion), and fatal exception error codes. Intermediate process data is not recorded to minimize the amount of logs. When the log level is the second level, in addition to the first level, key node information of the core workflow of the second target module is collected, such as the key steps of Bluetooth pairing ("request-response-confirmation"), the core parameters of navigation positioning data (latitude and longitude, signal strength), and the triggering scenarios of non-fatal exceptions, balancing log completeness and output volume. When the log level is the third level, the entire process data of the second target module's operation is collected, including underlying interaction protocol data (such as Bluetooth protocol stack logs), real-time operating parameters (CPU / memory usage, data transmission rate), all exception information (including warning level and prompt level logs), and debug logs, providing complete data support for in-depth analysis.

[0108] Furthermore, in one possible implementation, after collecting the logs corresponding to the second target module, when a collection termination command is received from the cloud server, the log switch corresponding to the second target module is turned off.

[0109] The collection termination instruction refers to a standardized instruction generated by the cloud server to terminate the initiated remote log collection process. It includes information such as instruction identifier, target vehicle terminal identifier, and second target module identifier, and uses the same secure transmission method as the log collection instruction.

[0110] Specifically, when the cloud server has acquired sufficient logs (e.g., fault data has been captured), the collection strategy has been adjusted, or collection is no longer necessary, maintenance and development personnel initiate a termination operation through the cloud server backend. The cloud server generates a collection termination command, which, after being digitally signed and encrypted with TLS, is sent to the target vehicle terminal. Upon receiving the collection termination command, the vehicle terminal performs security authentication on the command. After successful authentication, it parses the collection termination command.

[0111] Furthermore, after the vehicle terminal turns off the log switch corresponding to the second target module, it can send a confirmation message to the cloud server that the data collection has been terminated.

[0112] As mentioned above Figure 3 The log collection method described in this application involves remotely issuing commands from a cloud server and forcibly executing them on the vehicle terminal. This eliminates the need for user intervention, completely avoiding log collection failures caused by user forgetfulness, cumbersome operations, or misunderstanding. It is particularly suitable for critical vehicles such as pre-production vehicles, VIP vehicles, and vehicles with potential problems, ensuring data support for quality issue tracking and closed-loop management, thus solving the problem of easy omissions and ensuring 100% collection of key data. Furthermore, security authentication prevents malicious command intrusion and data leakage, ensuring the security of the vehicle system and log data.

[0113] Furthermore, the embodiments of this application support flexible configuration of collection strategies and remote termination of collection in the cloud, without the need for on-site operation, and can realize batch vehicle log collection and management, which greatly reduces the working costs of operation and maintenance and R&D personnel, thereby improving log management efficiency.

[0114] Furthermore, this application embodiment uses a triple precise configuration of the vehicle terminal identifier, the second target module identifier, and the log level to collect logs only for the target vehicle, target module, and target level of detail, avoiding storage redundancy and traffic consumption caused by full logs, while ensuring the relevance and usability of log data, thereby balancing log value and resource consumption.

[0115] The following is combined with Figure 4 This paper details another log collection method provided in the embodiments of this application.

[0116] like Figure 4 As shown in the embodiment of this application, another log collection method includes the following steps:

[0117] S401. In response to an access request triggered by a user through a preset operation, display an authentication interface to the user.

[0118] Among them, preset operations refer to specific operations reserved by the vehicle system for R&D / testing personnel to trigger the security entry. These operations are invisible or difficult to trigger for ordinary users, ensuring the security of the entry. These operations include various forms such as physical button combinations and hidden menu operations.

[0119] For example, the preset operation can be: physical button combination (such as pressing and holding the "volume +" button and "voice -" button on the vehicle terminal for 5 seconds at the same time), hidden menu operation (such as pressing and holding the hardware version information text on the vehicle system settings page for 5 seconds, and then pressing and holding the text for 5 seconds in succession), interface signal trigger (such as sending a trigger signal through a dedicated debugging interface, or sending a specified CAN signal after connecting to the OBD port), QR code authentication trigger (such as scanning a QR code containing vehicle identification number (VIN) information and initiating a connection request through a dedicated APP).

[0120] The identity authentication interface refers to the verification interface displayed by the vehicle terminal after receiving an access request. It is used to verify the legitimacy of the user's identity and prevent unauthorized personnel from accessing the site. For example, the identity authentication interface displayed by the vehicle terminal to the user clearly prompts for the authentication information to be entered (such as an initial password and a secondary verification code).

[0121] S402. Receive authentication information entered by the user through the authentication interface and verify the authentication information.

[0122] Among them, authentication information refers to the identity verification data that users need to enter, which is the core basis for identity verification.

[0123] In one possible implementation, the authentication information includes an initial password and a secondary verification code generated using the vehicle identification number (VIN) as the seed.

[0124] The initial password refers to a fixed password preset by the system administrator. It serves as the first layer of identity verification, used for initial screening of authorized personnel, and possesses a certain degree of confidentiality. It can be centrally managed or personalized. For example, the initial password may be uniformly set by the system administrator of an automobile manufacturer, or a personalized initial password may be assigned to each test vehicle and communicated to R&D and testing personnel through internal authorization channels. It can also be modified later through the management backend.

[0125] A Vehicle Identification Number (VIN) is a unique identifier for a vehicle, stored in the vehicle's onboard terminal system. It possesses uniqueness and immutability, serving as the core seed data for generating a secondary verification code. A secondary verification code is a one-time verification code dynamically generated using the VIN as the seed and a preset algorithm (such as a hash algorithm or random number generation algorithm). It acts as a second layer of verification, enhancing authentication security. For example, the onboard terminal's built-in verification code generation algorithm uses the vehicle's VIN as the core seed, combined with the current timestamp (to ensure timeliness), to generate a one-time secondary verification code. The verification code is a 6-8 digit / letter combination.

[0126] Specifically, the vehicle terminal receives the authentication information input by the user. It first compares the initial password included in the authentication information with the initial password pre-stored in the vehicle terminal. If they do not match, the authentication fails directly without needing to proceed to the secondary verification code check. If the initial passwords match, the vehicle terminal calls its built-in algorithm to generate a system-side verification code using the locally stored VIN code and the current timestamp as input. It then compares the secondary verification code included in the authentication information with the system-generated verification code and sets a validity period for the verification code (e.g., 5 minutes). If they match within the validity period, the authentication is successful. If they do not match or have expired, the verification code is invalid and needs to be regenerated and entered.

[0127] S403. When the authentication information is verified, the log configuration interface is displayed to the user, and the user's selection instructions for the third target module and log configuration are received through the log configuration interface.

[0128] The log configuration interface refers to the operation interface displayed after the vehicle terminal verifies the authentication information. It supports users in selecting the target module for log collection and related configurations, and provides a visual selection operation entry.

[0129] The third target module refers to the functional module (such as the navigation module or Bluetooth module) that the user selects through the log configuration interface and needs to be tested specifically. It is the target object for special log collection.

[0130] Among them, the selection command refers to the operation command entered by the user in the log configuration interface, including the selection of the third target module and the setting of log configuration parameters (such as log level), which is the direct basis for triggering log collection.

[0131] For example, once the authentication information is verified, the user is shown a log configuration interface. The log configuration interface lists all configurable functional modules (such as Bluetooth module, positioning module, audio decoding module, etc.) in the form of checkboxes, and provides log level selection options (level 1, level 2, and level 3). R&D and testing personnel can input selection commands by checking modules and selecting log levels according to specific testing needs. The interface provides real-time feedback on the user's selection results and supports multiple module selections and flexible switching of log levels.

[0132] S404. In response to the input of the selection command, turn on the log switch corresponding to the third target module and collect the logs corresponding to the third target module.

[0133] Specifically, after receiving the selection command, the vehicle terminal immediately parses the third target module and log configuration parameters in the selection command; it automatically turns on the log switch corresponding to the third target module, and collects logs according to the configured log configuration parameters. The collected content includes the module's full-process operation data, debugging information, and abnormal logs, which meet the specific testing requirements.

[0134] Furthermore, the log collection of the third target module triggered by this selection command is only valid for the current power-on cycle of the vehicle terminal. After the vehicle is powered on again, the log switch is automatically turned off and the configuration is restored to the default state to avoid affecting the use of ordinary users.

[0135] As mentioned above Figure 4The log collection method described in this application requires no connection to a development computer, input of complex debugging commands, or modification of configuration files. Log collection can be quickly configured through preset operations and a visual interface, simplifying pre-test preparation and allowing R&D / testing personnel to focus on core testing tasks. It eliminates the need for specialized debugging tools and advanced technical permissions; ordinary R&D / testing personnel can operate it after simple training, lowering the technical threshold and manpower costs of specialized testing and significantly improving testing efficiency. Furthermore, the secure entry point provided by the vehicle terminal is invisible to ordinary users and requires dual authentication to prevent unauthorized access.

[0136] Furthermore, this application embodiment uses a dual verification mechanism of initial password and secondary verification code to ensure the legitimacy of the access personnel's authorization, and also prevents the verification code from being reused or forged by uniquely binding the VIN code to the vehicle, thus ensuring the security of the vehicle system and test data.

[0137] Furthermore, the embodiments of this application support multiple selections of third target modules, which can be flexibly selected according to specific testing scenarios (such as single module testing, multi-module collaborative testing); with log level configuration, it can collect core process data as well as capture full detailed logs, adapting to different testing depth requirements.

[0138] In one possible implementation, the collected logs are stored in a local cache, and the network connection status of the vehicle terminal is monitored in real time. Based on the importance level of the locally cached logs and the network connection status, the locally cached logs are encrypted and uploaded to the cloud server in batches.

[0139] Local cache refers to a dedicated storage area built into the vehicle terminal (which can use flash memory, solid-state drives, or other media) used for temporary storage of collected log data. It features fast read and write speeds, strong shock resistance, and capacity adapted to vehicle scenarios. It also supports archiving by log type, importance level, and collection timestamp.

[0140] The importance level of logs refers to a priority standard based on their practical value and urgency. It is primarily based on the log collection scenario and the scope of the fault's impact, categorized into high, medium, and low levels to ensure that critical data is uploaded first. Specifically, during log collection, the vehicle-mounted terminal automatically marks logs with importance levels according to the collection mechanism, requiring no manual intervention and ensuring accurate and efficient judgment.

[0141] The network connection status refers to the network access status of the vehicle terminal, including three statuses: Wi-Fi connection (preferred), 4G / 5G mobile network connection, and no network connection. Among them, Wi-Fi connection is the optimal network environment for log uploading (low data cost and high stability).

[0142] Specifically, locally cached logs are split and transmitted to the cloud server in batches according to their importance and data volume. For example, high-importance logs are split into batches of up to 50MB each (to avoid timeouts for large data transmissions), and logs of the same importance are sorted in ascending order by collection timestamp (first collected, first uploaded); medium-importance logs are split into batches of up to 100MB each; and low-importance logs are split into batches of up to 200MB each, and then merged and uploaded in batches to improve efficiency.

[0143] In one possible implementation, importance levels are ranked as follows: High > Medium > Low, and network connection status is ranked as follows: Stable Wi-Fi connection > Unstable Wi-Fi connection > 4G / 5G connection. For high-level logs, the network connection status is stable Wi-Fi connection, unstable Wi-Fi connection, and 4G / 5G connection, triggering batch encrypted uploads to the cloud server. For medium-level logs, the network connection status is stable Wi-Fi connection and 4G / 5G connection, triggering batch encrypted uploads to the cloud server. For low-level logs, the network connection status is stable Wi-Fi connection only, triggering batch encrypted uploads to the cloud server.

[0144] This application provides a log collection method, including: continuously monitoring the operating indicators of an in-vehicle system; determining whether there is an anomaly in the in-vehicle system based on the operating indicators and a preset anomaly identification rule; when an anomaly is determined, identifying the corresponding first target module, activating the log switch corresponding to the first target module, and collecting the logs corresponding to the first target module. This application monitors the operating indicators of the in-vehicle system, automatically identifies anomalies according to preset anomaly identification rules, and accurately locates the first target module and immediately activates the corresponding log switch to collect logs when an anomaly is determined. Log capture can be completed immediately upon the occurrence of an anomaly without any user intervention, effectively avoiding the loss of contextual information and system operating data due to time differences in the critical anomaly scene. It fully reconstructs the real scenario of the anomaly occurrence, providing core data support for the reproduction of intermittent faults and significantly improving the success rate of root cause analysis.

[0145] Example 2:

[0146] The following is combined with Figure 5 This application provides a detailed description of a log collection device provided in its embodiments.

[0147] like Figure 5 As shown in the figure, a log collection device provided in this application embodiment includes the following modules:

[0148] The indicator monitoring module 511 is used to continuously monitor the operating indicators of the vehicle system.

[0149] The anomaly detection module 512 is used to determine whether there is an anomaly in the vehicle system based on operating indicators and preset anomaly identification rules.

[0150] The first acquisition module 513 is used to determine the corresponding first target module when it is determined that there is an abnormality in the vehicle system, and to activate the log switch corresponding to the first target module and collect the logs corresponding to the first target module.

[0151] In one possible implementation, it also includes: a data collection termination module, used to monitor the duration of log collection corresponding to the first target module; when the duration of collection reaches a preset duration, the log switch corresponding to the first target module is turned off.

[0152] In one possible implementation, the preset anomaly identification rules include: multiple sets of anomaly triggering conditions and anomaly modules corresponding to each of the multiple sets of anomaly triggering conditions; the anomaly judgment module 512 is specifically used to match the operating indicators with the multiple sets of anomaly triggering conditions included in the preset anomaly identification rules, and to determine whether there are any anomaly triggering conditions that match the operating indicators, so as to determine whether there is an anomaly in the vehicle system; the first acquisition module 513 is specifically used to determine that there is an anomaly in the system when it is determined that there are anomaly triggering conditions that match the operating indicators, and to determine the anomaly module corresponding to the matched anomaly triggering conditions as the corresponding first target module based on the preset anomaly identification rules.

[0153] In one possible implementation, such as Figure 5 As shown, the device also includes:

[0154] The instruction receiving module 521 is used to receive log collection instructions sent by the cloud server; wherein, the log collection instructions include: log collection strategy, and the log collection strategy includes: the identifier of the vehicle terminal and the identifier of the second target module;

[0155] Security authentication module 522 is used to perform security authentication on log collection commands;

[0156] The second acquisition module 523 is used to, when security authentication is passed, activate the log switch corresponding to the second target module indicated by the second target module identifier based on the log acquisition strategy included in the log acquisition instruction, and acquire the logs corresponding to the second target module.

[0157] In one possible implementation, it also includes: a termination receiving module, used to turn off the log switch corresponding to the second target module when a collection termination command is received from the cloud server.

[0158] In one possible implementation, such as Figure 5 As shown, the device also includes:

[0159] The authentication display module 531 is used to display the identity authentication interface to the user in response to the access request triggered by the user through a preset operation.

[0160] The authentication verification module 532 is used to receive authentication information entered by the user through the identity authentication interface and verify the authentication information;

[0161] The configuration display module 533 is used to display the log configuration interface to the user when the authentication information is verified, and to receive the user's selection instructions for the third target module and log configuration through the log configuration interface;

[0162] The third acquisition module 534 is used to respond to the input of the selection command, turn on the log switch corresponding to the third target module, and acquire the log corresponding to the third target module.

[0163] In one possible implementation, the device further includes: a cache detection module, used to store the collected logs in a local cache and detect the network connection status of the vehicle terminal in real time; and a log upload module, used to encrypt and upload the locally cached logs to a cloud server in batches based on the importance level of the locally cached logs and the network connection status. This application embodiment provides a log collection device including: an indicator monitoring module 511, used to continuously monitor the operating indicators of the vehicle system; an anomaly judgment module 512, used to determine whether there is an anomaly in the vehicle system based on the operating indicators and through preset anomaly identification rules; and a first collection module 513, used to determine the corresponding first target module when an anomaly is determined in the vehicle system, and to activate the log switch corresponding to the first target module to collect the logs corresponding to the first target module. This application embodiment monitors the operating indicators of the vehicle system and automatically identifies anomalies according to preset anomaly identification rules. When an anomaly is determined to exist in the vehicle system, it accurately locates the first target module and immediately activates the corresponding log switch to collect logs. Log capture can be completed at the first moment of anomaly without any user intervention, effectively avoiding the loss of contextual information and system operating data at the critical anomaly scene due to time difference. It fully restores the real scene of the anomaly and provides core data support for the reproduction of intermittent faults, significantly improving the success rate of root cause analysis.

[0164] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated 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 modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0165] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included 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 log collection method, characterized in that, Applied to vehicle-mounted terminals, the method includes: Continuously monitor the operational metrics of the vehicle system; Based on the aforementioned operational metrics, and through preset anomaly identification rules, it is determined whether the in-vehicle system exhibits any anomalies. When an anomaly is detected in the vehicle system, the corresponding first target module is identified, and the log switch corresponding to the first target module is turned on to collect the logs of the first target module.

2. The method according to claim 1, characterized in that, After activating the log switch corresponding to the first target module and collecting the logs corresponding to the first target module, the method further includes: Monitor the duration of log collection corresponding to the first target module; When the data collection duration reaches the preset duration, the log switch corresponding to the first target module is turned off.

3. The method according to claim 1, characterized in that, The preset anomaly identification rules include: multiple sets of anomaly triggering conditions and anomaly modules corresponding to each of the multiple sets of anomaly triggering conditions; the step of determining whether the vehicle system has anomalies based on the operating indicators and using the preset anomaly identification rules includes: The system matches the operating indicators with multiple sets of abnormal triggering conditions included in the preset abnormality identification rules to determine whether there are any abnormal triggering conditions that match the operating indicators, so as to determine whether there is an abnormality in the vehicle system. When it is determined that there is an anomaly in the vehicle system, the corresponding first target module is determined, including: When an abnormal triggering condition matching the operational metric is identified, it is determined that the system is abnormal, and based on the preset abnormal identification rules, the abnormal module corresponding to the matching abnormal triggering condition is identified as the corresponding first target module.

4. The method according to claim 1, characterized in that, The method includes: Receive log collection instructions sent by the cloud server; wherein, the log collection instructions include: a log collection strategy, and the log collection strategy includes: the identifier of the vehicle terminal and the identifier of the second target module; Perform security authentication on the log collection command; Once the security authentication is successful, based on the log collection strategy included in the log collection instruction, the log switch corresponding to the second target module indicated by the second target module identifier is turned on, and the logs corresponding to the second target module are collected.

5. The method according to claim 4, characterized in that, The log collection strategy further includes: log levels; wherein the log levels include: a first level, a second level, and a third level; the first level represents the collection of key result logs of the second target module, with the least amount of log output; the second level represents the collection of core process logs of the second target module, with a log output greater than that of the first level and less than that of the third level; the third level represents the collection of full-process detailed logs of the second target module, with the largest amount of log output.

6. The method according to claim 4, characterized in that, After collecting the logs corresponding to the second target module, the method further includes: When a data collection termination command is received from the cloud server, the log switch corresponding to the second target module is turned off.

7. The method according to claim 1, characterized in that, The method further includes: In response to an access request triggered by a user through a preset operation, display an identity authentication interface to the user; Receive authentication information input by the user through the authentication interface, and verify the authentication information; Once the authentication information is verified, the log configuration interface is displayed to the user, and the user's selection instructions for the third target module and log configuration are received through the log configuration interface. In response to the input of the selection command, the log switch corresponding to the third target module is turned on, and the logs corresponding to the third target module are collected.

8. The method according to claim 7, characterized in that, The authentication information includes: an initial password and a secondary verification code generated using the vehicle identification number (VIN) as the seed.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: The collected logs are stored in a local cache, and the network connection status of the vehicle terminal is monitored in real time. Based on the importance level of the locally cached logs and the network connection status, the locally cached logs are encrypted and uploaded to the cloud server in batches.

10. A log generation device, characterized in that, The device, applied to an in-vehicle terminal, includes: The performance indicator monitoring module is used to continuously monitor the operating indicators of the vehicle system. An anomaly detection module is used to determine whether there is an anomaly in the vehicle system based on the operating indicators and through preset anomaly identification rules; The acquisition trigger module is used to determine the corresponding first target module when it is determined that there is an anomaly in the vehicle system, and to activate the log switch corresponding to the first target module and collect the logs corresponding to the first target module.

Images